Need a bit more clarity on bindable_dataclass, ui context for session management integration

[git2212]

I've been going over the current docs/faqs/sample code and various posts here. I've considered breaking these questions into separate posts, but there are too many cross-dependencies and when considering application design approaches, these questions all have to be answered upfront.

Setting the stage:

As I understand it so far...It appears that

• using bindable_dataclass is the most efficient approach to support an MVC approach in a NiceGUI implementation.
• The docs indicate that the '@ui.page(...)' decorator allows for 'private' page spaces to be set up up (as opposed to the global state of auto-index page)
• There are indications from various posts that NiceGUI performs its own session tracking in the background although this functionality is not publicly/widely exposed but is likely related to the unique socket/wss connections it sets up.

... the mystery:

Given a true multi-user NiceGUI use case, a number of questions I am not able to find definitive answers to even after exploring all the rabbit-holes from the faq, examples and docs...

Q. What is meant by 'private' page in the Pages & Routing docs?... the concepts of 'private' and 'each user' is client (i.e. browser) context dependent and this can get 'messy' in a multi-tabbed environment in a hurry... how is this client-context derived?

Q. What is the correct way to use bindable_dataclass so that it is NiceGUI client-context (@ui.page...) aware?

Q. What is the correct way to integrate NiceGUI's client-context management with an overall 'session-management' which is external to NiceGUI (e.g. an OAuth/JWT custom framework)?... is there a way to bind NiceGUI's client-context to the broader 'session-context' which would not be considered a NiceGUI responsibility?

All answers will be appreciated!

[thevinchi]

Private refers to a page that has a client context. A client can have many connections which correlates to a websocket connection ID. Each browser tab has a single websocket connection (connection ID).

I maintain an app built with Nicegui using an MVC design pattern, where I maintain state in a Session class where each authenticated user has a single session_id. Nicegui provides a storage class with a user scope that has a one:many relationship with connections.

This allows you to store the user session information and reference it on each connection (tab) the user (session) has open.

I then have a data layer where I keep various instantiations of dataclasses with bindable properties that are bound to various UI elements. This allows you to have single instances of dataclasses with one or more bindable properties, that is represented in many instances of views across many users (sessions) and many connections (tabs) and/or you can map dataclass instances to single users and/or connections. It’s up to you.

The Nicegui architecture is quite remarkable. Especially when you then use regular python classes (with their own bindable properties) for your View layer, instantiated by your private page routes, so you can also maintain UI state for each view, for each connection, for each session.

I promise you, Nicegui has your back. You can be as granular (per tab, per user) as you need to be. Check out the storage class, where there are general, user, and tab storage scopes. Then have a look at AuthMiddleware in /examples (among others). I would share links but I’m on mobile and don’t want to gather them all up at the moment.

Happy to go deeper on any of these facets as needed.

[falkoschindler]

Q. What is meant by 'private' page in the Pages & Routing docs?

Private pages are re-generated whenever a user loads a page in a browser tab.

The only non-private page (at the moment) is the so-called auto-index page. This is the page which is populated with UI elements if you create them in global scope in your Python file, not within a decorated @page function. These elements are created once and remain accessible at the default endpoint "/" (if not overwritten) for every browser tab visiting this page. Because these elements exist only once, their state is share across all visiting browser tabs.

Note that we're planning to remove the auto-index page in the upcoming NiceGUI 3.0 for various reasons:
#4472 (comment)
#5005

Q. What is the correct way to use bindable_dataclass so that it is NiceGUI client-context (@ui.page...) aware?

I'm not 100% sure what you mean. But usually you define you model (e.g. a bindable dataclass) once somewhere outside of any page functions. Within page functions, where you have a UI context and create your UI elements, you can bind to and from the global data model. Whenever the model changes, all instances of bound UI elements will update accordingly.

Q. What is the correct way to integrate NiceGUI's client-context management with an overall 'session-management' which is external to NiceGUI (e.g. an OAuth/JWT custom framework)?... is there a way to bind NiceGUI's client-context to the broader 'session-context' which would not be considered a NiceGUI responsibility?

I have to pass on this one.
@rodja Can you answer this question?

[rodja]

What is the correct way to integrate NiceGUI's client-context management with an overall 'session-management' which is external to NiceGUI (e.g. an OAuth/JWT custom framework)?... is there a way to bind NiceGUI's client-context to the broader 'session-context' which would not be considered a NiceGUI responsibility?

I think our google oauth example is what you are looking for: the user data from Google represent the "external session management" and is bound to NiceGUI by storing it in app.storage.user. This makes the data available in every browser tab. If the storage does not provide the data -- or the data becomes invalid -- the user must repeat the login process. Of course, you could also store the data in app.storage.tab which would restrict the login to the current tab.

[git2212]

Thank you all for the answers!... will follow up on all the suggested links... it seems I have a bit of homework to do lol :)