# Create an Adalo pickup-slot component with Codex

Use Codex to develop a small Adalo component for choosing pickup slots, define its builder settings and actions, and test the boundary between selection and booking.

- Canonical URL: https://adalocado.com/guides/codex-adalo-custom-components
- Verification: Documented from current sources
- Topic: Responsive Design
- Skill level: Advanced
- Last reviewed: 2026-10-26
- Builder and evidence scope: Adalo component developer documentation reviewed October 26, 2026; published developer pages are dated February 2025 and the example has not been built
- Verification owner: Adalocado editorial
- Next review: 2027-01-26
- Index status: index-now

## Short answer

Start with an Adalo component library and ask Codex to implement a single pickup-slot selector using its existing manifest and platform conventions. Define the configurable inputs and selection action first, then test the component in Adalo on every platform you intend to support.

## Intended outcome

A scoped component specification and development workflow for a reusable pickup-slot selector that fits the Adalo component system.

The pickup-slot selector is a useful custom-code boundary: a small interaction with explicit inputs and one output. Codex can work on that code while Adalo continues to handle the surrounding app screens and actions.

## Requirements

- An Adalo account with the appropriate component developer workflow enabled
- A component library repository that Codex can inspect and edit
- A local runtime compatible with the actual component toolchain
- Web and native test environments for the platforms you intend to support
- A decision that a built-in or existing marketplace component cannot satisfy this interaction

## Step by step

1. **Prove why a custom component is useful**

   Try the pickup flow with existing buttons or a list first. A custom selector becomes useful when several screens need the same selection, disabled-state, and layout behavior. Keep booking logic outside the component so the new code has one clear responsibility.

2. **Start from the Adalo library structure**

   Follow the linked component setup documentation and inspect the resulting package and manifest. Ask Codex to preserve that scaffold and use its existing scripts. Verify toolchain compatibility before adding dependencies; older minimum-version text is not a recommendation to use an outdated runtime.

3. **Write the component contract**

   Specify where slots come from, how IDs and labels are bound, how unavailable slots are represented, the initial selection, styling controls, and the action fired on selection. Have Codex verify the actual SDK mechanism for each binding instead of inventing arbitrary props that the builder cannot expose.

4. **Implement the smallest interaction**

   Render a compact group of slot choices. An enabled choice becomes selected and emits its stable value once. A disabled choice cannot activate. Include an empty message, visible focus on web, readable labels, and a defined response when the previously selected slot disappears.

5. **Connect the component in a test screen**

   Use the supported development workflow, add the component to a test app, bind fictional slot data, and attach a harmless selection action. Check that changing a builder setting reaches the component. The developer documentation notes that manifest changes require restarting the component development process.

6. **Test selection and booking separately**

   Verify layout and interaction on web, iOS, and Android. Then connect selection to a separate booking action whose server rechecks capacity. When a slot fills between display and confirmation, show the conflict and let the person choose again rather than showing a false booking success.

## Why it works

- A component library includes more than a React view. The builder must know which settings and actions it exposes, and the implementation must follow the supported platform and binding conventions.
- Keeping selection separate from reservation makes the component reusable and prevents local visual state from being mistaken for an authoritative booking.

## A reusable prompt for 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.

## Review the contract before the styling

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.

## A component has more than one environment

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.

## Use Codex to improve an existing component

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.

## What still needs checking

- Original written component example; the SDK binding, development setup, and cross-platform behavior require project-specific verification.

## Data model

| Collection | Properties | Relationships |
| --- | --- | --- |
| Pickup Slots | Stable slot ID; label; start time; availability | Slots belong to a pickup location or schedule |
| Reservations | Chosen slot; confirmation status; created date | A server-confirmed reservation belongs to a User and a Slot |

## Common failures

### The generated component is ordinary browser-only React

Return Codex to the Adalo scaffold and platform requirements. Inspect for DOM-only elements or browser APIs on native paths and require the appropriate React Native implementation.

### A new setting does not appear in the builder

Compare the manifest entry with the SDK documentation and generated examples. Restart the development process after manifest changes, then confirm the component receives the configured value.

### Two customers see the same slot as available

Treat displayed availability as advisory until the server confirms the reservation. Enforce capacity atomically where bookings are stored and handle a conflict in the app.

## Testing checklist

- [ ] Selecting an enabled slot calls the configured action once with the documented selection value.
- [ ] A disabled or unavailable slot cannot be selected through touch or keyboard interaction.
- [ ] A changed slot list removes an obsolete selection rather than submitting a stale value.
- [ ] Long labels, an empty list, narrow layouts, and enlarged text remain understandable.
- [ ] Web, iOS, and Android are tested independently before claiming support for each platform.
- [ ] Every exposed setting corresponds to a supported manifest binding
- [ ] Selection emits a stable slot identifier exactly once per activation
- [ ] The component handles unavailable, empty, and removed selections
- [ ] Platform support claims match completed web and native checks

## Limitations

- This is a component development plan, not a finished component package or a tested marketplace listing.
- The linked component developer pages are dated February 2025; check the generated package, CLI requirements, and your editor's support before relying on exact setup details.
- Confirm component development is supported in your actual Adalo builder; a component library is not automatically interchangeable with an Ada-generated app's interface.
- A selected slot is a user preference, not a confirmed reservation; authoritative availability checks belong on the server.
## Sources

- [OpenAI: Codex best practices](https://learn.chatgpt.com/docs/learn/best-practices)
- [Adalo developers: Introduction and platform standards](https://developers.adalo.com/docs/basics/introduction/)
- [Adalo developers: Creating a Component](https://developers.adalo.com/docs/basics/create-adalo-component/)
- [Adalo developers: Testing](https://developers.adalo.com/docs/workflow/testing/)

## Changelog

- 2026-10-26: Created a Codex-assisted custom component workflow focused on slot selection and explicit platform testing.

## Related resources

- [Plan an Adalo app with Codex before building the screens](https://adalocado.com/guides/codex-adalo-app-planning)
- [Debug an Adalo workflow with Codex using records and evidence](https://adalocado.com/guides/codex-adalo-debugging)
- [Build an AI listing assistant for Adalo with Codex and a Custom Action](https://adalocado.com/guides/codex-adalo-custom-actions)

Markdown version: https://adalocado.com/guides/codex-adalo-custom-components.md