Comment by geokon

I wrote my last message and then thought "oh gosh, it's so long, no one will read it". But I'm glad to find someone thinking about similar problems :))

> It's the middle ground: you opt-in to memoization where it matters, rather than having an engine track everything automatically.

What is the downside of just memoizing everything?

> you tell it what to cache and when to invalidate

I'd be curious to here more on this. I think the conceptual problem I'm hitting is more that these derived state systems (and this goes for a Pathom engine or a subscription model) seem to work optimally on "shallow" derived states. Ex: You have a "username" you fetch his avatar (one derived state) and then render it (maybe another derived state). That's fine.

But if now have a list of users... each has usernames and derived avatars and rendered images.. the list of users is changing with people being added and removed - this get mess.

With Pathom you can make username,avatar,render revolvers for the derived states. It's nicely decoupled and you can even put it in a separate library. With cljfx subscribers you can make subscriptions based on the state + username. It's more coupled, but you nolonger need an engine. Functionally it's the same.

But when it comes to the cache, I don't actually know any system that would handle this "correctly" - clearing cache entries when users are removed. Under the current solutions you seem to only have two solutions:

- You just sort of guess and make a "large enough" FIFO cache. You either eat memory or thrash the cache.

- Make Resolvers/Subscriptions on whole lists. So now you have usernames->avatars->renderings. This makes the derived states "shallow" again. If any entry is changed, the whole lists of derived states are recalculated. Memory optimal and fast to fetch (don't need to look check the memoization cache a ton). But if your list is rapidly changing, then you're doing a ton of recalculation.

I actually haven't worked with React directly, so I'd be curious to know how they propose dealing with this.

> if you do experiment with Pathom-backed GUI, I'd love to hear how it goes

Will do :)