Resolve common questions before adopting Liquidify in an existing React interface.
These answers concern incremental adoption of the current React implementation. They do not describe a version-to-version upgrade or a conversion of SwiftUI source code.
Start with one contained task and keep its routes, data flow, and persistence contract. Replace the relevant controls and review the complete task before extending adoption. The Migration guide provides the sequence.
The checked npm latest React release is 0.0.0-placeholder; it does not supply the implementation shown here. Use Developing overview for the current limitation and source-evaluation path. Existing installation examples that assume a published implementation are not sufficient evidence of availability.
Incremental composition is possible in a React interface, but verify the combined result. Load the aggregate stylesheet once, inspect CSS conflicts, and review shared focus order and form behavior. Start with public props and tokens instead of carrying private selectors from a previous control library into Liquidify.
No persistence is implied by changing controls. Connect each component's documented value and callback to application state. A controlled Toggle uses checked and onChange; other controls can use different names and value shapes. The React tutorial shows a draft, asynchronous save, and retry feedback.
The shipped Dialog invokes an enabled action's callback and requests closure without awaiting its promise. A controlled open prop still belongs to the application, but that does not create a built-in asynchronous form contract. Use a composition with explicit validation and save ownership for an editor that must remain open after failure. See Dialogs.
Use familiar concepts as a starting point, then check the React API and rendered semantics. SwiftUI modifiers, native platform services, and automatic layout adaptation are not imported with the library. Read Coming from SwiftUI.
Review actual backgrounds, keyboard interaction, long labels, both themes, and the browsers your product supports. A visual resemblance does not establish identical rendering or accessibility behavior.
Record the source revision, package artifacts, and verification results together. The checked packages use 0.0.0 labels, so matching versions alone cannot establish parity. Verify a usable release before replacing local artifacts with registry packages. Follow Versioning for documentation context without assuming that it supplies a published upgrade path.
No general consumer migration tool has been verified for this workflow. The source repository contains internal development scripts; their existence does not establish a supported migration from another UI library or from SwiftUI. Plan the component and state mapping explicitly, and record unsupported requirements.