This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-08-19
Channels
- # announcements (4)
- # asami (1)
- # babashka (48)
- # beginners (84)
- # bristol-clojurians (1)
- # calva (15)
- # chlorine-clover (11)
- # cider (37)
- # clj-kondo (17)
- # clojure (72)
- # clojure-europe (13)
- # clojure-italy (43)
- # clojure-nl (6)
- # clojure-spec (8)
- # clojure-uk (19)
- # clojuredesign-podcast (7)
- # clojurescript (132)
- # code-reviews (7)
- # conjure (3)
- # cursive (24)
- # datascript (10)
- # datomic (61)
- # docker (4)
- # duct (24)
- # emacs (2)
- # figwheel-main (8)
- # fulcro (43)
- # graalvm (5)
- # juxt (1)
- # keechma (14)
- # malli (2)
- # off-topic (120)
- # re-frame (111)
- # reagent (6)
- # reitit (13)
- # shadow-cljs (118)
- # spacemacs (3)
- # tools-deps (32)
- # uncomplicate (5)
- # xtdb (6)
@mihaelkonjevic in keechma-next, when we derive a derived controller we can define for the second order controller the prep
and derive-state
methods, but not handle. Is this by design?
For example here https://github.com/retro/keechma-next-realworld-app/blob/master/src/app/controllers/article.cljs
If I would like to do some mutation on :article
, I create a separate controller to do that, cause handle is not called. What's the preferred way for that kind of actions, when I want to pull data from the pipeline and then work with it?
@ferossgp So, in this case the key is derived from :keechma.next.controllers.pipelines/controller
which implements it’s own handle
method (https://github.com/keechma/keechma-next-toolbox/blob/master/src/keechma/next/controllers/pipelines.cljs#L67) to work with pipelines. If you want to have your own implementation of the handle method you need to define it for your own key, but then it won’t have the default pipeline controller behavior
This is not a limitation in keechma, but in a way how the pipeline controller is implemented. Since the implementation is pretty simple, the idea is that you would create your own controller and pull in the behavior from the pipeline controller file. What I should probably do is extract all code from handlers to normal functions so you can easily re-implement pipeline controller with some extra features
or you can just add extra pipelines and then dispatch those events to the controller like here https://github.com/retro/keechma-next-realworld-app/blob/master/src/app/controllers/user/user_actions.cljs
:keechma.on/start
:keechma.on/deps-change
and :keechma.on/stop
are just built in events sent by keechma
When you use pipeline controllers, whatever event is dispatched to the controller will be handled by a pipeline (if you have a pipeline registered on that key)
I’m actually finishing and cleaning up the realworld app right now, and I plan to record a video with the architecture walkthrough, so if you have any questions, please let me know so I can answer them in the video
I'm still just experimenting by looking at realworld and trying implementing something based on the examples. One more thing that comes to my mind rn, when we mutate the entity db, all controller which depends on it, will trigger their active sub on and execute pulling, would be interesting to see if we can have some cursors like cache, so only subparts will trigger. I assume it can be done with nesting controllers and to get as params sub-parts instead of the whole db, but I haven't tried yet
Overall I really like the approach with custom controllers like pipelines/entitydb!
You’re right that changes to entitydb will potentially cause checks to a lot of controllers. But I don’t think this will be a big problem in practice. I’ve analyzed apps that we’ve built in the last few years, and the number of controllers is not that big. In keechma/next, you will probably never have more than 10 - 15 controllers running at once. If your app has a lot of features, you can group them into subapps - they serve both as a performance optimization, and a cognitive optimization - you just don’t care about anything that’s not needed for the current screen. This is the same bet that the React team did - there is a limit to the things that can be rendered at once, and that limit is on a human side, you just can’t put too much stuff on the screen at once. For the use cases where you need to render a huge amount of data frequently- for instance trading tickers or any live dashboard, you’ll need to come up with a custom architecture anyway. The goal is to have a really good experience for 90% - 95% of problems, and to provide escape hatches for things that don’t cleanly fit into the architecture
Also, I would notice that this is the same problem any reactive system will have (e.g. Reagent), it’s just more visible here because dependencies are explicit
keechma/next realworld app - https://github.com/gothinkster/clojurescript-keechma-realworld-example-app
this is a cleaned up version