Right now I use states to navigate different pages on my single-page app. When the page is loaded I typically pull the data from the URL into states so a user can start where they left off when they reload. This works great but is it the best way?
Have I created an unnecessary processing step? For example, pages, I use a Page state on the index as someone goes from one page to another. Conditionals display and hide pages accordingly. However, could I just make the conditionals based on the data from the URL, and cut out the middle step?
TLDR: Is there any reason I shouldn’t go from:
URL Data Tags >> Load date to State >> Conditional about state
to
URL Data Tags >> Conditional about Tags
Here is my current workflow setup to pull in URL info to states:
Using conditionals with initially hidden groups is the general approach I take with Sudsy Page as well, but I try to adhere to the DRY (don’t repeat yourself) principle. So, if there are multiple UI changes that should occur for a given page (or a specific view within a page), I might show a group based on the URL but then trigger other changes based on the visibility of that group (as opposed to referencing the URL again or creating a special boolean state).
States can certainly be handy, though, for storing the result of more complex logic used in conditionals (usually associated with longer nested URLs/routes), as you want to avoid replicating complex expressions. The idea is to keep things as simple, modular, and maintainable as possible.
