Clear separation of model and view concerns in Solara?

[metaperl]

In the docs we see this example:

import solara

clicks = solara.reactive(0)


@solara.component
def Page():
    def increase_clicks():
        clicks.value += 1

    solara.Button(label=f"Clicked {clicks} times", on_click=increase_clicks)

What bothers me about this is:

1. there is no Counter class for the model
2. the increase_clicks method should be updating a model object
3. it is not clear how to connect the solara.reactive(0) clicks to the clicks attribute of a model object.

PS. I maintain a list of pure python web frameworks. I know that Solara is shooting to be a Class A framework - industrial strength. I hope the devs can address my concerns so it gets there.

[maartenbreddels]

Hi,

I appreciate that you are concerned about this since we also find it very important to have state and UI clearly separated.

1. What do you expect to see? We keep our model state outside of the UI using the reactive variable, I am not sure how a class is needed here. But I'd like to understand your perspective!
2. That is what we do. Our reactive variable is our model object. It has no relationship with the UI, except that our UI automatically observes/watches/listens to changes to them. Could you maybe elaborate on why you think we are not updating a model object?
3. Sorry, we had a bug in the code, please see docs: fix modify script code suggestion #85 (which should be live soon, the current code contains a bug). The {clicks} should be {clicks.value}.. Does https://solara.dev/api/reactive clarify things, especially the part "When a component uses a reactive variable, it automatically listens for changes to the variable's value. If the value changes, the component will automatically re-render to reflect the updated state, without the need to explicitly subscribe to the variable.". If not, let us know what confuses you.

Maybe the following code resonates better with you, where all logic that modifies the state is outside of the UI component.

import solara

class State:
    clicks = solara.reactive(0)

    @staticmethod
    def increase_clicks():
        print("lala")
        State.clicks.value += 1

@solara.component
def Page():
    solara.Button(label=f"Clicked {State.clicks.value} times", on_click=State.increase_clicks)

[maartenbreddels]

Sorry for the confusion in item 3, this was already merged, and live, and you can actually use {clicks} because we overload __str__

[metaperl]

What do you expect to see? We keep our model state outside of the UI using the reactive variable, I am not sure how a class is needed here. But I'd like to understand your perspective!

This is a good question. Let's change gears. If Solara were to implement TODOMVC then the model for the todos would be a pure data model, with no user interface hints (such as solara.reactive or user_state) but with a clear interface between the data model of the todo items and the rendering of these items in a view.

[maartenbreddels]

Ah, I think I understand the confusion. solara.reactive has nothing to do with the interface. It's a container around data to make it reactive. This is in solara how we separate UI from application state/data.

Also see https://solara.dev/examples/utilities/todo , where we store todo items in a dataclass . I hope that helps.

Does this clarify things?

[metaperl]

The TODO example is excellent ... I have moved Solara from Class C to Class B after reviewing the code.

[maartenbreddels]

Thank you ❤️ ? What do you miss for it to be considered class A?

I think we have a clear separation of concerns, so you either disagree with that or you still miss something.

[metaperl]

Solara is now listed as a class a framework :) https://metaperl.github.io/pure-python-web-development/class-a.html