Fork me on GitHub

what is the best way to dispatch on state change? I have a subscription which is computed from multiple level subs... When the value of sub changes I would like to dispatch a handler.. Dispatching from sub seems wrong..


@nbdam: yeah this sort of question comes up a bit and is invariably driven by "old thinking". With re-frame, the only way that state can change is when an event happens.


The event handler changes the state in app-db


After that point the views are simply rednering the new state in app-db The subscriptions just feed that state through Dispatching from subs is definitely, absolutely wrong (and a sign you haven't quite made the right mental leaps yet)


Look instead to your event handlers (or maybe the middleware surrounding them)


@mikethompson: it seems that behaviour app behaviour depends on derived data which is produced by subscriptions. In this case derived data is not available in handler i guess


An event handler must have been told about the "change" which triggers the need the new date.


That event handler is responsible for ensuring the newly-required data is asked acquired.


Let me imagine situation. I have a line of 10 points. There's a subscriber which make an approximation for the line and may produce event if e.g. line has to steep turns. How do we handle this event? Or maybe this kind of logic is to complex for subscriber?


In re-frame: subscribers don't product events


Agree. So in my example calculation should be done inside handler and put in app-db?


That certainly one way of doing it.


There could also be a subscription which produces the boolean value as a function of the 10 points.


(register-sub :steep-turns? (fn [db [_]] ..... some function of the 10 points assumidely stored in db)))


So you'd be subscribing to a boolean which tells if there are steep-turns


The view, of course, has no idea where that data comes from.


It just subscribes to the stream of changes


The value MIGHT be calcualted and stored in app-db


Or it MIGHT be calcualated in the subscription from the raw 10 points


Yeah, that's totally understood. I was wondering more about the approach of doing it without storing calculated data in app-db.


@mikethompson: @nidu: good points... I will have to think how to structure this.... The derived state in my case can change in response to several event handlers. Encoding the same logic in subscription chain and in functions which would derive this data from handlers somehow seems like duplication. Perhaps in this case it will be best to restructure state to not derive it with subs but to calculate it immediately, store it in app-db, and dispatch further handlers if needed..


Just factor out the derived change into a function and call that function in each event handler


OR call this factored out function via enrich middleware


Or call this factored out function via on-change middleware


One of those approaches will fit


When an event handler changes state, you want that to trigger a further computation on app-db


Is anyone using both re-com and free-form? I like the automated form wireup of free-form, but its syntax conflicts with re-com's.

; free-form wants stuff like
[:input {...hash properties...}]

; re-com components are
  :key value
  :key2 value]
Is it possible to reconcile the two? Getting info back out of form fields seems like drudgery. Though at this point, I've probably spent more time doing things "the easy way" than if I had just typed more...


I'm actually doing fine without free-form, so I'm good, but if anyone has more insight, I'd still like to hear it!