Appropriate routing setup (e.g. tabs and stack navigators)

[dancamdev]

I decided to use expo-router file based routing for the first time. I setup the project without worrying too much about the routing at all, time to fix that.

• From login we should be able to go back to connect
• From home we should NOT be able to go back to connect or login
  • A logout functionality should be responsible for that, maybe in the settings
• From settings we should be able to go back to home
• From libraries we should go back to home
• From series we should go back to libraries

[aaronleopold]

From home we should NOT be able to go back to connect or login

One thing to consider, I think the exception would be if my configured server is not reachable. It may just be because the server is down, or it could truly unreachable (i.e. out of network, whatever it may be), but it may also be that the server URL has changed and needs to be updated.

In the interface package, I went the two route option. There is a route for onboarding (for desktop only), and then there is a route for server connection errors. I abstracted the server connection form into a separate component, and use that for both. I believe onboarding is effectively equivalent to your connect screen in its purpose.

[dancamdev]

Great point, thanks for sharing, if there's a server connection error, I suppose the UserStore wouldn't return a valid user. If that's the case you'd be automatically redirected to the connect screen.

Might be worth considering some nice error handling to show the user what went wrong, but if my assumption above is correct the app should be resilient enough to handle it.

Onboarding is similar to connect apart from the mobile app asking you for the url. Once the user inputs the url the app it's doing a ping request to see if the server is actually there and then forward to the login or register.

[aaronleopold]

if there's a server connection error, I suppose the UserStore wouldn't return a valid user. If that's the case you'd be automatically redirected to the connect screen.

The only time I would consider it necessary to route to the connect screen would be:

1. No server URL has been set (i.e. very very first launch of the app)
2. A network error that suggests the currently set server URL is not reachable (e.g. this check)

However, this is assuming there is some sort of persistence setup for the URL itself. If the server URL doesn't get persisted somewhere on the actual device yet, e.g. if it is just local state at the top-most level, then I think what you described works perfectly (and is ideal) until then! The end goal would eventually be to not have to input the URL each time you boot up the app. Granted, I haven't had much time to thoroughly review all the progress you've made, so if I'm missing something let me know!

Might be worth considering some nice error handling to show the user what went wrong

💯 for error handling in general, but that can come after a POC if needed

Onboarding is similar to connect apart from the mobile app asking you for the url. Once the user inputs the url the app it's doing a ping request to see if the server is actually there and then forward to the login or register.

That's actually sort of what the onboarding currently does 😄 but you wouldn't see it unless you started up the desktop app currently (but it is actually commented out right now lol so even then I guess you wouldn't see it haha). It does essentially what you described, taking in a URL and then ensuring the ping sends the expected response before accepting the URL. Eventually, this URL will be stored on disk via https://github.com/tauri-apps/tauri-plugin-store, but for development it just lives in localStorage.

[dancamdev]

Totally Agree on persistence, it's something I want to work on sooner rather than later. It's a pain having to input url username and pwd every time. I'm a lazy guy 😂