Allow creating a new page per client

[falkoschindler]

Idea: ui.page can not only be used as context, but also accepts a Callable argument for re-creating the page whenever a client connects.
If the path if / or omitted, the page replaces the main page.

This is related to #6, where @me21 posted a draft for a PrivatePage, which I haven't looked into, yet.

[rodja]

Maybe the assumptions in #70 will break when this is implemented.

[falkoschindler]

I think it's ok, because dynamically created pages will create their content as well. So each UI element is still contained in exactly one page. At least that is what I'm having in mind. Separate pages with shared elements and state don't make much sense, since that's what regular pages already are.

[falkoschindler]

I looked into @me21's proposal in #6 and it seems very reasonable. Keeping all individual pages in a dictionary is an idea I haven't thought about. But of course, you need to keep track of which pages to throw away after its last socket is closed.

What I'm wondering about: What is actually the desired behavior, shared or separate state between tabs of the same browser? So pages are either referred to by session ID or socket instance.

[falkoschindler]

I experimented with an implementation of a "private page" and came up with two approaches and another variant.

1. Changing the behavior of ui.page if a new factory argument is passed.

   The idea is to call ui.page('/some_route', factory=some_page_factory). Whenever "/some_route" is requested, some_page_factory will be evaluated to create a new page instance.

   This turns out to be quite confusing, since the original ui.page instance is itself not an actual page. It has a route, but no content. And the result of some_page_factory has no route, but content. And an open question is: Should some_page_factory return a page or only create UI elements what will be automatically placed on the page returned by "/some_route"?

2. A simpler and possibly more intuitive approach would be to change ui.page only slightly for generating pages without routes:

   self.delete_flag = route is None
   ...
   if route is not None:
       jp.Route(route, self._route_function)

   Pages with route=None will be automatically deleted by JustPy and won't register a route. Now we can create a route ourselves that returns a new page instance:

   class PrivatePage(ui.page):
       def __init__(self):
           super().__init__(None, 'Private Page')
           with self:
               ui.label('private')
   
   jp.Route('/private', PrivatePage)

   We could add this to the documentation and leave it as a recipe, or build a wrapper around it. The latter would require to duplicate most of the ui.page signature.

3. Or we allow specifying a route when inheriting from ui.page:

   class PrivatePage(ui.page, route='/private'):

   This can be handles in ui.page as follows:

   def __init_subclass__(cls, *, route: Optional[str] = None) -> None:
       if route is not None:
           jp.Route(route, cls)

   Besides the other above-mentioned changes to ui.page there is nothing else to do. That's why I think I'd prefer this approach. I'll create a pull request as a basis for further discussion.

[rodja]

@falkoschindler I think approach 3 is also quite confusing. Most people do not now about parameters passed to classes. Also the page builder would have no obvious connection to the ui object.

What do you think about this API:

@ui.get('/plain')
def plain():
    return responses.PlainTextResponse(f'some plain text')


@ui.page('/private_page')
def private_page():
    ui.label(f'your private page {uuid4()}')


ui.link('show plain response', '/plain')
ui.link('open new page', '/private_page')

[rodja]

I created the branch #61-page-decorator for the decorator approach. I could only get it working with a dedicated function name @ui.private_page. It would be nice to use @ui.page or even @ui.get.

[falkoschindler]

Let me summarize the current proposals - my three + the one from @rodja + another one he came up with just now:

1. Add ui.page(..., factory=...).
2. Allow ui.page(route=None, ...) and creating a jp.Route in user code.
3. Accept a route argument when subclassing ui.page.
4. Introduce a @ui.private_page decorator (or even re-use ui.page or ui.get).
5. Replace the with ui.page context with a @ui.page decorator that has a shared: bool argument.

[rodja]

I have fallen in love with the 5th proposal. With the latest push to #61-page-decorator I introduced a breaking change: all pages must be created via a decorator (including the index page):

@ui.page('/private_page', shared=False)
def private_page():
    ui.label(f'your private page with uuid {uuid4()}')


@ui.page('/shared_page', shared=True)
def shared_page():
    ui.label(f'a shared page with uuid {uuid4()}')


@ui.page('/', shared=True)
def index():
    ui.link('shared page', '/shared_page')
    ui.link('private page', '/private_page')

I think using a context for pages was confusing from the start (see #50 for example).
Pages are fundamentally different from card, row, column,...

[falkoschindler]

@rodja I've created a new issue #85 for tracking the actual development of this feature. Let's continue the discussion there.