Fork me on GitHub
#helix
<
2023-10-18
>
Braden Shepherdson17:10:29

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?

lilactown18:10:27

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

lilactown18:10:43

(I googled "helix reitit" and found it)

lilactown18:10:56

FWIW I think react-router is very serviceable to use in helix

☝️ 2
Braden Shepherdson18:10:36

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.

Braden Shepherdson18:10:58

that looks like a solid example of using a context for this; I think that will work well.

hifumi12318:10:33

If you use refx then the re-frame example from reitit's repo can be reused

Braden Shepherdson14:10:04

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.

lilactown16:10:17

> it would be cool to support multiple router-powered containers why? I'm earnestly curious

Braden Shepherdson16:10:42

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.

Braden Shepherdson16:10:57

in the React world, I think the DOM diffing will just take care of it.

lilactown16:10:12

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

lilactown16:10:42

this allows you to also preserve local state in that outer component while navigating

lilactown16:10:32

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

lilactown17:10:32

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

lilactown17:10:41

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

hifumi12319:10:25

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

hifumi12319:10:52

but at the end of the day the frontend has one giant tree of routes that is built from merging data together

hifumi12319:10:01

i.e. a single router, not multiple routers