D
D
Dmitry Spiridonov2015-02-06 15:19:41
React
Dmitry Spiridonov, 2015-02-06 15:19:41

Flux&&React architecture questions?

Good day to all. After reading articles on Habré about these technologies, I decided to try to rewrite the application for this miracle. But looking ahead, I immediately see several questions that I do not understand. Thank you in advance for any advice on them
1) In the very idea of ​​​​Flux it is sewn up that only the store (store) can operate with data, only it knows how to manipulate the data (as I understand it, of course I may be wrong). But here comes the question, let's say I have 2 separate components, and let's say clicking one opens the second component. In this case, should I pass this manipulation through the storage, create some kind of _isOpen flag in it, and hang up a changeListener, or can I pass such things through some common component of them?
2) How is data manipulated between repositories? Suppose I have 2 stores: dataStore, orderStore. When creating an order, I need to change some data in the dataStore. What to do in this case, can I inject the orderStore into the dataStore, or in this case, the chain goes like this: I catch an event in the view-controller that an order has been created, and immediately tell the dispatcher to pull the dataStore?
3) What about socketio? Do I understand correctly that he has a place in the view? that is, the view catches the socket and starts the traditional action->dispatcher chain... Or can I insert socket.on(...) into the store and immediately start changing the data there?
4) The question is rather debatable. It is impossible not to notice that you have to write many times more in React than in the same Angular. But the question is: how much longer does development on react take, in comparison with, for example, angular, ember?

Answer the question

In order to leave comments, you need to log in

1 answer(s)
A
Andrey Antropov, 2015-02-06
@spirAde

To begin with, I would like a couple of general words regarding Flux, everything will depend on the implementation of this architecture, what is offered directly by FB turns out to be too verbose and, looking ahead, the verbosity from point 4 is probably associated with this.
In my projects on React, I use the Refluxjs implementation of one of the most popular alternatives to FB.
I’ll build my answers as a comparison between the implementation of FB and Reflux
1. According to the classical scheme, yes, you need storage for this flag, in Reflux there is no central dispatcher and only really interested listeners receive events, so such things can be simplified and listen to just throwing an event like

mixins : [
  Reflux.listenTo(AActions.toggleOpen, 'onToggleOpen')
]

in which it is easy to make setState with new parameters, if there are more than one components that need to listen, it can be very easy to refactor to storage, thanks to mixins for storage, creating storage can be done in five lines of code.
2. The second idea is more correct, and it is in this form that it can be implemented in FB, for Reflux one store can listen to changes in the other and, accordingly, can, if necessary, change its internal state with the initiation of event
3. Not necessarily a view, just a code that initializes sockets , for the classics this is SERVER_EVENT, in Reflux you can directly hang an action as an event handler
4. It all depends on the implementation;) for me, the React + Reflux + Immutable bundle multiplied by pure functions is very concise and readable

Didn't find what you were looking for?

Ask your question

Ask a Question

731 491 924 answers to any question