Closed blackary closed 1 month ago
I'm a very big fan of this, because:
@blackary Any idea by when the lib will be updated with these changes?
@Sairam90 done :)
Thank you!..Will try it out !
@blackary I am not sure if I can reconstruct the section page structure without the in_section
attribute
I was using this to identify
1.pages which are not under any sections
2.find sections where all pages are hidden and hide the section as well in this case
Do you think this can be done with the exisitng attributes ?
@Sairam90 you can get the first one from get_nav_from_toml
and look for the pages that are under the entry ""
, which means no section.
For the second one, you can use the same function, and look for sections that have an empty list of pages.
The structure returned from that function should be something like that
{
"": [st.Page("home.py", title="Home")],
"Section1": [st.Page("page2.py", title="Page2")],
"Section2": [],
}
Ah,great,thanks again !🙂
Hey @blackary - If there is a page which is not part of a section between two other sections it is added to the section above it
toml sample_section_page.txt result result_get_nav_from_toml.txt
@Sairam90 Currently the only way to have a page not in a section is to have it at the beginning
cool..thank you!
Can you take a look at this question? https://github.com/blackary/st_pages/issues/103
Why?
st_pages was always created as an experimental way to improve on streamlit's built-in multipage app support. I wanted to have a way to specify the pages in my app in any order, with any icons, and with sections, without having to worry about where the files were located, or what they were named.
As of streamlit 1.36.0, these are all possible with native streamlit functions (and without the need to hackily manipulate internal cached dictionaries the way st-pages has always previously worked). To be honest, this makes me so happy, because these changes were partly inspired by the way st-pages works, and I'm so glad that more people like me will get to have this level of control over their page navigation without any 3rd-party tools needed.
There are still a few useful things that this library does that are small improvements on top of st.navigation:
But, switching to simply being a lite wrapper on top of st.navigation comes with the following benefits (in no particular order):
The Trade-off
The trade-off is that this means that st-pages 1.0 will NOT be a drop-in replacement for earlier versions of st-pages, but will be a VERY-breaking change:
If it was easy to keep the same basic API but using native functions, I probably would have, but, frankly, I couldn't figure out a way to make it work.
I'm very open to feedback on this from users of st-pages, but I'm fairly confident that this is the way I'm going to go.