Closed samuelsimoes closed 8 years ago
That's not the idea of change
event?
Yes, you're right, yesterday I was thinking about this and today our internal events are a bit disorganized and the change
events can be triggered many times on some methods, example: setAttribute
that changes some attribute that triggers a computed property update triggers two changes. On other cases, like setStores
that can update many stores once many changes
may be triggered.
I'm working on an adjustment to organize the events, on this patch Fluxo will only trigger the change
event once per method that does some state mutation. I'll submit this patch soon with more information about.
Can be closed now, right?
Yes, I forgot. Closed by https://github.com/fluxo-js/fluxo/pull/36
Today our React connector (https://github.com/fluxo-js/fluxo-react-connect) is smart enough to collect all events on the tick and only call once the
React.Component#setState
on the next tick, avoiding a massive amount ofsetState
calls, but sadly the connector might lose this feature because this issue https://github.com/fluxo-js/fluxo-react-connect-stores/issues/4So I'm thinking that Fluxo needs trigger events around the methods that cause state mutations like
#set
,#setAttribute
and so on. This will give the chance to a lib like the connector only trigger an interface rerender when all the state dependencies were computed. This will specially valid to methods likesetStores
,addStores
and so on where these methods may trigger a lot ofadd
,remove
and other events.The name of these events coud be like
cycle:setAttribute:start
,cycle:setAttribute:end
and so on.