Fork me on GitHub

I've looked into using re-posh and datascript, but the effiort might not be justified. Very often a simple map is fine to hold your app data. There's likely complexity around when to load data into your store and when to refresh it. I'm currently using #kee-frame to manage that


I’ve been looking over and subsequently Wouldn’t we essentially be able to rid ourselves of the performance caveat if we had a way to subscribe without the cache-and-return call? Something called subscribe! or maybe subscribe-once which would behave exactly the same as subscribe in that it retrieves from cache if available and just returns (handler-fn app-db query) if not? Still a newb here so are there any problems I’m overlooking with this approach?


Yes. But it's unclear whether it's worth it. Well, to me at least. With the existing subscribe, the API is simple. And you also get a benefit of using the cache in the event handler if that sub has already been used in a view. The downside - having to rely on some external project, plus the (albeit small) overhead of caching something and removing the cache right after that if the sub is not used anywhere else.


The downside you describe would be the reason it seems worth it to me. We eliminate the need for 3rd party projects and the caching setup/teardown overhead. It really is just the same function minus one little function call right at the end. The work would be minimal and allow anyone to write their own injection interceptor without having to worry about the caching teardown. But you’d still get the benefit of accessing the cached value if it exists.


The overhead is not that big of a deal - it's supposed to be used in events, and they're not supposed to be fired that often for this overhead to cause any noticeable performance degradation. Having an additional function in the API - well, that's something that you have to support and document. And this particular concern about using a sub in an event handler is just one of many re-frame has, given that it's a popular library.


Besides, nothing prevents anyone from writing their own version of subscribe just as well.


Yeah, that is the solution I have in place for now… my own subscribe . It looks virtually identical which is what sparked the question. Appreciate the reply.


If there is a derived, computed value, which is used in many places, I'd be tempted to simply calculate it and then place it in app-db so that it can be easily accessed by both subscriptions and event handlers


The main argument against such an approach happens when this computation needs to be triggered on changes being made to multiple paths within app-db for example P1 and P2. That would mean we now need a mechanism to detect any change in P1 and P2 and then trigger the computation.


Subscriptions are nice that way. They run in response to changes at certain app-db paths. So they solve this problem which is why it is attractive to solve the problem using only subscriptions. But they are not the only way.


Often it is clear when P1 and P2 change (changes can only happen in event handlers) and so the computation could be done either in the event handler itself OR in an interceptor on that those event handlers.


There is an interceptor designed specifically for this scenario


Thanks for pointing this out. I think the convenience of subs is still more alluring than on-changes but I will certainly be on the lookout for more opportunities to use this. 🚀


@p-himik I haven't forgotten about your request for a universal interceptor mechanism. You have convinced me. I just need to get some time to make it happen


Sounds intriguing - is there a link to more context? /cc @p-himik


Or ask Isaac to do it. Maybe that's the most sensible way.


Anyways, i haven't forgotten. :-)

bmo 8