This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2023-10-18
Channels
- # announcements (12)
- # babashka (6)
- # beginners (62)
- # calva (3)
- # cider (41)
- # clerk (5)
- # clojure (192)
- # clojure-bay-area (1)
- # clojure-europe (14)
- # clojure-norway (97)
- # clojure-uk (6)
- # clojuredesign-podcast (4)
- # clojurescript (30)
- # code-reviews (7)
- # cursive (32)
- # datahike (4)
- # datomic (35)
- # docker (8)
- # emacs (8)
- # events (1)
- # fulcro (13)
- # helix (19)
- # hoplon (4)
- # hyperfiddle (37)
- # jobs-discuss (10)
- # membrane (11)
- # missionary (19)
- # off-topic (28)
- # polylith (8)
- # portal (10)
- # practicalli (8)
- # re-frame (31)
- # reitit (6)
- # shadow-cljs (39)
- # timbre (3)
- # vim (1)
- # xtdb (6)
I've been using helix with success! but I'm wondering about the best way to integrate reitit or a similar routing library, such that the current route info is available as a value to components, and a route change is properly reactive. reitit's frontend examples tend to use an r/atom
, but there's no obvious counterpart in helix.
should I use a vanilla atom and listener with use-state
? put the route in a React Context? something else?
here's an example I found, not sure if it's the "right" way to do it necessarily https://codeberg.org/madoka/helix-ssr-demo/src/branch/master/src/demo/router.cljs
I have reasons to want the data-driven approach of something like bidi or reitit; the routes might be handwritten and they might be generated.
that looks like a solid example of using a context for this; I think that will work well.
closing the loop: I got this working nicely based on that example. the router being global is unfortunate, but it's hard to avoid in the browser. it would be cool to support multiple router-powered containers on the page at once, but that's an advanced feature I can ignore for now.
> it would be cool to support multiple router-powered containers why? I'm earnestly curious
actually, maybe that's a non-issue in a React world that I've unconsciously imported from Angular land with its horrible stateful components. in that stateful context, sometimes the skeleton of the page is common to all/many routes, but a few pieces of the page (sidebar, top, main content) change based on the route. in that world, it's handy to avoid tearing down and rebuilding the skeleton, and to instead have multiple bits of the page that react to the router.
in the React world, I think the DOM diffing will just take care of it.
react-router is very good at this. it has a concept of "nested routes" which share the same outer page component which renders a special Outlet
component where the nested part will be placed
this allows you to also preserve local state in that outer component while navigating
you're right though that it won't go and destroy the entire page and recreate all the DOM elements on every navigation, just the parts that changed
BTW react-router is pretty data-driven, at least in the way you define routes (similar to reitit). See https://reactrouter.com/en/6.17.0/routers/create-browser-router
anyway I'll stop shilling for react-router :^) I'm migrating from secretary to react-router after considering the alternatives, so it's top of mind, but there's many different ways to skin this cat
i use reitit with refx and it has everything ive needed. i (ab)use the fact that routes can be composed from data in several different parts of the app. i do this to help with code splitting and keep admin routes separate from "normal" routes