Create an Adalo pickup-slot component with Codex

Inspect this Adalo component library, its manifest, scripts, and current SDK examples. Build one Pickup Slot Selector using those conventions. Before editing, explain how slot data, the selected value, disabled state, styling controls, and the selection action will be exposed in the builder. Verify that the SDK supports each proposed binding. Use platform-appropriate primitives, handle empty and changing data, include accessible labels and web keyboard interaction, and avoid adding a booking backend. Add focused checks for selection and disabled-state behavior. Tell me which checks ran locally and which still require Adalo and real devices.

Attach a drawing of the intended selector and four fictional slots, including one unavailable slot. State whether tapping a slot only selects it or also navigates. That behavioral detail matters more than asking Codex to make the component look polished.

A useful first contract says that a slot has a stable identifier, a visible label, and availability; selection emits the identifier expected by the app's next action. The precise list and action configuration must come from the supported component SDK. A generic JavaScript array and callback are a sketch, not proof of an Adalo binding.

Ask Codex to map every contract item to a manifest field or a supported implementation pattern. If a dynamic list cannot be bound as proposed, simplify the design or use the documented collection-binding mechanism. Do not build the entire visual treatment around an unverified data interface.

The view in the builder, the web runtime, and a native app are separate places to check. A browser-only library may render beautifully in one while failing in another. Adalo's developer standards call for cross-platform testing, so keep a platform checklist with actual results rather than assuming a shared React abstraction proves compatibility.

Use the same inputs on each target: long time labels, no slots, one disabled slot, a removed selection, and larger text. On web, check keyboard operation and focus. On native, check touch targets, screen-reader labels, and layout. Record any remaining platform limitation in the library's usage notes.

You can reverse this workflow by giving Codex a component you already maintain and a precise failure: the selected slot remains active after its record disappears, or the action fires twice on one tap. Ask it to trace the input, local state, and emitted action before changing the component.

Keep the public manifest contract stable when possible. If a setting must change, document the migration and test an existing app screen with saved configuration. A new component version that works only after recreating every instance is a change your app builders need to know about.