Have you tried using / not using @ui.page?

[evnchn]

I just now read about the auto-index page in https://nicegui.io/documentation/section_pages_routing#auto-index_page as well as some interesting issues that are found only in it such as #4335 (if I read the PR and corresponding issues correctly)

Personally, I have never used the auto-index page, nor even figured out why one would want to use it. I use bindings (and worse case polling) for any kind of data update in the page, also for those that are shared.

Now, my ideas are not very creative 😅. In fact, it would be best if you can share your creations using the auto-index page in the comments below, or even better, in https://github.com/zauberzeug/nicegui/discussions/categories/show-and-tell

Coincidentally, I think this data will be useful in preparing for the next major update?

[rodja]

Thank you for starting this poll. The auto-index page makes NiceGUI code base (and many new features) so much more complicated to implement. When we started implementing NiceGUI a few years back we wanted to make it as simple as possible to write a minimalistic ui. Thats why we came up with the auto-index page-concept: simply import nicegui, put some ui elements and then run. We still use it for throw-away scripts. But your poll explicitly asks for "projects" which use auto-index pages. And that is very rare, I guess.

[falkoschindler]

@rodja Don't forget our ODrive GUI which doesn't use page functions. This project inspired us to invent NiceGUI to build UIs that run in the browser. At this time we didn't think about pages, but rather one canvas with one global UI state only.

[evnchn]

I recall how I stumble into NiceGUI:

1. Oh wow that's cool! Let me copy that example.
2. Proceeds to expand the project.
3. Finds out that the state is shared and cannot make subpages, not liking it.
4. After long searching, found out about https://nicegui.io/documentation/page
5. After making subpage using @ui.page, found out it behaves differently, more like flask (which I used in the past).
6. Have to relearn it.
7. Proceeds to migrate all code over.

So, in my mind, the auto-index page never served anything rather than lowering the initial barrier to entry, with increased effort down the line.

But, that is a bold claim to make, and obviously doesn't apply to everyone.

This is why my poll is a way to ask, if anyone doesn't feel the same on step 3, was satisfied / fell in love with auto-index page, and did not do steps 4-7.

[evnchn]

I also want to add that I joined using NiceGUI at 2.3.0, so no, I don't know about the past way of doing things. The more you know I guess!

But then, I may think the auto-index page has a hint of historical / technical debt to it.

But the NiceDeck and ODrive GUI are teo strong points, though.

[falkoschindler]

That's a very interesting question, @evnchn! We're discussing the pros and cons of the auto-index client regularly since it adds quite some complexity to the library code. But let me collect a few arguments for the auto-index page:

1. From the top of my mind there are some of my/our projects like ODrive GUI or NiceDeck that don't use page functions. Such apps are built around a common global state and it just makes sense to have a shared UI as well. When some ODrive parameter changes, everyone should see it. If the slide deck switches to the next slide, it should happen in all tabs if there is more than one watching.

2. Similarly, when developing native single-page apps, there is basically only one client. Using a page function would add little to no benefit.

Of course, such apps could certainly be implemented without the auto-index client. But this can be troublesome:

3. Consider a UI talking to some piece of hardware, e.g. a temperature sensor. Every time the sensor outputs new data, you want to update the UI. You can register some kind of event handler on_data_received = lambda data: my_label.set_text(data.temperature). This causes a UI element my_label being tied to a global long-living variable on_data_received. Therefore the garbage collector can't remove my_label. If used in page functions, this creates a memory leak. On the long-living auto-index page this isn't a problem because the UI isn't removed anyway.

And as @rodja mentioned:

4. An important use case for the auto-index page are small test scripts, short demos on our website, and pytest cases. I love the fact that you can share minimum reproducible NiceGUI apps with just a few lines and very little boilerplate code.

[evnchn]

Point 1: Glanced at the source code of NiceDeck. That makes total sense! How come I not think of that 😅

Point 2: But then, using a page function would add little to no trouble, as well. Let's not forget that by not using a page function, you are asking for trouble when want to switch to web server (change of minds happen quite frequently, trust me). So, in this case, the cons (future from migration to web, -0.01) are greater than pros (which there are none? 0). I'd say -0.01+0 < 0

Point 3: That's dangerous in my opinion. You should set the sensor to store the temperature into some variable, or even some text file (preferably in RAM, don't write to the SD card and burn out the wear cycles), and then the page elements shall then bind/poll against the variable. If the sensor interfaces directly with the text, then you can think you are bunding 50MB of RAM with the operation of updating an integer.

Point 4: If you read #4472 (reply in thread), I think it is hamstringing future development and expansion, especially when one does not have good understanding of NiceGUI yet.

[evnchn]

Extending further, I have recalled that I was asked whether I want telemetry for my Next.js project

Well, the computer that I was developing on back than was super slow, so I turned it off to potentially save performance.

But I could see how that would otherwise be useful to see which functions got the most love, and potentially have some automatic bug reports.

It could be a far far goal, but we can consider a similar approach. But, I think privacy is a top concern for this one.

[evnchn]

I'd also like to raise:

If @ui.page has missing features compared to the auto-index page, namely that does not have a shared state, then maybe we could do with the auto-index page not having an individual client reference in #4335?

[s71m]

I'm using a dynamic page routing system for my application. Is it auto-index page?

During application startup, the system scans all modules in the pages folder and registers them in a central registry. When user makes a request, the handler matches the URL path against this registry to locate and instantiate the appropriate page component.

@ui.page('/{path:path}')
async def dynamic_module_page(request: Request):
    path = request.url.path.strip('/')
    route = f'/{path}'
    pageinfo = pagemanager.get_pages().get(route)
    
    if pageinfo:
        try:
            module = importlib.import_module(pageinfo.modulepath)
            if hasattr(module, pageinfo.classname):
                ModuleClass = getattr(module, pageinfo.classname)
                ModuleClass(pageinfo=pageinfo, request=request)
                

[evnchn]

That is not the auto-index page.

Auto-index page refers to when you put stuff like ui.label() outside the @ui.page(), where it "hey I can't find what page I should be in. Let me just be at /"

By index, we don't mean "indexing", we literally mean "index.html"

---

from nicegui import ui
ui.label('Hello NiceGUI!')
ui.run()

This would be auto-index page.

[evnchn]

@falkoschindler should we title it to "have you tried using / not using @ui.page" then clarify "not using @ui.page = auto-index page"

[rodja]

From my point of view the simplicity of just writing a few lines of UI is the only real reason to keep the auto-index page (and hence the whole complicated concept of shared pages). Finally, in #5005 we are developing a compelling idea to define a single callback function as main entry point and make it almost as simple as the current auto-index page:

from nicegui import ui

def root():
    ui.label('Hello World!")

ui.run(root)

@evnchn hinted in #4729 that there are other reasons for shared pages. I'm not convinced that the benefits outweigh the technical trouble. For example:

1. shared clients do not have a request object
2. you can not get the ip address
3. need special cleanup logic for shared clients
4. it is very tricky to decide how implement ui.download (see UI events should provide the corresponding socket ID #4218)
5. the auto-index client has performance implications in multi-process applications because it must be created at import time (see Nicegui and multiprocessing calculation #4353)
6. you can not await javascript executions, connections etc.
7. startup handlers always execute in auto-index client context regardless of appropriateness
8. resetting the test environment requires layout hierarchy hacks (layout.parent_slot = None)
9. some elements behave differently on shared clients vs private clients (eg. drawer)
10. not all storage features are available with auto-index page

Therfore, I'm a big fan of dropping the auto-index client feature.

[falkoschindler]

11. SPA's are not supported on the auto-index page

And consequences of point 6 (no JavaScript calls) are

• no read access to the clipboard
• no read access for user data in, e.g., ui.aggrid, ui.echart or ui.json_editor

[evnchn]

Indeed the maintenance burden of the auto-index client is quite large. I never overlooked this point, and I made it clear in #4729 as well.

Ask yourself: Why doesn't FastAPI have an auto-index route?

Still, the need for synchronized elements exists, like shared presentations (NiceDeck), controlling a single hardware object (ODrive GUI), and generally speaking shared experiences (such as .io games)

Three important insights:

• Sure, but may or may not be the whole page, though.
• Sure, but may or may not be using the auto-index client, though.
• Sure, but may or may not be for all elements, though.

Wishful programming:

@ui.page('/')
def some_synchronized():
    with ui.sync_contents():
        everyone_input = ui.input('Everyone input')
        ui.label().bind_text_from(everyones_input, 'value')  # shared for everyone
my_input = ui.input('My input')
ui.label().bind_text_from(my_input, 'value')  # only for me

Then, we can in-fact block tricky elements or functions from being used withing ui.sync_contents() (such as ui.download, etc...)

Can the behaviour of with ui.sync_contents(): be achieved with existing elements? I'm thinking maybe ui.refreshable? But that's not quite the same as everything is refreshed in and out of the refreshable container...

[rodja]

I'm not sure we need another construct. We have long abadoned using auto-index pages for controlling hardware. It's fairly easy to create a "System" singleton which communicates with the hardware and then use bindings/refreshable etc to interact with that through a ui.page. ODrive GUI is just so seldomly used that we have not updated it. Similarly in NiceDeck a simple app.storage.general['slide_number'] could be used to sync the state to all viewers.

[evnchn]

Perhaps to get a feel for how life without auto-index page is, we can begin to modernize the examples?

Notably, I think the "chat app" would be most affected by it, since it heavily uses the shared client for the sync chat.

[falkoschindler]

Notably, I think the "chat app" would be most affected by it, since it heavily uses the shared client for the sync chat.

Actually it doesn't 😯

[hank880907]

I am a Robotics Engineer and I use nicegui to create UI for interacting with robotics systems. The concept of a shared state page (auto-index page) is absolutely a very useful thing to have, as usually the UI elements is representing some hardware. For my application, it will be valuable to be able to also mark other pages into a “shared state page”.
I think it might be worth considering to not enforce the auto-index page, but have a way to mark pages as shared state pages?

[BlankAdventure]

I personally enjoy the auto-index page option. I find it super useful for initial development, quick prototyping, that sort of thing. I wouldn't cry if it disappeared, but I like that its there.

[falkoschindler]

Thanks, @hank880907 and @BlankAdventure, for sharing your perspective! It inspired us to think about our plans for the auto-index client once again. Apart from a long list of problems with this feature (see #4472 (comment)), we identified three important aspects and possible solutions:

1. NiceGUI "scripts" (as we started to call them) are a great way to get started, to try out code snippets or to create a simple app that just doesn't need multiple pages. This is particularly interesting for people from the field of data analysis who are looking for alternatives to Matlab, Streamlit or Jupyter. But also NiceGUI beginners, who are copying snippets from existing online resources, shouldn't be left behind by enforcing page functions.

   A possible solution without the auto-index client might be to detect such NiceGUI scripts via UI element in global scope and to handle them differently in ui.run by wrapping the whole script in a page function using runpy. This way scripts without @ui.page will still work - the resulting page just isn't shared anymore. But we think that for this user group shared vs. private pages in an unnecessary distinction anyway. Running NiceGUI scripts in a "normal" private client increases consistency and avoids confusion when introducing page functions later. If startup performance is an issue, users can easily migrate to using a page function.

2. Synchronization with singletons is easy with the auto-index client because the UI is effectively also a singleton. So you don't have to worry too much about creating memory leaks by referencing short-living UI elements from a long-living data model or hardware interfaces.

   We think part of the problem is already solved: Binding UI elements to singletons already works because the binding module takes care of removing references when a client disconnects.

   But event-driven UI synchronization is more difficult: If you, e.g., want to add UI elements, show a notification or refresh a refreshable whenever a certain message is received over a serial bus, you need to register and unregister event handlers which is very error-prone. Our own robot system RoSys already comes with an event system that covers this use case. To simplify the work without an auto-index client, we're planning to move this event system over to NiceGUI so that both, binding and event handling, become equally nice to use.

3. Support for other shared pages has been discussed (and spiked, see PR Support shared client for routed page #4729). It would be counterproductive to remove the auto-index client while thinking about adding shared pages in the future. After all, the "shared" aspect is the most troublesome of the auto-index client.

   After a thourough consideration we agreed on not planning to support shared pages in the future. Assuming two browser tabs would show the exact same state of a page sounds like a intriguing feature, but is flawed in many ways: The viewport in 2D plots and 3D scenes is not syncronized, some elements like ui.aggrid can have local user input that is not synchronized, ui.select popups are not in sync, ... Let alone all above-mentioned features like user storage, ui.sub_pages, ui.clipboard, ui.download, await ui.run_javascript, ... that are conceptionally hard to synchronize.

   Consequently, shared pages would always be a tradeoff that complicates the code base and potentionally confuse our users. Instead of fighting this battle, we rather invest our time and effort in powerful tools to synchronize state with private pages.