shopify

Which USB-C port should a customer use? A Shopify product specification guide !Official Dell UltraSharp U2723QE monitor Official manufacturer image of the model discussed in the guide. A customer looking for a monitor with a one-cable laptop connection needs two clear answers: which USB-C port carries the video signal, and how much power can the monitor deliver to the laptop? The Dell UltraSharp U2723QE has three USB-C ports with similar-looking connectors. For a one-cable laptop connection, use port #5, as numbered in the Dell manual. On Dell’s US product page, Tech Specs → Connectivity → Interfaces lists up to 90W for the video-capable upstream port and up to 15W for a downstream accessory port. The page’s family selector also shows a 140W EPR option, but that figure applies to the range of models offered there—not to the U2723QE. This monitor is specified for up to 90W. Dell U2723QE specifications The Dell manual is the source for the port numbers used in this guide. In its bottom-view diagram, the Ethernet jack is #13 and the downstream USB-C port is #15. SCAN uses a different illustration that groups several USB-A ports, so it labels that same downstream USB-C connector #13. Choose the diagram first, then make sure the legend uses the numbering from that exact image. The Shopify example below uses Dell’s published specifications as sample data. Dell manual, pp. 12–13, SCAN port illustration Put the answer where the customer needs it Answer the compatibility question near the price and add-to-cart controls, where the buying decision happens. Use the diagram to help customers locate the connector and the specification table to compare models. The 90W figure belongs in both places, but each needs its own context. Put a usable connection note next to the price > Dell U2723QE one-cable laptop connection. Plug the included one-metre USB-C to USB-C cable into rear port #5. The laptop port must support DisplayPort Alt Mode video output and USB Power Delivery input. With a compatible setup, the display supports up to 3840 × 2160 at 60Hz and up to 90W of USB PD (20V/4.5A) from the monitor to the laptop. The other included USB-A to USB-C cable is for USB data. For that setup, connect video separately over HDMI or DisplayPort. Show the host requirements alongside the wattage rather than leaving customers to infer compatibility from the number alone. Dell’s manual describes USB-C support for Windows 10 and later, and its charging table marks a 130W-rated laptop as unsupported. The laptop negotiates power based on its own capabilities. The USB port is rated for up to 10Gbps, while the available video and data modes also depend on the host, cable and the monitor’s Display → USB-C Prioritization setting. Dell connection instructions, charging table, monitor menu Add a text legend below the port photograph or diagram Pair the numbered image with a text legend directly below it. Customers should still be able to identify each port on a phone, even when the image is too small to read clearly. A visible `` also makes the port information available to tools that interpret the page’s text. | Dell manual number | Port and physical location | Use it for | | --- | --- | --- | | #5 | Main USB-C upstream, rear connector bay | Laptop video via DP 1.4 Alt Mode, upstream USB data and up to 90W USB PD to a compatible host | | #8 | Secondary USB-C upstream, rear connector bay | USB data from a second computer. Connect video over HDMI #3 or DP In #4. If using KVM, pair the video input with the USB upstream connection in the monitor menu | | #15 | USB-C downstream, underside quick-access area | USB data and up to 15W (5V/3A) to an accessory. Establish an upstream USB data connection first if you need the hub | In the Dell manual diagram, #1 is the lock slot, #2 is AC, #3 and #4 are the HDMI and DisplayPort inputs, #6 is DP out, #7 is audio line out, #9–#12 are USB-A downstream ports, #13 is Ethernet, and #14 is the USB-A port with Battery Charging 1.2. In SCAN’s illustration, #5 and #8 retain their labels, #9 groups three USB-A ports, #10 is the remaining rear USB-A port, #11 is Ethernet, #12 is the quick-access USB-A port, and #13 is the USB-C accessory port. Keep the complete text legend matched to the illustration version shown on the page. Dell manual, SCAN illustration Split the specification table by function A single “Interfaces” row can blur an important distinction: charging a laptop is not the same as supplying power to a phone or accessory. Give host charging and downstream accessory power their own rows. | Field | Dell U2723QE | ASUS PA279CRV | BenQ PD2705U | | --- | --- | --- | --- | | USB-C video input | #5, DP 1.4 Alt Mode | USB-C with DP Alt Mode | USB-C with DP Alt Mode | | USB-C host PD | Up to 90W | Up to 96W | Up to 65W | | Separate data upstream | #8 USB-C, video via another input | No separate data upstream listed on the cited spec sheet | USB-B upstream listed separately | | USB-C downstream | #15, up to 15W for an accessory | One USB 3.2 Gen 1 Type-C downstream | One USB-C downstream | | Included USB-C cabling | 1m C–C and 1m A–C, with different roles | USB-C cable, depending on region | USB-C cable | Before adding accessory or in-box cable details to a listing, check the product page for the market where you sell. Bundles can vary by region. Dell, ASUS, BenQ Wire the three displays to the same Shopify records Use Product metafields when every variant shares the same hardware. An accessory bundle or warranty option may differ without changing the ports. If selecting a different variant changes the board or power rating, define the specification fields on Variants and enable the Product boolean specs.use_variant_specs. The example will then read the selected variant’s full set of fields. If a variant’s data is incomplete, the page displays a pending message instead of borrowing the product-level value. In particular, do not show the product’s 90W rating for a variant that it does not describe. Create and fill the port entries 1. Go to Settings → Metafields and metaobjects → Metaobjects → Add definition. Name the definition USB-C Port Spec and set its type to usb_c_port_spec. Set port_number and power_delivery_watts to Integer; use Single-line text for the other fields listed below. Add a display-name field, make the entries available to the storefront, and set them to Active wherever publication status is enabled. 2. Go to Content → Metaobjects → USB-C Port Spec → Add entry and create entries for #5, #8 and #15. Appendix B contains the complete sample records. If you use the SCAN illustration, create a separate revision and its corresponding entries. Shopify metaobject entry guide | Entry field | #5 | #8 | #15 | | --- | --- | --- | --- | | model_code | U2723QE | U2723QE | U2723QE | | diagram_revision | dell-user-guide-bottom | dell-user-guide-bottom | dell-user-guide-bottom | | port_number | 5 | 8 | 15 | | role_key | host_video_pd | host_data | accessory_downstream | | port_name / physical_location | Main USB-C upstream / rear bay | Secondary USB-C upstream / rear bay | USB-C downstream / underside quick-access area | | primary_role | One-cable laptop connection | Second computer’s USB data, with separate video | Accessory data and power | | video_input | DP 1.4 Alt Mode, up to 4K 60Hz with a compatible setup | Separate HDMI #3 or DP In #4 | No video input | | power_delivery_watts | 90 | Leave blank | 15 | | pd_voltage_current | 20V/4.5A, 15V/3A, 9V/3A, 5V/3A | Leave blank | 5V/3A | | data_rate | USB 3.2 Gen 2 upstream, port rated up to 10Gbps | USB 3.2 Gen 2 upstream, port rated up to 10Gbps | USB 3.2 Gen 2 downstream, port rated up to 10Gbps | Reference the entries from the product Create these definitions under Settings → Metafields and metaobjects → Products → Add definition. Then enter the values under Products → the product → Metafields. Set both reference fields to use the usb_c_port_spec type. Shopify custom metafield definitions | Field | Type | Value for U2723QE | | --- | --- | --- | | specs.one_cable_supported | True or false | true after checking. Leave unset if unknown. Use false for a confirmed unsupported model | | specs.model_code | Single-line text | U2723QE | | specs.primary_usb_c_port | Single metaobject reference | Reference the #5 entry directly | | specs.usb_c_ports | List of metaobject references | #5, #8, #15, with the primary entry included | | specs.included_usbc_cables | Multi-line text | 1m C–C for the laptop connection and 1m A–C for USB data with separate video | | specs.host_requirements | Multi-line text | DP Alt Mode output and USB PD input on the chosen host port. Windows 10 or later per the manual | | specs.port_diagram_image | File reference limited to images | Optional authorized image such as u2723qe_ports_dell-user-guide-bottom.png | | specs.port_diagram_revision | Single-line text | dell-user-guide-bottom | | specs.spec_source_url | URL | Link to the Dell manual bottom view | | specs.use_variant_specs | True or false, Product switch | Unset or false for a single hardware spec. Use true to read Variant specs | The buy box takes the value 90 from the primary port entry. If the store already uses specs.max_pd_wattage, locate every place that consumes it—including the theme, filters and feeds—before migrating the field. The goal is to give the team one authoritative place to maintain the wattage. Install the Liquid snippet in a theme copy First, duplicate the theme under Online Store → Themes so you can work on a copy. Open Edit code, add snippets/product-usbc-specs.liquid, and merge the usb_c translation keys from Appendix A into the appropriate locale file. Find the main-product section used by the product template. In Dawn, place the decision call beside buy_buttons; add the other calls where the port diagram and specification table should appear. {% render 'product-usbc-specs', product: product, placement: 'decision' %} {% render 'product-usbc-specs', product: product, placement: 'diagram' %} {% render 'product-usbc-specs', product: product, placement: 'table' %} The snippet validates the model and diagram revision, checks for duplicate port numbers, and confirms that the primary reference appears in the list with the video-and-PD role. When an image is attached, it also checks the revision suffix in the filename returned by image_url. Renaming an incorrect image can make that check pass when it should not, so always inspect the visible port labels in the theme preview. For products with hardware variants, test each ?variant=ID URL first. Then connect the theme’s variant-update flow to the Section Rendering API so the custom specification containers refresh along with the price and product form. Confirm that adding the product to the cart adds the selected variant. If the theme already outputs {{ product | structured_data }}, begin with the three visible placements. If you manage the generator for that Product object, merge the optional properties output into its existing additionalProperty array. Preserve the existing offer, availability and variant information. Shopify Section Rendering API, Dawn product section, Schema.org additionalProperty Validate the answer on mobile, in HTML and in the cited source Use the same question at every stage of validation: Can the Dell U2723QE display a laptop’s image and charge the laptop through one USB-C cable? If so, which port should the customer use, and what is the maximum wattage? On a phone, check the area beside the price. The customer should be able to see port #5, the up-to-90W rating and the host requirements without hunting for them. Make sure the diagram agrees with the legend, then disable images and confirm that the text still explains what to connect. In the returned HTML, inspect the buy-box element. If you extended the existing Product JSON-LD, parse that separately. Finding 90W somewhere in the full page is not enough: the value could belong to a filter or another port. When the power property is present, verify that it is the numeric value 90, uses WTT as its unit, and describes laptop charging. | Local fixture | Expected buy-box output | Optional properties output | | --- | --- | --- | | #5 selected and all entries and image on the same revision | Shows #5 and up to 90W | Numeric 90, with separate #8 and #15 facts | | Image name changed to u2723qe_ports_scan-ports.png alone | Pending confirmation | [] | | Primary reference missing, support marked true | Pending confirmation | [] | | Support explicitly set to false | One-cable video and laptop power marked unsupported | Boolean false | These fixture checks run the Liquid snippet against Shopify-shaped input objects. They do not replace testing in the actual store. The target store still needs a theme preview, variant checks and verification of the image URL returned by its own CDN. When evaluating an AI-generated answer, record the exact question, date, market and source links. First check whether the answer is correct. Then check whether it cites your product page and, crucially, whether the cited passage actually supports the claim. An answer that correctly relies on the Dell manual may help the buyer, but it does not count as a citation to your store. If the answer cites your page but points only to a generic interfaces list with no clear link between each port and its role, add that context beside the buy button or diagram. Once the page is available to the search service, ask the same question again and record what changed. Google guidance on AI search features Taken together, these checks keep three kinds of evidence separate: Dell’s public documentation, the result from the local template fixture, and the test that still needs to be run in the live store. Keeping them distinct makes it possible to judge whether a change helped customers, changed the page output, or affected which sources an AI answer cites. Appendix A · Liquid snippet and English locale Save the first code block as snippets/product-usbc-specs.liquid. Merge the English locale keys in the second block into the appropriate locale file. {% doc %} Render shared USB-C specifications for a product. @param {product} product - The product owning the specs metafields. @param {string} placement - decision, diagram, table, or properties. @example {% render 'product-usbc-specs', product: product, placement: 'decision' %} {% enddoc %} {%- liquid assign owner = product if product.metafields.specs.use_variant_specs.value == true assign owner = product.selected_or_first_available_variant endif assign specs = owner.metafields.specs assign supported = specs.one_cable_supported.value assign model_code = specs.model_code.value assign revision = specs.port_diagram_revision.value assign ports = specs.usb_c_ports.value assign main_port = specs.primary_usb_c_port.value assign main_handle = main_port.system.handle assign main_number = main_port.port_number.value assign main_watts = main_port.power_delivery_watts.value assign main_profiles = main_port.pd_voltage_current.value assign requirements = specs.host_requirements.value assign cables = specs.included_usbc_cables.value assign diagram = specs.port_diagram_image.value assign source_url = specs.spec_source_url.value assign diagram_matches = true if diagram != blank assign diagram_filename = diagram.preview_image | image_url: width: 1200 | split: '?' | first | split: '/' | last assign revision_marker = revision | prepend: '_' | append: '.' unless diagram_filename contains revision_marker assign diagram_matches = false endunless endif assign valid_list = true assign found_main = false assign numbers = '|' for port in ports assign number = port.port_number.value assign number_marker = number | prepend: '|' | append: '|' if port.model_code.value != model_code or port.diagram_revision.value != revision assign valid_list = false endif if number == blank or numbers contains number_marker assign valid_list = false endif if port.port_name.value == blank or port.physical_location.value == blank or port.primary_role.value == blank assign valid_list = false endif if port.video_input.value == blank or port.data_rate.value == blank assign valid_list = false endif assign numbers = numbers | append: number | append: '|' if main_handle != blank and port.system.handle == main_handle assign found_main = true endif endfor assign mode = 'pending' if supported == false assign mode = 'unsupported' elsif supported == true and found_main and valid_list and diagram_matches if model_code != blank and revision != blank and requirements != blank and cables != blank if main_port.role_key.value == 'host_video_pd' and main_watts != blank and main_watts > 0 assign mode = 'ready' endif endif endif assign support_label = 'usb_c.pending' | t if mode == 'ready' assign support_label = 'usb_c.supported' | t elsif mode == 'unsupported' assign support_label = 'usb_c.unsupported' | t endif assign title = 'usb_c.title' | t assign watts_label = 'usb_c.host_power' | t assign requirements_label = 'usb_c.requirements' | t assign cables_label = 'usb_c.cables' | t assign port_label = 'usb_c.port' | t assign video_label = 'usb_c.video' | t assign data_label = 'usb_c.data' | t assign port_power_label = 'usb_c.port_power' | t -%} {%- case placement -%} {%- when 'decision' -%} ### {{ title | escape }} {%- if mode == 'ready' -%} **{{ product.title | escape }}**： {{ 'usb_c.connection' | t: number: main_number, watts: main_watts, video: main_port.video_input.value | escape }} **{{ requirements_label | escape }}：**{{ requirements | escape | newline_to_br }} **{{ cables_label | escape }}：**{{ cables | escape | newline_to_br }} [{{ 'usb_c.view_ports' | t | escape }}](#usbc-port-diagram) {%- else -%} {{ support_label | escape }} {%- endif -%} {%- when 'diagram' -%} {%- if mode == 'ready' -%} {%- if diagram.media_type == 'image' and diagram.preview_image != blank -%} {%- assign diagram_alt = 'usb_c.diagram_alt' | t: model: model_code -%} {{ diagram.preview_image | image_url: width: 1200 | image_tag: widths: '360, 540, 800, 1200', sizes: '(min-width: 990px) 820px, 100vw', loading: 'lazy', alt: diagram_alt }} {%- endif -%} ### {{ 'usb_c.legend' | t | escape }} {%- for port in ports -%} - **#{{ port.port_number.value }} {{ port.port_name.value | escape }}** （{{ port.physical_location.value | escape }}）：{{ port.primary_role.value | escape }}。 {{ video_label | escape }}：{{ port.video_input.value | escape }}。 {%- if port.power_delivery_watts.value != blank -%} {{ port_power_label | escape }}：{{ port.power_delivery_watts.value }}W。 {%- endif -%} {%- endfor -%} {%- if source_url != blank -%} {{ 'usb_c.diagram_source' | t | escape }} {%- endif -%} {%- endif -%} {%- when 'table' -%} {%- if mode == 'ready' -%} {%- for port in ports -%} {%- assign number = port.port_number.value -%} {%- if port.power_delivery_watts.value != blank -%} {%- endif -%} {%- endfor -%} {%- endif -%} {{ product.title | escape }} · {{ 'usb_c.specifications' | t | escape }} {{ title | escape }}{{ support_label | escape }} {{ watts_label | escape }} {{ main_watts }}W{% if main_profiles != blank %}（{{ main_profiles | escape }}）{% endif %} {{ port_label | escape }} #{{ number }} {{ port.port_name.value | escape }} · {{ port.physical_location.value | escape }} · {{ port.primary_role.value | escape }} #{{ number }} · {{ video_label | escape }}{{ port.video_input.value | escape }} #{{ number }} · {{ data_label | escape }}{{ port.data_rate.value | escape }} #{{ number }} · {{ port_power_label | escape }} {{ port.power_delivery_watts.value }}W{% if port.pd_voltage_current.value != blank %}（{{ port.pd_voltage_current.value | escape }}）{% endif %} {{ cables_label | escape }}{{ cables | escape | newline_to_br }} {{ requirements_label | escape }}{{ requirements | escape | newline_to_br }} {%- when 'properties' -%} [ {%- if mode == 'ready' -%} {"@type":"PropertyValue","name":{{ title | json }},"value":true}, {"@type":"PropertyValue","name":{{ watts_label | json }},"value":{{ main_watts | json }},"unitCode":"WTT"}, {%- for port in ports -%} {%- assign port_name = port_label | append: ' #' | append: port.port_number.value -%} {%- capture port_value -%} {{ port.port_name.value }} · {{ port.physical_location.value }} · {{ port.primary_role.value }}； {{ video_label }}：{{ port.video_input.value }}；{{ data_label }}：{{ port.data_rate.value }} {%- if port.power_delivery_watts.value != blank %}；{{ port_power_label }}：{{ port.power_delivery_watts.value }}W{% endif -%} {%- endcapture -%} {"@type":"PropertyValue","name":{{ port_name | json }},"value":{{ port_value | strip | json }}}, {%- endfor -%} {"@type":"PropertyValue","name":{{ cables_label | json }},"value":{{ cables | json }}}, {"@type":"PropertyValue","name":{{ requirements_label | json }},"value":{{ requirements | json }}} {%- elsif mode == 'unsupported' -%} {"@type":"PropertyValue","name":{{ title | json }},"value":false} {%- endif -%} ] {%- endcase -%} { "usb_c": { "title": "USB-C connection", "supported": "Supported. Check the host and cable requirements.", "unsupported": "This model does not support video and laptop charging over one USB-C cable.", "pending": "One-cable support is pending confirmation. Check the official specifications.", "connection": "Connect rear upstream port #{{ number }}. {{ video }}, with up to {{ watts }}W USB PD to a compatible laptop.", "requirements": "Host connection requirements", "cables": "Included USB-C cables", "view_ports": "View port locations", "diagram_alt": "{{ model }} bottom view. The legend gives the numbered port locations.", "legend": "USB-C port locations and connections", "diagram_source": "View the source diagram", "specifications": "USB-C specifications", "port": "USB-C port", "video": "Video input", "data": "USB data", "host_power": "Maximum USB PD to the laptop", "port_power": "Maximum power from this port" } } Appendix B · Port entry values Use these sample entries with the manufacturer’s drawing. For each input fixture described above, render the decision placement and parse the properties output. [ { "model_code": "U2723QE", "diagram_revision": "dell-user-guide-bottom", "port_number": 5, "role_key": "host_video_pd", "port_name": "Main USB-C upstream", "physical_location": "Rear connector bay", "primary_role": "One-cable laptop video, data and power", "video_input": "DP 1.4 Alt Mode, up to 3840 × 2160 at 60Hz", "power_delivery_watts": 90, "pd_voltage_current": "20V/4.5A, 15V/3A, 9V/3A, 5V/3A", "data_rate": "USB 3.2 Gen 2 upstream, rated up to 10Gbps" }, { "model_code": "U2723QE", "diagram_revision": "dell-user-guide-bottom", "port_number": 8, "role_key": "host_data", "port_name": "Secondary USB-C upstream", "physical_location": "Rear connector bay", "primary_role": "Second host USB data, without laptop charging", "video_input": "Separate video over HDMI #3 or DP In #4", "power_delivery_watts": null, "data_rate": "USB 3.2 Gen 2 upstream, rated up to 10Gbps" }, { "model_code": "U2723QE", "diagram_revision": "dell-user-guide-bottom", "port_number": 15, "role_key": "accessory_downstream", "port_name": "USB-C downstream", "physical_location": "Underside quick-access area", "primary_role": "USB data and power for compatible accessories", "video_input": "No video input", "power_delivery_watts": 15, "pd_voltage_current": "5V/3A", "data_rate": "USB 3.2 Gen 2 downstream, rated up to 10Gbps" } ]

@antirez one data point on the discussion: Maaarcocr/liquid-fight-club the task: reimplement liquid from its specs shopify/liquid-spec the results: - rust seems to cost less overall - c is faster at runtime rust is also slightly more correct (less bad bugs)

Shopifyテーマ：snippetsについて 今回はShopifyテーマファイルにある、snippetsについての情報をまとめました。 sample-theme-file/ ├── assets/ ├── blocks/ ├── config/ ├── layout/ ├── locales/ ├── sections/ ├── snippets/ <--今回のトピック └── templates/ Snippetsの主な特徴 Shopifyテーマエディタ上では扱えない（sectionsなどにコードを直接埋め込む用途専用） テーマ全体で繰り返し使うコードに最適 Snippetsの使い方 Liquidコード内でsnippetを参照するには render タグを使う（snippetのファイル名を、.liquid 拡張子を省略して指定）。 //参照ファイル = snippet/product-card.liquid {% render 'product-card' for collection.products as product, show_price: true, size: 'large' %} render タグのパラメータ 一つの render タグ内で for や with は同時に指定できないが、for や with と一緒に変数を受け渡すことは可能。 【変数の受け渡し】 snippetの外部で作成された変数を渡すために使う。渡した変数への変更は、そのsnippet内でのみ反映される。 {% render 'product-card', product: product %} 【for】 配列内のすべての要素に対してsnippetをレンダリングするために使う。as パラメータ (任意) を指定 すると、snippet内でループ中の現在の要素を参照できる。さらに、ループ中のsnippet内では forloop オブジェクト（first、index、length など）にアクセスできる。 {% render 'filename' for array as item %} 【with】 単一のオブジェクトを渡すために使う（例: product オブジェクト、section オブジェクトなど)。追加で as を指定すると、snippet内でそのオブジェクトを参照する際のカスタム名を指定できる（as を指定しない場合、オブジェクトはsnippetのファイル名で参照できる）。 {% render 'filename' with object as name %} 補足：LiquidDoc (Shopify dev docs) を使ってドキュメントを追加できる。 {% doc %} Product card snippet @param {string} title - The title to display @param {number} [max_items] - Optional maximum number of items to show @example {% render 'example-snippet', title: 'Featured Products', max_items: 3 %} {% enddoc %} render タグのスコープ render タグを使用して出力されるsnippetは、独立した環境で動作し、グローバルオブジェクトと呼び出し時に明示的に渡された変数・オブジェクトのみを継承する。イメージ的にはプログラミングにおける「関数」に近く（実際の設計思想のもとにもなっている Shopify Liquid - PR#1122）、Online Store 2.0から include タグが非推奨となっている理由でもある。 render タグで利用できるものは以下の通り： グローバルオブジェクト（例: shop、settings、productテンプレート内のsnippetであれば product オブジェクトなど） パラメータとして明示的に渡された変数 注意：collectionテンプレート内で呼び出されたsnippetは collection オブジェクトを継承するが、product オブジェクトは継承しない。product オブジェクトが必要な場合は変数として渡す必要がある（例：{% render 'product-card', product: product %}）。 snippet内から特定の変数・オブジェクトが参照できているかを確認するには、その変数をコンソールへ出力する手がある。その際、json フィルターを使うと、存在しない変数は null、空文字列は "" として出力される（json フィルターなしだと、存在しない変数と空文字列はどちらも同じ出力で見分けがつかない）。 <script> //サンプルJavaScript const title = {{ collection.title | json }}; const product = {{ product | json }}; console.log('collection-title: ', title); console.log('Product-object: ', product); </script> include タグについて（非推奨・参考用） Snippetの挿入方法として、{% include %} タグも存在するが、2019年8月以降、{% render %} タグの使用が推奨されている。 includeタグの構文 {% include 'filename' %} 非推奨とされる理由は、include が呼び出し元（テンプレートファイル）と同じ変数スコープで実行されるため。具体的には: snippetは呼び出し元のあらゆる変数を読み書きできる。 snippet内で変更された変数や、新しく作られた変数は外部に漏れ出す。 これにより意図しない変数の変更が発生し、コードの可読性・保守性が低下するのに加えて、余分なメモリオーバーヘッドが生じパフォーマンスも低下する。 参考資料 Snippets - Shopify dev docs render - Shopify dev docs include - Shopify dev docs Add new {% render %} tag - Shopify GitHub

Fast-Forwarding Past the 9 A.M. Reminder, Bob Ross Paints Straight to the GPU, and a README That Confesses Its Own Bugs --- title: "Fast-Forwarding Past the 9 A.M. Reminder, Bob Ross Paints Straight to the GPU, and a README That Confesses Its Own Bugs" published: true cover_image: dev-to-uploads.s3.us-east-2.amazonaws.com description: "Explore Appduct from Callstack, which turns your running app into an MCP server for AI agents, and react-native-skia-webgpu-video for GPU video editing on Skia 3." tags: reactnative, javascript, mobile, expo canonical_url: thereactnativerewind.com --- You’re reading The React Native Rewind #63. --- Great Scott, Your App Has a Time Machine Doc Brown needed a DeLorean and 1.21 gigawatts to jump forward in time. Our QA agents just need to test a reminder that fires at 9 a.m., and right now they sit and wait for it like the rest of us. Szymon Chmal and Callstack launched Appduct on October 20 to fix exactly that. What does it actually do? Appduct turns your running app into an MCP server (the protocol agents use to call outside tools). You register functions like advance_time, seed_cart or set_feature_flag, and the agent calls them instead of tapping through six screens. The handlers run your app's own code, so a test starts on the screen it cares about rather than the login page. Call advance_time with 60 seconds, and the 9 a.m. reminder fires without anyone staring at a clock. import { useAppductTool } from "@appduct/react-native"; import { z } from "zod"; export function AppductTools() { useAppductTool({ name: "seed_cart", description: "Fill the cart with test items.", inputSchema: z.object({ items: z.number() }), handler: async ({ items }) => ({ added: items }), }); return null; } Mount that near the root, and any agent that speaks MCP can call it. The same tool works in Swift, Kotlin, Flutter and on the web. Release builds leave it out unless you opt in. How does the agent know the app is ready? Instead of sleep(3000) and a prayer, the app posts an event like checkout_completed, and the agent waits for it. The connection runs through a small daemon on your machine and an encrypted WebSocket, paired with a single-use link (or a QR code on a real device). For the taps that still need tapping, it pairs with Callstack's agent-device. Does it work in normal tests? A day later came @appduct/e2e, which wraps the e2e tests you already have. One call fills the cart, and the test runner's AI agent gets the same tools. The same test runs on web, iOS and Android. !Appduct e2e seed cart demo Where our tests are going, they don't need login screens. 👉 Appduct --- !Ancient Aliens ProGuard meme Happy Little Frames Bob Ross could turn a blank canvas into a mountain range in half an hour. React Native video editing usually takes longer, plus a native SDK and a lot of bridge code. Sebastien Hecart published the first beta of react-native-skia-webgpu-video on October 19. What is it? It plays, composes and exports video on top of React Native Skia 3 and William Candillon's React Native WebGPU (the GPU API that Skia 3 now draws through). Every video frame lands on a Skia canvas, so we can paint text, shapes and filters straight on top. Frames travel from the phone's decoder to the encoder on the GPU, without a detour through JavaScript. The trick is that one worklet (a small function that runs off the JS thread) draws both the live preview and the exported file. const drawFrame: FrameDrawer = (props) => { 'worklet'; const { canvas, frames, width, height } = props; const frame = frames.clip; if (frame) { drawVideoFrame(canvas, frame, { x: 0, y: 0, width, height }, { fit: 'contain' }); } // Draw your Skia text, shapes, or overlays here. }; await exportVideoComposition({ videoComposition: composition, drawFrame, outPath, width: 1280, height: 720, frameRate: 30, bitRate: 5_000_000, }); It picks up where the older Skia Video left off, rewritten from scratch for Skia 3. Is anyone using it yet? Giulio Amato has already moved his video editor off Media3 (Android's native media library) and onto it. Because the same code draws the preview and the export, what we see on the timeline is exactly what lands in the file. !Skia video editor demo What's the catch? It's a beta, tested on an iPhone 15 Pro and a Pixel 8a. HDR isn't qualified yet. It pins exact Skia and WebGPU versions and needs the New Architecture and a native rebuild. So Expo Go is out. The README lists its known bugs with refreshing honesty, which is more than most of our side projects manage. Beta 3 on October 22 already cut a 4K frame on iOS from 33 MB to 12 MB. There are no mistakes, just happy little dropped frames. 👉 react-native-skia-webgpu-video --- !Afraid to ask pod install meme 📦 Nitro V1 alpha Marc Rousavy (@mrousavy) has opened the doors on the first Nitro V1 alpha, so library authors can grab the alpha-nightly tag and start poking at the future. The same week, his fbjni PR made every call into Java and Kotlin 14% faster, which is a lot of speed for one merged pull request. 📦 Radon IDE 1.20 The iPhone Duo simulator now folds right inside your editor, and Radon warns you before you launch an app that iOS 27 is about to crash for skipping the UIScene lifecycle. 📝 Supporting iPhone Duo with Expo Apple's first foldable landed on Friday, and Expo's guide explains why insets.top is suddenly zero and your tab bar has moved into a rail on the side. 📦 React Native Windows 0.85 The legacy architecture has finally been shown the door, so it's New Architecture only from here, and you'll need Visual Studio 2026 to get in. 📦 React Native Firebase 27 CocoaPods is out and Swift Package Manager is in on iOS, and the ML package has been laid to rest now that Google has discontinued it. 📦 Unistyles 3.6 A new experimental Metro integration lets you ditch the Babel plugin, and plain views now re-render in half the time. 📦 Hot Updater 1.1 Over-the-air updates now reach brownfield apps too, and bumping your version number no longer locks you out of shipping a quick fix. 📦 React Native Bottom Tabs 1.5 Swift Package Manager support has arrived, along with a new prominent tab role for the one tab on iOS 27 that deserves to stand out from the crowd. 📦 create-react-native-library 0.64 Satyajit Sahoo (@satya164) has taken the C++ template out of experimental, so your next native module can be written in C++ without feeling like a science project. 📦 React Native Better PDF 1.1 Hand it three PDFs and it stitches them into one document with a single page count and search, which is exactly the trick react-native-pdf can't pull off. !Goodbye GIF --- Authored by Luke Farrell and edited by Fran Ríos. If you’re enjoying this newsletter, why not help us grow? Share it with your friends, family, and even that one coworker who always “forgets” to update dependencies. Use this link: thereactnativerewind.com.

Shopify CLI 5.0が出た 少し前に変わったSHOPIFY_APP_AUTOMATION_TOKENが非推奨になり、SHOPIFY_SERVICE_ACCOUNT_TOKENを使用するように変わってるから、CIまわりの設定が変わりそう github.com/Shopify/cli/releases/tag/5.0.0

@hunkybill Same topics, sure. That's the table of contents. The commands underneath changed: app logs removed, theme dev --poll gone, existing JSON output reshaped. Breaking changes means a new major version. That's semver working as we promised: github.com/Shopify/cli/releases/tag/5.0.0

Design Token Architecture for Scalable Theming - How I organize a token taxonomy that survives scale - Why Style Dictionary is table stakes — and how to extend it - Token versioning & publishing that won't break teams - Mapping tokens across web and native platforms without surprises - A migration checklist you can run this week Design tokens are the single source of truth that determines whether your product family remains consistent or fragments into one-off styles across teams and platforms . When teams treat tokens as an afterthought, theming becomes a long-running maintenance tax — you trade speed today for chaos tomorrow. The problem shows up as duplicated hex values in three repos, three different dark-mode strategies, components that look off by a pixel across platforms, and last-minute accessibility fixes that slip through. Teams waste time reconciling visual regressions; product launches stall while engineers hunt down where a color actually lives. That is a governance and tooling failure — not a design problem. How I organize a token taxonomy that survives scale Design tokens must do one job: make visual decisions explicit, discoverable, and changeable without touching component code. The pragmatic taxonomy I use separates tokens into three layers: raw tokens, aliases, and semantic tokens. That separation keeps intent clear and reduces blast radius when values change . - Raw tokens (primitives) — atomic values: hex/rgb colors, numeric spacing scales, font families, raw sizes. These change rarely and should map closely to source assets from designers. - Alias tokens (scales & palettes) — reusable scales and brand palette items (for example blue.500, space.3). Aliases centralize a single design decision (the scale) and let you repurpose it consistently. - Semantic tokens (contracts) — named for purpose, not color or size: color.button.primary.bg, radius.card.default, typography.heading.1. Components consume semantic tokens only. | Layer | Example name | Typical owner | Change frequency | Use by code | |---|---:|---|---:|---| | Raw (primitive) | color.raw.blue.500 | Design tokens team | Very low | Not directly by components | | Alias | color.alias.brand.primary | Design system team | Low | Used to compose semantic tokens | | Semantic | color.button.primary.bg | Component/product teams | Moderate | Directly consumed by components | Example token JSON (Style Dictionary / DTCG-friendly structure): { "color": { "raw": { "blue": { "500": { "value": "#0B5FFF", "type": "color", "description": "Brand blue 500 (sRGB)" } }, "white": { "value": "#FFFFFF", "type": "color" } }, "alias": { "brand": { "primary": { "value": "{color.raw.blue.500.value}" } } }, "semantic": { "button": { "primary": { "background": { "value": "{color.alias.brand.primary.value}" }, "text": { "value": "{color.raw.white.value}" } } } } } } Why this matters in practice: - Stability: Components reference semantic tokens only; you can retune an alias or raw value without changing component code. - Traceability: Each token carries description, type, and optional deprecated flags so maintainers and codemods can map change impact. - Theming: Build themes by swapping alias values (or semantic overrides) rather than editing component usage. Style Dictionary (and other tools) favor a CTI (category-type-item) layout to support transforms and filters. Use that shape to make automated transforms reliable and to enrich tokens with metadata for platform-specific builds . > Important: Treat semantic tokens as the contract between design and engineering — raw values are implementation detail, not the contract. Why Style Dictionary is table stakes — and how to extend it Style Dictionary is the pragmatic choice for multi-platform token pipelines because it already understands transforms, formats, and common platform needs (CSS, JS, Android, iOS) and is extensible with custom transforms and formats . Use it as the build engine, not the policy system. Typical config (excerpt): // style-dictionary.config.js module.exports = { source: ['tokens/**/*.json'], platforms: { css: { transformGroup: 'css', buildPath: 'dist/css/', files: [{ destination: 'variables.css', format: 'css/variables', options: { outputReferences: true } }] }, js: { transformGroup: 'js', buildPath: 'dist/js/', files: [{ destination: 'tokens.esm.js', format: 'javascript/esm' }] }, android: { transformGroup: 'android', buildPath: 'dist/android/', files: [{ destination: 'colors.xml', format: 'android/resources' }] }, ios: { transformGroup: 'ios', buildPath: 'dist/ios/', files: [{ destination: 'Colors.swift', format: 'ios-swift/class.swift' }] } } }; Why you will extend Style Dictionary: - Built-in transforms handle name casing and unit conversions, but you will need platform-specific tweaks: px -> dp/sp for Android, rem -> pt for iOS typography, and color-space conversions for Display P3 or platform-native color types . - Preserve token references in outputs using options.outputReferences so generated CSS/JS produces var(--semantic-token, var(--alias-token)) fallbacks and keeps intent readable downstream . Custom transform example (register a simple size transform): const StyleDictionary = require('style-dictionary'); StyleDictionary.registerTransform({ name: 'size/pxToDp', type: 'value', matcher: token => token.type === 'size', transformer: token => `${Math.round(parseFloat(token.value) * (160/96))}dp` }); Operational notes: - Run StyleDictionary.buildAllPlatforms() inside CI to emit a deterministic set of artifacts (CSS variables, TypeScript types, Android XML, iOS Swift files). - Keep transforms idempotent and testable. Add unit tests for a transform that converts spacing across platforms. Style Dictionary is not the only tool, but it is widely adopted and integrates with the newer DTCG (Design Tokens) movement to standardize JSON formats across tools . Token versioning & publishing that won't break teams Treat your token package like a public API. Use semantic versioning and map changes to semantic impact so downstream consumers can safely adopt updates . Semver mapping I use: | Change type | SemVer bump | Example | |---|---:|---| | Breaking semantics or removals | Major (1.x → 2.0.0) | Rename color.button.primary.bg to a different function | | Additive, non-breaking tokens or new themes | Minor (1.2.0) | Add color.toast.info.bg | | Fix metadata, typos, build fixes | Patch (1.2.1) | Correct description or type, rebuild artifacts | Operational policy: 1. Add a deprecated: true flag and replacement pointer to old tokens in a minor release. Consumers get lint warnings before removal. 2. Remove a deprecated token only in a major release; include a clear migration table in release notes. 3. Publish per-semver release artifacts for each platform and include exact SHA/tarball links for native consumers. Distribution patterns: - Publish a canonical design-tokens npm package with generated artifacts (dist/css, dist/js, dist/android, dist/ios). Shopify and others publish token packages to npm as a single distribution point . - For very large ecosystems, split tokens into smaller packages (per-component token packages). Fluent UI’s semantic-tokens RFC describes the per-component package approach to reduce the blast radius and to emit per-component fallback CSS variables . Automated release pipeline (example): - CI: npx style-dictionary build → run token validation linters → run color-contrast checks → build artifacts → npm version {patch|minor|major} → npm publish. - Add changelog entries that map old→new tokens and include example replacement code snippets. Atlassian’s token ecosystem shows how linting and codemods can be part of the rollout: they expose a token() helper, lint rules, and codemods to help replace raw values with tokens safely . Use those patterns to avoid surprise breakages. Mapping tokens across web and native platforms without surprises Cross-platform pitfalls are predictable: unit mismatches (px vs dp vs pt), color-space mismatches (sRGB vs Display P3), and different platform naming conventions. Plan transforms to handle those differences centrally rather than ad-hoc in product code . Key tactics: - Encode type and unit metadata on tokens so transforms can make deterministic conversions (for example type: "size", unit: "rem"). - Use Style Dictionary’s built-in transforms for common conversions (remToSp, remToDp) and color transforms for different platform color objects . - For color, prefer storing tokens in a modern color space and generate platform-specific representations in the build step. The DTCG spec now documents color handling and interoperable color formats; align your schema to be compatible . Example CSS-based theming pattern (generate with Style Dictionary): /* dist/css/variables.css (generated) */ :root { --color-button-primary-bg: #0B5FFF; --color-button-primary-text: #FFFFFF; } [data-theme="dark"] { --color-button-primary-bg: #093b9f; } Fallback strategy for gradual migration (generated): /* in component CSS */ background: var(--semantic-button-primary-bg, var(--alias-brand-primary, #0B5FFF)); For native: - Android: emit colors.xml under res/values/ with names converted to snake_case or lowercase as required. - iOS: emit Colors.swift or .xcassets + color catalogs, using PascalCase or idiomatic Swift names. Style Dictionary’s formats include a wide set of ready-made outputs for Android and iOS; use those and customize only when necessary . You can also generate TypeScript declarations to get strong typings for token consumption on the web . Design tool sync: - Keep designers and engineers aligned by syncing tokens from Figma (Tokens Studio / Figma Tokens plugin) into the token repository, then run the build pipeline to produce artifacts consumers use . A migration checklist you can run this week This is a compact, runnable checklist. Each line is a discrete sprint chunk. 1. Audit (1 week) - Extract current variables and hard-coded values across repos (grep/shell scripts, theme folders). - Export the design file tokens (Tokens Studio or Figma Tokens) to JSON for reference . 2. Define taxonomy & ownership (1 week) - Create folders: tokens/raw/, tokens/alias/, tokens/semantic/, tokens/themes/. - Author token naming conventions (CTI) and a small governance doc. 3. Seed tokens & config (1 week) - Put primitives under raw/; create alias scale files; define the initial semantic tokens. - Add style-dictionary.config.js and a package.json script: "build:tokens": "style-dictionary build". 4. Build & validate (ongoing) - CI job: npm run build:tokens → run a token linter and color-contrast checks (automate with an a11y script). - Commit generated artifacts to an artifacts branch or publish to an internal npm registry. 5. Pilot adoption (1 sprint) - Pick a single small component or page. Use the semantic tokens only in that module. - Add a temporary compatibility layer if needed: component reads semantic token then falls back to legacy CSS var. 6. Codemod and scale (2–4 sprints) - Replace direct hex values and legacy CSS vars progressively via codemods and lint rules. - Publish a minor release with deprecated flags before removal. 7. Ongoing governance - Enforce token usage with lint rules and CI checks. - Use change logs that include explicit migration paths and code snippets. Quick example package.json tokens scripts: { "scripts": { "build:tokens": "style-dictionary build", "test:tokens": "node ./scripts/validate-tokens.js", "release:tokens": "npm run build:tokens && standard-version" } } Short codemod pattern (conceptual) to replace var(--old-token) with semantic helper usage: // pseudo-code for jscodeshift replacement // find CSS-in-JS literal strings containing 'var(--old-token)' and replace with `token('color.button.primary.bg')` Real-world reference points: - Atlassian publishes token linting and codemods to help teams migrate and enforce usage . - Shopify historically published token artifacts for multiple formats and distributed via npm . - Fluent UI is moving toward per-component semantic token packages and explicit fallback structures to reduce breaking changes . > Callout: Ship early, pilot wide. A single component fully migrated to semantic tokens is worth more than half a token repo left in limbo. Adopt the taxonomy, automate builds with Style Dictionary, and treat tokens like a public API: version them, test them, and communicate changes. That approach turns theming from a constant firefight into a predictable engineering workflow and makes consistent cross-platform theming achievable at scale . Sources: Design Tokens Community Group - Specification and ecosystem guidance for the DTCG JSON format and community-driven best practices; used to justify token standardization and cross-tool interoperability. Style Dictionary — Built-in formats & transforms reference - Documentation of Style Dictionary formats, transform groups, and transform registration used for platform builds and customization examples. Using CSS custom properties (MDN) - Behavior, scoping, and @property guidance for CSS custom properties used in theming and fallback strategies. Semantic Versioning 2.0.0 (SemVer) - The semantic versioning specification referenced for mapping token changes to version bumps and release policy. Atlassian Design System — Use tokens in code - Concrete examples of token helper functions, linting guidance, and migration tooling recommendations used as a practical model for adoption. Shopify Polaris Tokens (GitHub) - Example of a real-world token package and distribution approach (npm, multiple formats) illustrating multi-format distribution. Tokens Studio for Figma (official repo) - The Figma plugin used by many teams to manage tokens in design files and sync them to code; referenced for design tooling integration. Fluent UI RFC: Fluent Semantic Tokens (GitHub issue) - A real-world RFC discussing per-component semantic tokens, fallback structures, and reduced blast radius for token changes.

Hey @ShopifyDevs the App Bridge API has stopped working for the camera scanner in iOS This is causing issues for Merchants trying to pack orders shopify-app-bridge#589

こちらのスキルに対するフィードバックも受け付けています！ community.shopify.dev CLIはオープンソースなので、直接PR送ることも可能です！ github.com/Shopify/cli/tree/main/packages/app/src…

How we create and optimize shops with Claude Code (Full Workflow + Tool Stack) Everyone knows how to use Claude chat. Here's how we use Claude Code to build real software, custom client apps and Shopify stores. Work with us to scale your brand:lotuxagency.com Follow along on Instagram: instagram.com Get my dev workflow + all plugins mentioned: - Dev Workflow: dropbox.com - VSCode: code.visualstudio.com - Github: github.com - Caveman: juliusbrussee/caveman - Claude Plugins: anthropics/claude-plugins-official - Impeccable: pbakaus/impeccable - Marketing Skills: coreyhaines31/marketingskills - Superpowers: obra/superpowers - Shopify AI Toolkit: Shopify/Shopify-AI-Toolkit - Context7: upstash/context7 Timestamps: 00:00 Intro 00:45 The custom app we built for a client 01:33 Principles first: code, GitHub & deployment 03:26 Branches, pull requests & merges explained 04:40 Previewing changes on localhost 05:24 Setting up VS Code + Claude Code 06:27 My master workflow document 07:28 The MCP servers to connect first 09:30 The plugins I recommend 10:53 Your context window: /compact & /clear 11:47 Impeccable, Superpowers, Shopify & Context7 13:01 Downloading your Shopify theme locally 14:47 The CLAUDE.md file 15:30 Plan mode vs auto mode 18:50 Connecting Shopify to GitHub 21:36 A store built with zero apps 22:38 Designing in Claude Design first 24:37 From design to code 25:04 Wrap-up