Fork me on GitHub

@mattly I've seen this question asked here quite a few times and it took a while for me to find it in the documentation too.


Maybe it should be mentioned earlier in the documentation, or the "Builtin effect handlers" section should be moved above the navigation bar?


Hi! I'm currently building a dashboard-like web-app, which has a sort of "personal public profile" for any person registered on it. The relative URI (using Secretary) for any such profile is then /person/:person-url-slug. I want to have anchors to sub-views of the profile (e.g. /person/person-url-slug/general), and thus need to have access to the person-url-slug in one of the child-components. Now to the actual question, is it a "bad" idea to have a map in app-db, which is used to hold any data associated with the current page/view, in this case, the peron-url-slug? I'm thinking I could also have specific maps for each page, but that means I have to be doing a lot of manual cleanup when changing the page, right?


@wielderofmjolnir: Two of the basic options I can think of right now - ask for clarification if it’s needed - Add a current-person key to your app-db, and update that with the relevant data whenever you change people. Then your child components can subscribe to that data and get access to it. - Add the data that each child component needs as a property that is passed in when they are used - then they can be plain reagent components and you only have to worry about the data your main view needs. I’ve use both of these in different places, and they’re pretty easy to use and don’t add much overhead if they fit with the rest of the needs of your application. Is all that you need access to the person-url-slug from the URI?


Hmm.. I was thinking option #1 but the problem is that I want to use these url-slugs for anchors in a "second" navigation bar, which potentially changes for each view. I have a Reagent component which is tab, and then I'm storing a map of available-tabs (key being the identifier of the tab, and having a map as val) in app-db. So I have a variable length vector with information for each tab, which one is active, etc. This means that for every different page that might have something similar, information I want from the URI, I would have to store it as a key, val in app-db. I might end up being a bit too much? I don't think I can do option #2 since I'm dispatching a :set-view event in the defroute, so there's really no way for me to access the data before rendering the top-bar, right? Option #3 would be to store the URI path, and parse it everytime I want to extract data from it.


@wielderofmjolnir: I would store the current URI path, possibly along with some of the parsed URI data that you care about (depending on what makes your code work better) - you could just have a root uri key with a map {:full-uri “ “ :person “ “ :something-else “” } or something along those lines. Then you can just add that as a subscription or pass it in as data to any component throughout your whole app.


That sounds like a good idea! 🙂 Thanks a lot! Really do appreciate you taking time to help me out!


@wielderofmjolnir: No problem, keep asking questions as you have them


Could I one more right now? 😄


The :ul is of course within another Reagent component 🙂


Should I create these ids manually? Or do they need to be unique in the entire DOM?


Also, I'm using square brackets, not parenthesis when calling tab, but I tested using parens just now


If you change your code to

	(doall (map (fn [[tab-kw {id :id title :title}]]
                  ^{:key “unique-prefix”} [tab id title (= @active-tab tab-kw)])
Then your warnings will go away.


For the unique prefix, I usually use some combination of the calling component and the ID of the data in the doall block - I’ve always assumed the ID should be totally unique but I could be wrong on that. And using square brackets will save you some other problems.


Not sure if it’s necessary for the react ID to have square brackets, but it’s general good practice unless you know exactly why you don’t want to use them.


Ah, cool 🙂 Thanks, once again! 😃