[BUG] Upper limit for pages in a multipage app

Hi,

I have an app where I add pages via:

register_page(
    __name__,
    path='/xxx',
    order=n,
    name="yyy",
    title="zzz"
)

where everything works fine as long as I have only 10 pages, i.e., n = 0,...,9.

As soon as I add an eleventh page and n turns into a two digit number, the new pages is entered as the third one, i.e., the sorting becomes: 0, 1, 10, 2, ..., 9.
This can also be seen by printing the page_registry in the global layout where I generate the navigation bar.

How can this be fixed? Is this an upstream bug?

EDIT: The error could be the string cast here: dash/dash/_pages.py at dev · plotly/dash · GitHub

EDIT: Found a fix: replace the above line with

key=lambda i: (str(i.get("order", i["module"])).zfill(9), i["module"]),

which is a dirty workaround to prepend the order integer return with zeros to ensure correct sorting.

EDIT: Here are the upstream issue and pull request: [BUG] wrong sorting of registered pages by ordering · Issue #2564 · plotly/dash · GitHub and Update _pages.py - fix sorting for > 10 pages by gothicVI · Pull Request #2565 · plotly/dash · GitHub

3 Likes

I have not run into this particular problem, but I have run into the same behavior in other situations and the culprit is usually when an object that started as an integer, gets converted to a string. You can see that the order when n = “0”, “1”, “11”, “2” makes sense as a ordered list of strings. Maybe you can start by investigating how the page registry stores the values for n. Keep in mind that JSON requires keys to be strings, so if n was the key in a JSON it would be converted to a string.

1 Like

That’s literally the explanation I gave - also the fix is already merged :wink:

Sorry buddy, I stopped reading yours when I saw “dirty workaround”.

I guess my own workaround on that stuff has been to work from 10 to 99 - lots of page numbers available that way. Nice to know there is a fix though.

1 Like