5

Given I have an AJAX based search field that reacts on user input, requests search results from a backend via AJAX, shows the results in a dropdown below the search field, allows navigation through the search results via cursor keys and reacts on esc key presses in an intelligent way.

Since the current Backbone based component is broken in many ways, I'd like to reimplement that search component using React and maybe Flux architecture.

During planning it turned out, that my component has at least a number of 10 different states (maybe even more), it has to react to actions triggered by user inputs, and as well to actions triggered by asynchronous server responses.

Question1: Should I model all state in a store instead of a the parent component? That meant, that every user input changes the stores state, for example the :searchQuery, :searchResults and my parent view component reacts to that state changes?

Question2: Or should I model all state in the parent component itself and omit a store, dispatcher and actions completely?

Question3: Independently from handling state in a store or in the parent component itself, it turned out, that the component itself can have at least 10 different states, and there should only be a certain number of transitions allowed. Usually, I'd pull in a statemachine implementation here, model all :states and allowed :transitions and execute transitions everytime an action is received by the store or a callback method is called in the parent component. What is the correct React way to handle states and transitions between these states in a component?

Question4: Which is the to-go-state-of-the-art Flux implementation for Javascript? I have seen reflux so far, but I'm not sure, that's my poison.

I am open to all kind of suggestions here.

victorkt
  • 13,992
  • 9
  • 52
  • 51
GeorgieF
  • 2,687
  • 5
  • 29
  • 43
  • I have some similar questions. I have a form that doesn't get saved until the save button is clicked. Should I have the component mutate its state and only call an action when the store (or other components) need to know? Should the component notify the store every time the user enters input? Should the component have current state, and the store to be outdated until it should be pushed to persistence (or some more complex logic is needed)? Would that make the source of truth confusing? – DanCaveman Mar 19 '15 at 03:42

1 Answers1

1

I am building a similar component in React with flux right now and I have worked with Backbone extensively in the past so hopefully I give you some insight.

My guess is that your Backbone solution had a model local to your search view that built :searchQuery when the field(s) were updated. On the ajax callback you most likely just directly updated the :searchResults.

1-2:

With flux there ends up being a bit more boilerplate code, but in my experience if I don't build a store to start with I always regret it. That being said I would make a SearchStore for the :searchResults and keep the :searchQuery in the state of the parent component.

This way when you are ready to call your search you use a view action SearchViewActions.getSearchResults(:searchQuery) which makes the ajax call and in the callback calls SearchServerActions.receiveSearchResults(:searchQuery, :searchResults) and updates the store. Then your results component can listen for Store changes and call SearchStore.getResults() when it sees the change. This helps modularize the two sub-components, where as option 2 would tightly couple the two components and make it harder for outside component reuse.

3:

I like your solution of the state-machine, that you can just ask if you are allowed to make a transition and return a set of properties to update or a function to execute call setState({...}) based on that information.

4:

Reflux looks great, as it seems to reduce the boilerplate quite a bit. Reflux may or may not perform as well as stock Flux however.

Let me know how it goes, as your strategy may help me improve my structure.

Liam Maier
  • 171
  • 4