One-Way data flow

[a-teammate]

Hey all,

I love the project, really helped me a lot spinning up small prototypes very, very quickly!
I wanted to give some quick feedback, how I use it and what I could imagine might improve it further for that.

Step 1

My first step in creating something is always the same:
Think about what the user wants to see at what point of their navigation journey, i.e. describe the data they want to see at those points.

Since that data is what they want to see, it almost never what I want to store, i.e. I have duplicated data all over the place (since the same information bit often appears e.g. in 2 pages as "preview" and on a third page as "context", or more detailed.)

Example (GitHub)

Github Code Browser Page shows file name, modification date, modification author and a button to open the file.
Github File Page shows file name, file content, modification date, modification author and a button to open to the browser.

Long story short (probably not totally new so far :D ): My UIs usually involve different views onto the same data in different ways, for different User Journeys through the app.

Step 2

Now the fun is deduplicating this data to some common source of truth.
Which means I have the following data flow:

SourceOfTruth (call it "Database" or whatever)
↓ (PageDataModel.fromSourceOfTruth(..))
PageDataModel
↓ display it using view_page(data: PageDataModel) with nicegui
Browser

What I afterwards do to add interactivity is modifying the source of truth:
like db.files[page.current_file].name = xy, db.files[page.current_file].name = xy (e.g. as on_click action for a button)
Maybe then I might even add some wrapper functions, when multiple effects are caused by one user action (like def merge_pull_request_button_pressed(pr_id):)

Benefits

This style of structuring things has the obvious benefit of a common source of truth (i.e. no 'unsound' data), but also adding interactivity step by step.
The name for it is sometimes referred to as "The Elm Architecture", but Redux and the like picked up this concept as well I believe.

One thing I could imagine would benefit from building this style more into the API of nicegui could be performance and predictability.

API suggestion

@ui.data(["repo", "file", "editmode=mode"]) // <- this is data coming from the route
class RepoFile:
    """What the user want to see when they arrived at the full detailed File View in the Repo."""

    last_change: LastChangeDense
    file_name: FromRoute("file") # ? not type checked afterwards..
    editmode: RouteParam[bool] = False # but this is
    content: FileContent

    def fromStorage(cls, storage: Storage, repo: str, file: str, editmode: bool):
         """Get the particular data for this view from the common source of truth (based on route parameters).""" 
         content = storage.repos[repo].files[file]
         return cls(...)

storage = SourceOfTruth.from_blank_session()

@ui.view
def view_repo_file(p: RepoFile):
     ui.row()...

nicegui.open_and_reload(view=collect_views(), source_of_truth=storage)
# the old behavior of "watch everything" could be enabled with a helper function like
# source_of_truth=globals_watcher

Thank you for reading my 2 cents, I'd love to hear your thoughts on this!

[falkoschindler]

Thanks for your warm words and the interesting idea of an API extension. What you're describing is definitely a common use case. If we can simplify things a bit, it would certainly be of great value.

Regarding your code example: I'm struggling a bit to see what you propose to be new NiceGUI API features and what is part of user code. But I guess the main ingredients are ui.data, ui.view and nicegui.open_and_reload. Can you elaborate a bit about their individual role?

More specifically:

• How does ui.data relate to a route?
• How does ui.view integrate with NiceGUI's ui.pages and/or FastAPI's routes?
• Do you imply that the view somehow finds its dependencies (RepoFile in this case) automatically via type annotation? So every time the view is rendered it gathers its dependencies, which in turn know how to load from their source of truth?

[a-teammate]

Thank you Falko for your fast reaction!

That API proposal was far from thought-through, just a quick on-the-fly sketch. Should have called it like that.
One thing which made it more complex, was to add parametrization for reusing a data view for slightly different parts of the data storage.
I think this made the example very complicated to understand. I did some notes on routes in the end here, but probably I should have ignored any API sketches in the first step :D

Also, I think I should have split the two parts: "How I use it" and "Ideaize how the one-way-data flow could be done in the most pythonic way".

Do you imply that the view somehow finds its dependencies (RepoFile in this case) automatically via type annotation? So every time the view is rendered it gathers its dependencies, which in turn know how to load from their source of truth?

Yes, exactly. I as a UI dev want to

1. describe what users see on the page (which maps to a User Action of my users, i.e. what they currently want to do)
2. (mock that data and render it, to give people an impression of what they will be able to experience)
3. describe how the data is stored (with a lot of relations, so "duplicate" data is not out of sync, but just mentioned once)
4. describe what a user interaction does (link clicked? button clicked? text entered?)

The API idea is to implement it in a little pythonic way:

1. dataclasses: PageData
2. (implement a spartanic view using a nicegui.page() and some mocked data. Maybe multiple pages, with some non-meaningful routes, just so you can use show some first navigation flows)
3. dataclasses: "StoredData" (and provide functions to nicegui for transforming the shared source of truth StoredDate to the PageData).
4. callbacks, attached to the UI elements as usual.. (callbacks can only modify data we passed the control of to nicegui's watcher, i.e. StoredData or mocked PageData)

If 4. is only allowed to modify the StoredData/or mocked Data, we would know and ensure the soundness of the data everywhere.
I see that "just adding a class around your used variables" does not sound like a big win, but I would believe it goes some steps towards a more explicit separation of "what is used by nicegui to render and trigger updates" (niceguis main purpose in this case) from "what the UI dev wants to show and make interactable".
One could either try to enforce a single class for the storage ui.run(storage: StorageData) (which sounds like a good idea to me personally, given my background as elm developer, but maybe not to everyone). Or one could just allow a list and give a helper for putting "all global data" in there to fall back to the current behavior (ui.run(storage: List[object] = ui.collect_global_objects()))

4. also implies that cronjobs (scheduled functions modifying the StoredData, and therefore triggering a rerender) are not part of the one-way UI run code, but a separate API.

routing

I could imagine not many changes, if at all are required for the routing.
However we might want to redesign that as well later. From my understanding routes have the purpose of addresses, to serve as entry point, when opening the app from links.
Mainly supporting Single Page Applications better would require an improved design (coupling addresses/routes to pages is suboptimal, if you only have a single page :D).

Parametrization of pages (currently through parametrization of "routes") mainly changes which part of the storage is transferred to what the user views (i.e. only the PageData).

Hence I was too quick in approaching this part in the current discussion already and believe it makes sense to address it as a second step, after "simplifying the data flow".

For a proposal, I maybe could provide a wrapper around nicegui or so as starting point. Currently busy with work and then its Christmas, so it needs to fit inbetween a little, but I'd definitely be interested.

[a-teammate]

For a proposal, I maybe could provide a wrapper around nicegui or so as starting point. Currently busy with work and then its Christmas, so it needs to fit inbetween a little, but I'd definitely be interested.

Maybe it even makes sense to spin-off a dedicated project for adhering to this design pattern and keep it separate. Let's see, as always, time aka priorities are the problem.