Insights · Design and code · 2 min read
Know when to make a custom component.
The built-in components cover the familiar parts of an app. A custom component earns its place when a shared design or a specialised interaction needs a home of its own.
Start with the components you already have
A product card does not need a new code file. A container, an image, some text and a button express it clearly, with properties that stay easy to change on the canvas. Built-in components also give Sanic AI a known vocabulary to work with.
Try the catalogue first. You keep more of the interface directly editable and have fewer moving parts to look after.
Turn a repeated design into a shared component
When the same design appears in several places, select the layers and create a custom component. Its structure and appearance update every linked copy together. A plain group only organises one area; a shared definition keeps copies in step.
Name it for what it does, such as Workout card or Account summary, and keep the definition focused. If one copy needs its own content or structure, detach that copy before changing it. Shared designs do not yet have variants or per-copy text overrides.
Use code for a specialised feature
A game board, a chart or a gesture that the catalogue cannot express belongs in code. Write the component in the code workspace, register it, and expose the few settings you want to adjust visually. It then sits on the canvas beside the built-in components, and the six game templates are built exactly this way.
Keep the implementation inside. Expose meaningful settings, such as a label or a difficulty level, with sensible defaults. A small, understandable set of properties is easier for people and for Sanic AI to use.
- Make it work at different widths and heights.
- Use explicit input properties and event callbacks.
- Include empty, loading and failure states where they apply.
- Check any library in Code's Libraries view before depending on it.
Check the environment your feature needs
A package that works in a browser is not automatically a mobile package. Browser globals, missing native modules or a library's own setup can stop the same code running on a phone. The code workspace reports native compatibility problems, which is a good start and not a substitute for running the feature.
Test the component in the preview and on the device you are aiming at. Expo Go has a fixed native runtime, so a library that needs its own native module needs a native build instead. A custom component is an extension point, not a promise that anything can run anywhere.
