0

I'm using ReactJs together with Flux. So I have views, action creators, a dispatcher and stores. I created a reusable search component that uses a 'searchActionCreator' (which calls a search API). Finally the 'searchStore' will receive the search results and will emit an event that the search component will act upon to display the search results.

The front-end developer who uses this component only needs to set some properties to define what to search for and pass a method (delegate) that will be called when a user selects one of the search results. I do not want to pass the search results to the search view from a parent component, because that would make it a little bit more complex to re-use the search component for something else.

Eveything works fine, as long as there only is one search component in every browser window. Because every search component registers an event handler with the searchStore, every search component will be triggered to display the search results when one of the search components made a call to a search API.

I can think of some options myself how to prevent this behaviour. E.g. I could set the state of a search component to 'waiting' after creating and firing the search action until the component received the results. Only components that have a 'waiting' state need to process a 'resultsReady' event from the searchStore. Another option would be to pass a unique ID of the search component togeter with the search query to the search action creator. The search store would need to supply this ID to all requesting search component, so that the search component can compare this ID to its own unique ID.

I can't imagine that I'm the only one person who encounters this challenge and that there must be some sort of standardized solution. I already read a good article on asynchronous requests, but haven't found an answer to this question in this article either. Any suggestions would be greatly appreciated!

Björn Boxstart
  • 1,098
  • 1
  • 12
  • 25
  • When there are multiples of components that really don't need a shared store, I think this is a case where a "store" pattern doesn't make sense. That's how I've handled something similar. I just had a component that wrapped the search and kept it in a parent container. It worked well and still abstracted the search component adequately. – WiredPrairie Apr 07 '15 at 22:23
  • @WiredPrairie I agree with you, but because we just started to implement Flux, I would not like to abondon this principle (even not for certain small parts of the total application) at this moment. Maybe we later will decide that this is the way to go. – Björn Boxstart Apr 08 '15 at 07:50
  • 1
    Ok. It's just a pattern. I consider the store to best represent data you would synchronize with a database (two-way). Anything more "state" and client only often doesn't fit the model. Even complex data and deep data models are challenging to build into a Flux store. – WiredPrairie Apr 08 '15 at 10:38
  • @WiredPrairie I'm triggerd by your last sentence '_Even complex data and deep data models are challenging to build into a Flux store_'. This now seems to be our biggest challenge. Do you have any suggestions or best practices to share? – Björn Boxstart Apr 10 '15 at 07:49

1 Answers1

1

The solution depends on the Flux implementation that you use. I would actually solve this by implementing the searchStore as a repository that supports multiple searches, the results indexed by some sort of unique component id string. Then I'd create an aggregate store (easy with Reflux) that filters the searchStore on a given component id string. So that way the components only interface with the aggregate stores to keep things simple.

  • +1 for bringing up aggregated stores. Although I do not need to support parallel searches, I theoretically wouldn't need multiple stores with search results at the same moment in time. But the method you describe would make it easier to bind only one component to every store (unless they share the same ID ofcourse). – Björn Boxstart Apr 08 '15 at 07:48