keechma

Keechma stack. Mention @U050986L9 or @U2J1PHYNM if you have any questions
ferossgp 2020-08-19T09:00:43.058Z

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

mihaelkonjevic 2020-08-19T09:04:07.060100Z

@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

mihaelkonjevic 2020-08-19T09:06:23.062700Z

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

mihaelkonjevic 2020-08-19T09:07:38.063300Z

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

mihaelkonjevic 2020-08-19T09:08:17.064500Z

:keechma.on/start :keechma.on/deps-change and :keechma.on/stop are just built in events sent by keechma

ferossgp 2020-08-19T09:09:16.065800Z

Oh thanks! I missed that controller, that would perfectly work for my usecase 👍

mihaelkonjevic 2020-08-19T09:09:19.065900Z

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)

mihaelkonjevic 2020-08-19T09:10:04.067100Z

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

👍 1
ferossgp 2020-08-19T09:18:19.067600Z

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

👍 1
ferossgp 2020-08-19T09:20:09.067800Z

Overall I really like the approach with custom controllers like pipelines/entitydb!

👍 1
mihaelkonjevic 2020-08-19T09:27:51.068Z

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

mihaelkonjevic 2020-08-19T09:28:35.068200Z

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

mihaelkonjevic 2020-08-19T15:15:14.069Z

keechma/next realworld app - https://github.com/gothinkster/clojurescript-keechma-realworld-example-app

👍 2
mihaelkonjevic 2020-08-19T15:15:21.069400Z

this is a cleaned up version