V1.37 - what's the way to create pages/routes that don't appear in the navigation?

Using Streamlit
, ,
1

Pre st.navigation we were using streamlit-pages which has hide_pages().

Afaik for a route to exist one must add the page to st.navigation but there no simple way to control which pages render in the nav.

2

I’ve had to set navigation to hidden and then build a custom nav to handle hiding pages while being routable. At least now the sidebar seems a little more flexible and page_link exits.

However, it’s disappointing that a new component like navigation is still being built in ways that isn’t flexible. coupling routing and navigation rendering is a bad design decision IMHO. I get it makes it a little more batteries included. But if this was built in a more composable fashion you should have been able to achieve the best of both worlds. And it would have saved me a bunch coding that adds zero value our app.

please please please stop wrapping several things into magic boxes that do a thing just “one” way.

1 Like
3

Hey @janaka, thanks for your feedback.

st.navigation was built with the strengths of st_pages in mind. So much that you can see st_pages now relying on st.navigation in the latest release by @blackary - hopefully you don’t experience any regression moving from one to the other.

I do think the new API has come to a rather composable state, since you can now:

  • create a page st.Page from a file or callable
  • run that page programmatically st.Page.run()
  • switch page programmatically switch_page
  • show a page button page_link

It seems like you’ve been missing documentation to help you “get off the magic track” to build your custom navigation, in particular through the client.showSidebarNavigation config parameter. Is that right? Did you happen to land on that related page Create a dynamic navigation menu - Streamlit Docs?

Or is there any missing feature?

4

I think I did come across the dynamic nav docs but mainly used the ones here Define multipage apps with st.Page and st.navigation - Streamlit Docs. The docs were sufficient once I’d figured I had to build custom nav.

we don’t use a config.toml. any server config is passed in a cli params. anything else is don’t programmatically. especially don’t want to control any app UI behaviour via a config file. anything we want to configure like server related, we only want to use env vars, that’s the one way.

used position=hidden to turn off the default nav. that needs all kinds of wrong as an API tbh. Back to my point about composition. I agree that Page and page_link are composable. But what’s going on with navigation?! that’s got at least two responsibilities: routing and nav UI render. those should be available separately IMHO.

5

That shouldn’t be a blocker, you may pass any of the params in config.toml as a CLI param, right

# config.toml
[client]
showSidebarNavigation=false

is equivalent to

$ streamlit run streamlit_app.py --client.showSidebarNavigation false
6

Wanna provide an API sketch of what you would have preferred?

7

yep, but don’t want to configure UI behaviour this way. We do precisely this for server stuff which. UI any UI related config we want to control programmatically. So as long as everything client related can be set programmatically all is good.

8

yeah, I’ll share something over the next few days.

appreciate you engaging on this :pray:

1 Like
9

Hi, sorry, didn’t get back to you, been slammed, still am.

Here a rough incomplete sketch to illustrate the idea of separation. In a nutshell it’s the established model in web frameworks.

page - all config related to a page. separate props for display title on page, browser title, browser description, URL slug, etc. don’t re-use a prop for unrelated cases (default sure but enable setting for granular control).

st.router.add(page.get_route()) - handle all the routing setup, adding page route to Tornado etc.

st.nav.add(page) or st.nav(page[])

st.nav internally sets routes e.g. calls router.add() for each page.

st.nav.hide_pages(page) - hides page in nav. doesn’t make sense to have a prop on page for this because page

A user should be able to build a custom nav with access to all the same building blocks as st.nav.

Hope that helps and makes sense.

1 Like