Fork me on GitHub

Hmm.. I wonder how re-frame differs from react/redux in this case.


One of the things i find complicating about redux is that question...


You'd kind of like all state to be in the store, but the boilerplate becomes enormous in some cases...


So you might resort to middleware like redux-ui to handle ephemeral ui state in a manner that's more like angular scopes than like redux.


(But still winds up putting your state in the store for you)


And then there's state that should be entirely internal to the component, but we all know that React classes are deprecated, so we use recompose's withState and withHandlers higher order components, which are in a way pretty lispy, but...


Now we have several different mechanisms for handling state, and at least one is a bit tricky to understand.


And one doesn't put state in the central source of truth, so you lose something there.


And your code becomes much less regular.


At least at the layer that takes state and passes it to components.


Thank you for your input @mikethompson and @tagore


Can I dispatch events upon stuff changing in the DB? I have parts of the DB that depend directly on other parts of the DB and would like to have some way updating one thing when the other changes.


Specifically: items whose visibility depends on filters. I keep both the state of filters (on/off) and the list of visible items in the DB.


I think the reframe way to do this would be to have the visible items be a subscription, as it is derived data. You'd store all the items and the filter state in the db, then have a subscription for the visible items...


I expect the values to be read far more often than written though, which is why I’m lodging them in the DB. Caching, essentially. Is it still a better idea to have them as transient subscriptions rather than realized in the DB?


@henrik If you use your subscription in different layer ( it will recompute only if result of dependent subscription changed. In case you want to dispatch event when something happens to the app-db, you can use track function (


^ Yeah subscriptions are cached just make sure you only depend on the relevant inputs


Oh cool! Alright, thanks everyone. I’ll go with on demand calculations.


@henrik I'm not very experienced with re-frame (so grain of salt,) but I have worked a fair bit with discrete FRPish frameworks, and...


The thing is that data in the db shouldn't ever change except in response to a few defined circumstances.


When one of those circumstances arises you want to calculate an entirely new db state in response.


You have access to the entire db at that point in time, and can calculate how A will change.


So if B's value depends on A's value you an calculate what B's new value should be at that time.


Hmm- I put that rather badly, but hopefully you see what I mean.


@tagore Thanks for the input! This is tricky one. It’s somewhere in the middle: the read/write ratio is skewed enough in favour of read that I’d want to stick the values somewhere where I know they will not be recalculated every time I look at them. Still. they are derived values, principally ideal in structure for subscriptions, if not necessarily in terms of performance.


Well if I understand re-frame subscriptions properly they are memoized.


If B can be entirely derived from A (or A and C and D, which live in the db) there's no reason to put B in the db, and you shouldn't.


That's the mental model I use too but sometimes deriving data needs to call async browser APIs and I don't want subs to return promises so I'd occasionally have derived data in the DB with a note saying that it's updated automatically with an interceptor.... but yeah, subs are cached so reading derived values have next to no overhead.


If you need to make an async call that modifies the db then B is not purely derivable from the db.


And other layers of the application come into play.


It's still wise to separate them though.


Hard to talk about in the abstract though.


Do you have an exmaple?


It was a while ago so I'm not exactly sure, I think it was a data DSL -> JPEG function that had async calls.