Refactoring and Determining Boilerplate Structure

[dillondesilva]

Keeping this issue to store ideas for how the application should be structured in the boilerplate. This will likely inspire any future ideas for the framework

Currently identified areas that need work are:

• requirements.txt is not up to date. Consider moving to python package management framework like poetry so future usage is automatically updated
• Auth design could be improved by moving existing components to their own class/module that is incorporated into the boilerplate

[dillondesilva]

Something I noticed:

Routing in this app is not structured and we should ideally take care of this in a boilerplate. The moment I moved one of the pages (Home.py) into a different folder, everything broke and I needed to fix the names. My suggestion for this is to build a feature into our framework to handle routing. Instead of doing st.switch_page("Home.py"), developers would call something like nina.router.push("\") in their code and our framework takes care of this

[dillondesilva]

Then similarly, all this authentication code can be bundled in the module nina.auth instead of Home.py. It is also starting to become apparent to me that this could be a substantial project - we may want to start with the following abstractions:

• nina.auth (for authentication)
• nina.router (for routing)
• nina.component (for component design of pages)
• nina.session (for cookies, local/session storage and all that jazz)