web-react-dev

Web React Dev

Use this skill for React web client engineering. It covers browser-rendered React applications, React components, routing, data fetching, forms, frontend API integration, accessibility, performance, build, and deploy checks. It does not own mini-program host behavior, Flutter, native mobile, backend service design, or visual design system rules.

Routing

• Use product-rd-workflow first when the work spans product, design, architecture, implementation, testing, review, and release.
• Use product-ui-ux-design before or alongside coding for interaction model, layout, visual hierarchy, density, states, and UI acceptance.
• Use miniapp-product-dev for WeChat/Alipay/Douyin/Baidu mini-program pages, host-platform APIs, developer tools, review submission, and release. For React/H5 embedded inside a mini-program webview, this skill owns the React page while miniapp-product-dev owns the mini-program shell, bridge, host capabilities, and review/release evidence.
• For Taro projects (React syntax compiled to mini-program runtime): this skill owns the React layer (component decomposition, hooks, state ownership, effect discipline, accessibility primitives) and the pure shared layer in the repo's established shared module: DTOs, types, validators, pure mapping functions.
  • miniapp-product-dev owns Taro lifecycle hooks (useReady/useLoad/useDidShow/useDidHide), Taro.* runtime APIs, platform branching (process.env.TARO_ENV, conditional compilation, platform-specific files), subpackage configuration, host capability adapters, multi-target build invocation, host review/release, and rendered mini-program evidence.
  • Shared runtime adapters that mini-program targets consume are co-owned with a named final-decision owner per adapter, recorded in the repo. The adapter list and the miniapp acceptance-gate enumeration are canonical in miniapp-product-dev (the Shared runtime adapters consumed by mini-program targets row under ## Sibling Boundary With web-react-dev); that gate is blocking and its miniapp contract tests must pass before mini-program targets import the adapter. Web sets browser semantics and cannot merge an adapter change that is browser-safe but mini-program-unsafe. Do not re-add a fixed kill-switch dimension list here: the owner's safety contract names the property (fail-closed flag evaluation) and its release contract makes each host platform's gray-release mechanism its own contract, so the dimensions a given adapter needs come from that platform's contract, not from a list on this side. Before merging an adapter change, the merge record must carry the canonical row's gate token and a passing miniapp-contract run recorded on the change under merge (rule canonical in that row); a merge record without the token, or asserting mini-program-safety without the contract run, is a violation.
  • When shared code must run in both web and mini-program targets, keep react-dom, DOM mutation, browser observers (IntersectionObserver/ResizeObserver/MutationObserver), RAF/layout APIs, and other browser globals out of the shared layer; use Taro cross-platform equivalents at the consumer side.
• Use app-cross-platform-dev for Flutter, React Native, native Android, native iOS, app store release, and device-native capability work.
• Use Go or Python backend skills for API/service ownership, persistence, auth services, queues, and server contracts.
• For backend HTTP integrations, preserve current client wire behavior unless an explicit consumer-migration decision exists. Classify JSON vs protobuf-backed HTTP using ../platform-service-connectivity/references/protobuf-http-contract-signals.md.
  • First decide whether the client diff touches the HTTP contract or wire behavior. Wire-unchanged UI/component/state work does not need a backend owner round-trip and must not claim backend contract conformance.
  • For unrelated client work, classify the diff with the canonical gate. If the surface is out of scope, client work may continue without claiming backend contract conformance.
  • If the canonical gate classifies the diff as in scope, confirm the backend's recorded wire format or route back to the backend contract owner.
  • Routine JSON/OpenAPI changes use the existing API contract record and do not require backend wire-format confirmation when the canonical reference classifies the surface as out of the protobuf wire-format gate.
  • Client API wrappers must consume the backend contract's recorded response envelope per ../platform-service-connectivity/references/http-response-envelope-contract.md: for surfaces on the canonical code/message/data envelope, components and domain state read typed business data from data; other shipped or non-JSON envelopes are consumed per their recorded contract. Read only fields present in the recorded contract — do not infer business fields from unrecorded top-level or fallback shapes — and scatter no duplicate envelope parsing across the client.
  • If backend wire-format evidence is unreachable for an in-scope surface, stop at pending-contract-owner, name the backend owner or owning repo, record the attempted lookup, and set the next escalation path. An assumed-wire-format note never unblocks merge. The blocker clears only when a checkable owner record, quoted prior backend record, or explicit migration decision is available; if no owner responds within the team's review SLA, keep the client change blocked or downscope the touched wire-format surface and record the dropped surface as an open owner-routed gap. Do not claim backend contract conformance or completion for the removed slice.
  • Do not fork IDL or hand-maintain duplicated DTOs in the web repo.
• Use testing-strategy to choose unit/component/API/E2E layers; return here for React-specific implementation.
• Use test-artifact-management when the ask is about generating structured test cases from a Feishu requirements doc or codebase and tracking them in Feishu Bitable before implementation begins.
• Use defect-diagnosis first for failed tests, browser bugs, hydration/rendering issues, flaky UI, API integration symptoms, or production regressions.
• For money, quota, permission, tenant/user data, high-impact AI, repeated submit, async finality, or support-traceable incidents, apply product-rd-workflow high-risk resilience gates before treating the UI as complete.