Fork me on GitHub

@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 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 which implements it’s own handle method ( 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


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


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


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

👍 1

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

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

👍 1

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


this is a cleaned up version