Fork me on GitHub
#reitit
<
2018-06-12
>
ikitommi10:06:01

@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?

yogthos11:06:54

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

yogthos11:06:36

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

juhoteperi12:06:48

@yogthos What's the best information for kee-frame controllers? We have implemented our own controllers

yogthos12:06:52

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

yogthos12:06:06

I imagine most people end up implementing an ad hoc version of that for bigger apps

juhoteperi12:06:07

Is there a single controller per page?

yogthos12:06:18

yeah it's a controller per route approach

juhoteperi12:06:07

We use controller per "reitit layer", e.g. something like [root-controller users-list-controller user-controller] for /users/1

juhoteperi12:06:07

/users could use [root-controller users-list-controller] and then navigating to user route would only start the new controller (`user-controller`)

ingesol07:06:26

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.

juhoteperi12:06:33

I'll try to document this better when the code is finally ready

yogthos12:06:46

ah interesting, so this way you can chain them

juhoteperi12:06:14

It makes it really easy to share some common logic between pages

Scot14:06:00

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.

Scot14:06:59

I really like that approach because it means that you don't have to duplicate logic across many routes for shared resources.

Scot14:06:05

It seems like controller per layer could accomplish something similar, but the kee-frame approach seems more flexible.

Scot14:06:28

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.

ikitommi18:06:08

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}]]]

ikitommi18:06:55

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}]]

ikitommi18:06:01

transitioning from /orders to /orders/1 just calls init on :user-controller. Same gets destroyed if you walk back.

jcr18:06:09

Hey guys, just joined to say thanks for the great library (and great documentation too)!