Best practices for state management and encapsulation
I am trying to figure out how to handle application state in a pythonic and scalable way. I don't like having global (reactive) variables, and I would like to encapsulate as much logic as possible into the components to separate concerns.
1. Is there any way for components to access reactives (solara.reactive or solara.use_state) on other components?
2. Can components be classes, or in some other way carry methods / properties / reactives in order to encapsulate behaviour? (eg general form of question above)
3. Are there examples/docs/instructions for how to create complex application states to be shared between components? I'm envisaging the application state as a big, nested dict that contains all state.
4. Is component state better managed by having a module per component that defines one or more reactives and their manipulation functions together with the component itself, so that you would import my_component and then use my_component.MyComponent, my_component.data and my_component.update_data(new_data)?
3 Replies
Regarding global reactive variable, I am not sure "not liking" is a good reason to not use it. They are useful for application state, where you don't need multiple instances. If you build something for which you need multiple instances, yes, don't use them. If it is application state, it will make your application much simpler.
1. Yes, you can pass reactive variables as arguments to components.
2. you probably don't want the component to do that, but you could create a class with methods that mutate the reactive variables.
3. We plan to build out https://github.com/widgetti/solara/pull/667 a bit, which is not too complex, but less trival. Does that sounds like something that would help you?
4. i would split components and state in larger applications, focus on the state, get that and the state transitions(function that gets called in event handler) right, and let your components be simple visualuzations of that state.
Let me know what you think, feel free to ask more, you are asking the right questions!
kecnry
<:pull_open:882464248721182842> [widgetti/solara] docs: todo example to use a class for state
This PR updates the todo example to place all state in a (re-usable)
TodoItem class, instead of a dataclass. This allows avoiding the need for Ref and .fields.
If there is no other example for Ref and fields in the docs, then maybe this shouldn't be merged, but at least shows the difference between the two implementations.Created
Thank you for the reply. I could have verbalized by objection to global variables better. Specifically I'm trying to understand how to build an application where the user adds and removes components herself, so the components and their state have to be linked dynamically.
1. My reflex would be to pass Components to other Components, saying "this is the component you should interact with". In that way the parent component does not need to know how these components interact (i.e. how they share state). Practically, the follow-up question would be: in the Todo example you linked, can other component access the create_new_item() member of a TodoNew component? If so, is this a bad idea and why?
2. Are there any code examples for this?
3. It was useful but not sufficiently complex. I tested it and commented in the PR. I hope it will be helpful.
4. I'm starting to grasp that "state" is central concept here. It's just difficult to transition from OOP to this paradigm.
I will play around with the TODO example and see if I can make it more complicated.