Back to Details

experience-lwc-widget-migrate

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Migrate an LWC to a widget

将 LWC 迁移为 widget

Use the LWC to recover the user's goal and data contract, then build the closest useful widget. A widget is its own declarative artifact. 
platform-widget-generate
authors it; a Lightning Type renderer may need separate wiring to make it reachable. This skill owns the comparison, handoff, integration check, and honest final status.
利用 LWC 还原用户目标和数据契约，随后构建最接近原用途且真正实用的 widget。widget 本身是一个独立的声明式产物。
platform-widget-generate
负责编写它；可能还需要单独连接 Lightning Type renderer，才能使其可访问。本 skill 负责对比、交接、集成检查以及如实报告最终状态。

1. Decide whether to proceed

1. 决定是否继续

Read and apply 
experience-lwc-widget-assess
to the component, its action output, and any existing Lightning Type/renderer. Preserve its verdict and the key findings from its report (blockers, contract change, lost interactions) in your report; do not write the assessment's own 
verdict.json
or 
report.md
files. Stop on 
pointless
, 
blocked
, 
review
, or 
needsHumanReview: true
. Proceed on 
viable
only when the intended change is explicit:
  • For 
    port-declarative
    , preserve the current visible fields and actions.
  • For 
    needs-IA-contract-change
    , identify the exact bounded output fields or pre-shaped values required. A widget against a proposed contract is a draft until the action returns that contract; do not call it working.
  • For 
    not-portable
    with a viable adaptation, describe the replacement UX and each lost interaction. Call it a rebuild, not a faithful port.
读取并应用 
experience-lwc-widget-assess
，对组件、其 action 输出以及任何现有 Lightning Type/renderer 进行评估。在报告中保留其 verdict 和关键发现（blockers、contract change、lost interactions）；不要编写该评估自身的 
verdict.json
或 
report.md
文件。遇到 
pointless
、
blocked
、
review
或 
needsHumanReview: true
时停止。仅当预期变更明确时，才可在 
viable
的情况下继续：
  • 对于 
    port-declarative
    ，保留当前可见的字段和操作。
  • 对于 
    needs-IA-contract-change
    ，明确界定所需的确切输出字段或预塑形值。基于拟议契约的 widget，在 action 返回该契约之前都只是草稿；不要将其称为已正常工作。
  • 对于 
    not-portable
    但存在可行适配方案的情况，描述替代 UX 以及每一项丢失的交互。应将其称为重建，而不是忠实移植。

2. Derive the generator handoff

2. 派生生成器交接内容

Trace each value the proposed widget displays to the actual or proposed action output. Before authoring, verify the action contract rather than relying only on an assessment prompt's description. Pass 
platform-widget-generate
an ordered field shape (
name
, 
type
, 
required
), nested/list item fields, the intended tile role of each visible element, and supported terminal actions. Preserve render order and field paths. Use its discovery results for tile definitions and attributes, its documented formula catalog for expressions, and its instructions for schema types and bundle layout; do not maintain a second catalog here. A formula can cover supported scalar/date/regex operations, while collection restructuring may require pre-shaped output.
If an LWC fixture or action example contains sample data, it can help infer the shape; sample data is optional and is not a documented generator input or a substitute for the action contract. Do not invent sample fields. For an action such as 
sendMessage
, verify that the required context reaches the agent and that the agent has a way to perform the requested work. Do not assume a widget input form can submit collected values without a discovered, validated mechanism.
将拟议 widget 展示的每个值追溯到实际或拟议的 action 输出。开始编写前，应验证 action 契约，而不是仅依赖 assessment prompt 中的描述。向 
platform-widget-generate
传入有序字段结构（
name
、
type
、
required
）、嵌套字段或列表项字段、每个可见元素预期的 tile 角色，以及受支持的 terminal action。保留渲染顺序和字段路径。使用其 discovery 结果确定 tile 定义和 attributes，使用其文档中的 formula catalog 处理表达式，并遵循其针对 schema 类型和 bundle 布局的说明；不要在此维护第二份目录。formula 可覆盖受支持的 scalar/date/regex 操作，而集合重构可能需要预塑形输出。
如果 LWC fixture 或 action 示例包含 sample data，它可以帮助推断结构；sample data 是可选的，既不是生成器的文档化输入，也不能替代 action 契约。不要虚构 sample fields。对于 
sendMessage
等 action，应验证所需上下文能够到达 agent，并确认 agent 有途径执行请求的工作。不要假设 widget 输入表单无需经过发现和验证的机制，就能提交所收集的值。

3. Generate and connect

3. 生成并连接

Load 
platform-widget-generate
and follow its mandatory live 
discoverUiComponents
and 
getUiComponentSchemas
calls. If the 
metadata-experts
MCP or discovery is unavailable, stop before authoring a bundle; report the completed assessment and proposed field shape. The generator owns its three widget files and self-validation. Do not copy its UEM syntax or validation checklist into this skill.
For an Agentforce renderer migration, also establish the Lightning Type that receives the action output. A bundle alone is not connected to the action:
  • Existing compatible Lightning Type: inspect its schema and current 
    renderer.json
    . After generation, read 
    platform-custom-lightning-type-generate/references/widget-rendition.md
    , wire the widget with field mappings, and follow 
    platform-lightning-type-widget-coordinate
    's renderer checks. If the existing renderer points to another widget or LWC, surface the replacement/merge decision before changing it.
  • No compatible Lightning Type: resolve the action's output class and a Lightning Type name from the project or the user's request. For the coordinator's supported Apex-backed route, use 
    platform-lightning-type-widget-coordinate
    with that type and the assessed output shape; let it own bundle generation and renderer wiring. That coordinator does not cover every type. If the output/type route cannot be established, stop and identify the missing integration step. Do not claim a complete migration.
If the user requested a bundle only, report it explicitly as an unconnected bundle. Otherwise, completion requires both the bundle and renderer wiring.
加载 
platform-widget-generate
，并执行其中强制要求的实时 
discoverUiComponents
和 
getUiComponentSchemas
调用。如果 
metadata-experts
MCP 或 discovery 不可用，请在编写 bundle 之前停止；报告已完成的评估和拟议字段结构。生成器负责其三个 widget 文件及自验证。不要将此 skill 中的 UEM 语法或验证清单复制过来。
在迁移 Agentforce renderer 时，还需确定用于接收 action 输出的 Lightning Type。仅生成 bundle 并不表示它已连接到 action：
  • **存在兼容的 Lightning Type：**检查其 schema 和当前的 
    renderer.json
    。生成后，读取 
    platform-custom-lightning-type-generate/references/widget-rendition.md
    ，通过字段映射连接 widget，并遵循 
    platform-lightning-type-widget-coordinate
    的 renderer 检查。如果现有 renderer 指向另一个 widget 或 LWC，请先明确替换还是合并的决策，再进行更改。
  • **不存在兼容的 Lightning Type：**从项目或用户请求中确定 action 的 output class 和 Lightning Type 名称。如果采用 coordinator 支持的 Apex-backed 路径，请将相应类型和评估后的 output shape 传给 
    platform-lightning-type-widget-coordinate
    ，由其负责 bundle generation 和 renderer wiring。该 coordinator 并不支持所有类型。如果无法确定 output/type 路径，请停止并指出缺失的集成步骤。不要声称迁移已完整完成。
如果用户只要求 bundle，请明确将其报告为未连接的 bundle。否则，完整完成需要同时具备 bundle 和 renderer wiring。

4. Check the result

4. 检查结果

Use the generator's bundle self-validation. Then compare the result to the assessed candidate: every retained visible field has a binding to the real/proposed payload; list item paths and supported actions match; omitted behavior and contract changes are stated; and, for a renderer migration, the Lightning Type points to this widget with matching attributes. Static checks establish structure and mapping, not deployed runtime behavior. Report assessment, created paths, validation results, and one of: 
migrated and wired
, 
bundle only
, 
draft pending IA contract
, or 
stopped
, with the reason.
使用生成器提供的 bundle 自验证。然后将结果与评估后的候选方案进行比较：每个保留的可见字段都应绑定到真实或拟议的 payload；列表项路径和受支持的操作应保持一致；应明确说明省略的行为和契约变更；对于 renderer 迁移，Lightning Type 应指向该 widget，并使用匹配的 attributes。静态检查只能确认结构和映射，不能证明已部署环境中的运行时行为。报告评估结果、创建路径、验证结果，以及以下状态之一：
migrated and wired
、
bundle only
、
draft pending IA contract
或 
stopped
，并说明原因。