Anatomy
The anatomy of Solara's functionality
Anatomy
For communication, it is useful to speak the same language and use the same idiom.
As a reference, we provide this "anatomy" image of our favorite ClickButton component with a layout that we consider best practice.

Explanations
- Import
solaraand you also get thereactonnamespace with it (saves typing, and finding/remembering which hooks is in which packages) - Add a
@solara.componentdecorator to turn your function into a component. - Start with
use_statehooks and other hooks. This avoids issues with conditional hooks or hooks in loops. - Data/state flows down (to children)
- Information (events, data) flows up from children via events and callbacks (
on_<some_event_name>=my_callback). - If you need multiple components, use a parent container component as context manager. A good default name to give this context manager is
main. Don't forget to return it in your render function! - The body of your component (the function you wrote) is called the render function.
- In between the hooks as defining all your elements, you put your custom code, like checking variables, defining callbacks, and other logic.
- The only way for a component to cause itself to rerender is to have state (using
use_state) and change it (calling the second return value with a different value). - Reacton is declarative. Your render function gets executed after every state change (and thus should be relatively cheap to execute). Reacton will find out the changes for you and will add, remove and update the associated widgets for you. This means you can easily do conditional rendering (creating an element in an if statement or in a loop).