Clojurians Log v2

I'm working through the video tutorials for Fulcro 3. It seems after part 7, the content becomes increasingly detailed. It appears to be like water from a water hose, as a beginner, or I just see the leaves, not trees, or the forest. I wonder if I really miss too much of the fundamental. Is there a better way to learn Fulcro 3?

The https://book.fulcrologic.com/#_partial_routes section is quite illuminating as I tried to implement my first nested route. I'm still not sure how to handle an "index" route, i.e., "/accounts" that would render a list of accounts, but then also support routing to "/accounts/<id>" to display a single account. The two solutions in the book seem less than ideal. The "never issue partial" routes instruction becomes difficult once you're trying to route from the window url (you end up with hacks https://github.com/lgessler/glam/blob/master/src/main/glam/client/router.cljs#L71-L73 and L133-147) The solution to pre-issue relative routing instructions at application startup also seems kludgy. In both cases you've moved a bit of the routing logic somewhere else. Couldn't a router specify an initial target? Something like

(defrouter AccountsRouter
  [this props]
  {:route-segment  ["accounts"]
   :router-targets [AccountsIndexPage]
   :initial-target AccountsIndexPage  ; <--- routed to when a partial route is received
   :always-render-body? false}
  (common/loader))

Indeed, I see the problem with the idea of an "initial-target", in fact this also affects the "pre-issue" solution. If I enter the page at /accounts/edit then click on "Accounts" in the navbar. If that navigates to ["accounts"] the rendered comp will not change as ["accounts" "edit"] is already active. I see why the author of the linked project above used the ["accounts" ""] convention to represent the /accounts route. Our URL path convention doesn't seem to map directly onto fulcro's composable dynamic routes

Right: The router is about UI routing, NOT URL ROUTING. For convenience a data structure (vector of strings) was chosen as it is simple to translate to-from a URL, but DR works on mobile, electron, etc. Mapping to URLs is a simple function away, and such a function can trivially transform paths. But also, why not use ["accounts"] and ["account" :id]. Doing so eliminates the overlap problem and makes perfect sense.

Don’t be so stuck on some way you saw it done in some REST app. Dropping an s isn’t a terrible leap or a cardinal sin 😄

one could easily argue it is even the grammatical thing that should be done.

But my general point it: don’t confuse convenience with design goals. The design goals of the composition in D.R. do not include “always maps 1-to-1 with a browser URL”. URL mapping convenience is a consideration, since often you can get the 1-to-1 mapping and that means you don’t have to maintain an external data structure that maps from URLs to UI routes, but it is also a design goal that you are able to refactor your code…Moving a route therefore technically changes the URL, which invalidates existing bookmarks…meaning that you might want old URL to new URL aliasing. That part was a design goal (that you be able to deal with it when you want a browser URL to point to route that no longer matches the UI path).

This latter consideration also solves the problem of “what if my UI route doesn’t match the URL I want?”