Best practice: how do you use URL parameters single page app navigation?

  • renske.renske-1351514867881873408

    R

    1 month ago

    I have built a SPA and have just changed to a component based model. The setup was as follows:
    1. When the user clicks on an item in the menu bar, the URL parameter was updated (in my case, "view" becomes e.g. "budget").
    2. All content (titles, content, KPIs) belonging to this view (budget) is shown. The rest is hidden.

    Now, I have created a component for the view. The component 'Page' contains slots for all content. This way, I only have to hide/show on this Page component level (great so far!). I now have a Page component for each item in the menu bar, when a menu item like "budget" is chosen, URL parameter "view" is set to "budget", and the Page component for "budget" is shown.

    However, I have to set the "view" attribute of the Page component manually to be the URL parameter every time I use the component. If I set the value to be the URL parameter in the component, it does not work. The overall solution works, but it feels like there should be a better solution.. does anyone have a good idea?
    1351514868251103314-image.png
  • j.ulian4976-1351554287616000011

    J.ulian

    1 month ago

    Great idea to use this standardised slots! Like the simplicity of this single tree. Does remind me of an outliner. However I understand you want to improve... What I would do:

    I would wrap this 'page' component in a component called 'budget' etc. This way you can let your predefined attributes where they are. To be clear: in this structure you work on the component in isolation, so without your menu bar.

    At page level only show/hide is needed. This simplifies - if I understand your setup correctly - the need for setting multiple variable values for fields. Within the 'budget' wrapper component perhaps all attributes can be static (?)

    Also consider using a top level component for keeping global state, for values similar to attributes like 'modalOpen'.

    This is how I would do it, hope it makes sense. But you have to build in a way that makes sense for you.
    🫶1
  • lucasg-1351627517316042873

    Lucas G

    1 month ago

    This might be overcomplicating things a bit. You could just have a header/menu component that controls its own settings and then just have a "budget" component whose show/hide condition is "does path equal budget"
    🫶1
  • lucasg-1351627804797567036

    Lucas G

    1 month ago

    Then you can freely work on the "budget" component whenever needed
  • renske.renske-1352338940656615435

    R

    1 month ago

    @Lucas G I think that is more or less what I have so far - just that I have one component for all my pages. I like it because it gives me the same layout in all of the pages. Or am I getting you wrong?

    What I meant too is that now I am adding values into attributes that are always the same, like the URL parameters, or a flag from my API whether a user is flagged for beta or not. However, I need to push them from my main page into the attributes. Is that just the way to go or am I missing something?
  • lucasg-1352340087538454700

    Lucas G

    1 month ago

    That would be the way to go if you're going to use a component like that, what I meant to say was that it may potentially be an extra component that is not needed
  • 1352340219520749733-image.png
  • This is a similar idea to what you're building
  • The main page of an SPA where each of those components is a page of the app and its show/hide condition is controlled by page path params
  • In that example, main app has the header and a couple modals/components that are used throughout the app (like a toast component for example)
  • And it has a <main> element with a slot in which the other components go
  • layout is the same for all its child components that way
  • lucasg-1352341158965022790

    Lucas G

    1 month ago

    Page paths are shared via a context so if any component needs that data then it can easily access it that way
  • For example, an id to determine which project to show
  • lucasg-1352341759564189779

    Lucas G

    1 month ago

    In your case though, I assume the page wrapper has its own child components as well
  • When working in them you wouldn't need to set an attribute to change things unless I am missing something extra
  • lucasg-1352342541449695233

    Lucas G

    1 month ago

    It doesn't sound like you are doing anything wrong though to be clear. The direct answer to your question is, yes, if you are setting settings via attributes then you'd need to update them to see it reflect when working in the editor.
  • lucasg-1352343261662150797

    Lucas G

    1 month ago

    Sorry for the wall of text lol. I may not be understanding you correctly, in which case a video would help
  • renske.renske-1352344858362249315

    R

    1 month ago

    Ah that makes a lot of sense - that would make it even cleaner, I like it! Once I have my more urgent fixes done I will have a look at optimizing this :D. At some point this page needs to get launched haha - as perfect as I would like it to be.
  • Let me record a video to what I mean
    👍1
  • lucasg-1352350293492371628

    Lucas G

    1 month ago

    That helps. I had assumed each of those page components had child components of their own but that isn't the case
  • I would recommend considering having each of those views be their own components then it would make them a lot easier to work with
  • Then you don't have to toggle back and forth as you are doing in the video
  • As for the feature flags (premium feature, regular/beta user, etc.) I would personally use contexts to pass those down to whatever child component needs them
  • renske.renske-1352351006335307940

    R

    1 month ago

    Ok - will look into this! Thank you!!