This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # beginners (376)
- # cider (7)
- # cljs-dev (4)
- # clojure (96)
- # clojure-dev (7)
- # clojure-finland (2)
- # clojure-spec (1)
- # clojure-uk (15)
- # clojurescript (54)
- # cryogen (1)
- # defnpodcast (2)
- # docs (4)
- # emacs (1)
- # fulcro (2)
- # hoplon (15)
- # lumo (19)
- # off-topic (28)
- # om (3)
- # pedestal (2)
- # portkey (6)
- # proton (2)
- # re-frame (34)
- # reagent (4)
- # ring (3)
- # spacemacs (5)
- # unrepl (3)
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.
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.
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 (https://github.com/Day8/re-frame/blob/master/docs/SubscriptionInfographic.md) 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 (https://reagent-project.github.io/news/news060-alpha.html)
^ Yeah subscriptions are cached just make sure you only depend on the relevant inputs
@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.
@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.
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.