Regarding purging... I doubt you really need to but perhaps I'm wrong.
Certainly could be premature optimisation unless you really have memory
footprint problems.
On Tue, Feb 17, 2015 at 4:29 AM, Scott Nelson wrote:
> Thanks for the suggestions.
>
> So it sounds like in the my case the state is
Sounds pretty sensible to me.
On Tue, Feb 17, 2015 at 4:29 AM, Scott Nelson wrote:
> Thanks for the suggestions.
>
> So it sounds like in the my case the state is just a normalized store of
> artists, albums, and songs. Some portion of the app state would look
> something like:
>
> {:artis
Thanks for the suggestions.
So it sounds like in the my case the state is just a normalized store of
artists, albums, and songs. Some portion of the app state would look something
like:
{:artists [{:id 1
:name "The Beatles"}]
:albums [{:id 1
:artist-id 1
Hey Leon
It was really a matter of practicalities.
There doesn't seem to be hook to inject derived state into OM cleanly just
now. I have tried various other approaches and my code was much less
managable. This approach is proving really convenient.
One really strong win with this approach is
Can you elaborate why you implement a new IDeref? Why not just calculate and
pass the derived state during rendering? Memoization in any fashion could still
happen.
Also, is memoize-last just intended as an optimzation to consume less memory,
or does it serve another purpose?
On Sunday, Februa
My approach to this stuff is to think in terms of state and derived state.
I have a few helpers to facilitate implementing that which amounts to
- Use an atom for state
- Use a function to derive state
- Use a simple cache to reduce load of derivation in render loop
- Hack deref to ma
If they were changing, you could implement your own reference system, where you
have one stateful lookup map that you make globally available via a ref cursor.
Instead of the actual changing values, you'd use lookup keys in your rendered
cursors. Changes to values in the stateful lookup map woul
