This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2018-06-12
Channels
- # beginners (36)
- # boot (11)
- # cider (10)
- # cljs-dev (10)
- # cljsrn (3)
- # clojure (103)
- # clojure-greece (1)
- # clojure-italy (16)
- # clojure-nl (3)
- # clojure-spec (59)
- # clojure-uk (129)
- # clojurescript (125)
- # data-science (29)
- # datomic (30)
- # emacs (12)
- # events (5)
- # fulcro (61)
- # graphql (5)
- # keechma (3)
- # leiningen (9)
- # luminus (7)
- # onyx (26)
- # re-frame (3)
- # reagent (56)
- # reitit (25)
- # ring-swagger (16)
- # shadow-cljs (44)
- # spacemacs (4)
- # specter (2)
- # tools-deps (7)
- # vim (8)
@yogthos Thanks. Juho is pulling out helper code from our projects into reitit-frontend
helper module, minimal helpers to avoid the boilerplate of bootstrapping the routing. What is the api/Router
in you example?
ah yeah having a frontend modules is a good call, and we're using Reitit with kee-frame, so that's our implementation for the routing protocol in it https://github.com/ingesolvoll/kee-frame#using-a-different-router-implementation-since-020
as a side note, I can definitely recommend kee-frame just for the controllers alone, I find it makes routing much cleaner than regular re-frame events
@yogthos What's the best information for kee-frame controllers? We have implemented our own controllers
it's mostly inspired by keechma, the idea is that all the logic for setting up a particular page is managed in the controller, so when you hit a route you can do all the setup in one place
Is there a single controller per page?
We use controller per "reitit layer", e.g. something like [root-controller users-list-controller user-controller]
for /users/1
/users
could use [root-controller users-list-controller]
and then navigating to user route would only start the new controller (`user-controller`)
Kee-frame does something similar, only from a different angle. Each controller decides how to act on the route, just like keechma. So a controller for retrieving a user list can match on both /users and /users/1. The part about "did already match on /users, so don't have to call it again" is implicit in this case.
I'll try to document this better when the code is finally ready
It makes it really easy to share some common logic between pages
https://github.com/metosin/reitit/pull/62/files#diff-459dfe9940b6e1cea2a4bc2616c8cadd current impl & tests are in the PR
Just a slight correction on kee-frame controllers. They aren't tightly paired with specific routes. They each have a function on the route match. When the route changes the function is run. if it transitions from non-nil to nil, the controller calls it's stop fn. if it transitions from nil to a non nil, it invokes it's start fn with the non nil as params. if it transitions between two different non nil values, it calls stop then start.
I really like that approach because it means that you don't have to duplicate logic across many routes for shared resources.
It seems like controller per layer could accomplish something similar, but the kee-frame approach seems more flexible.
I think the key insight of the kee-frame approach is that controllers are for managing pieces of functionality depending on route, not for orchestrating the whole initialization of a particular route. This means that controllers can be far more declarative.
Both kee-frame and the one we have been using for reitit both mimic the excellent work by @mihaelkonjevic for Keechma. Here’s an example syntax of the one we have been using:
["" {:contollers [:root-controller]}
["/orders" {:contollers [:users-controller]}
["" {:name ::orders}]
["/:id" {:contollers [:user-controller]
:parameters {:path {:id int?}}
:name ::order}]]]
reitit flattens the routes so effectively there are two routes:
[["/orders" {:contollers [:root-controller
:users-controller]
:name ::orders}]
["/orders/:id" {:contollers [:root-controller
:users-controller
:user-controller]
:parameters {:path {:id int?}}
:name ::order}]]