Response to https://twitter.com/fisherwebdev/status/526646648311906304

526646648311906304.markdown

This is a response to Bill Fisher regarding experience with Flux:

@abdullin Also, can you clarify what you mean by "solution structure"? I am thinking about revising the examples soon.

Currently all flux samples (that I've seen) group files into folders based on technical similarity. For example, stores go with stores, action creators reside in the same folder shared with the other action creators.

This pattern works quite well for smaller projects. It feels especially good for the sample projects of various MVC frameworks, when you have just a bunch of controllers, models and views.

However, as we discovered on some production projects, such approach doesn't scale well. At some point you end up with dozens of technically similar files per folder and logically messy solution.

1. Doesn't scale well.
2. While you work on a component, you have to suffer from extra context switching overhead (jumping between various folders).
3. Solutions become more "entangled" than needed.
4. More complex IDE features are needed to support the workflow (e.g. context-aware navigation and completion).
5. More merge conflicts, since it is harder to bound work by a feature (and communicate that).

We discovered that aligning solution with the domain model leads to a better design in the long run. E.g. we try to group files by their functionality or feature. This would mean, that different technical elements of a single feature could be squashed into one folder or onto one file. For example, for Flux we are considering to have a single folder for "News feed", which would contain all related action creators, fetchers and stores. Of course, there could be some other components that the this chat page would use (e.g. avatars, like buttons or user stores), such components would reside in their own folders. On the overall, such component decomposition is requires more effort than simply grouping files by class type. However, we value both the process (it leads to a deeper insight) and the outcome (solution that is more simple to think and reason about).

Of course, this is just something that seems to work only in a subset of cases I've been exposed to. There can easily be a deeper pattern which I fail to recognize.

Hi Rinat, Bill,

Thanks for these insights, they are very useful.

I was recently thinking more about actions/events in the past. Because I do love the idea the actions are outcomes of real-word processes and thus should be named in the past because they can't change. But I have some concerns about this, and I was wondering what you think about it.

Validating user input

At the moment my stores are responsible for the validation and I do something like this:

// action -> MESSAGE_SUBMITTED

messageStore.messageSubmitted(message) {
  if (invalid(message)) {
    setErrorNotification()
  } else {
    // do things in the store
    // deleteErrorNotifcation()
  }

  emitChange()
}

So it's possible that a message is not valid so submitted seems wrong here. It's only after the validation that the message really is submitted.

Failed on the server

An action can fail on the server, so, again, submitted seems wrong.

Possible solution

It's the responsability of the api (actionCreator) to call the server, and maybe also to validate the messages, so it would be possible to handle all things that can fail in the api and change my api interface like this:

for validation:

api.messageSumbit {
  if (invalid(message)) {
    dispatch('MESSAGE_INVALID_SUBMITTED')
  } else {
    dispatch('MESSAGE_VALID_SUBMITTED')
  }
}

with submitting to the server:

api.messageSumbit {
  if (invalid(message)) {
    dispatch('MESSAGE_INVALID_SUBMITTED', message)
    // Invalid messages are not send to the server
  } else {
    dispatch('MESSAGE_VALID_SUBMITTED.SEND', message)
    sendMessageToServer(message).then(function(result) {
      dispatch('MESSAGE_VALID_SUBMITTED.RESOLVED', message)
    }).catch(function(error) {
      dispatch('MESSAGE_VALID_SUBMITTED.REJECTED', message)
    });
  }
}

The inspiration for my solution came mostly from here: http://www.code-experience.com/async-requests-with-react-js-and-flux-revisited/

This has the advantage that all actions can be in the past again, but it makes the solution more complex. Furthermore, as soon as localstorage is added, that could fail too and that must also be taken into account.

On the other hand, syncing between localstorage and the server is not trival, so dealing with it explicitly wouldn't be so bad.

Is this the way you would handle this, or do you do this differently?

Hi Thomas,

Yes, this is essentially how I would do validation, but only if my validation was somewhat simple, like a regex to validate that the text looks like an email address.

However, if the validation requires me to examine the state of the stores, then I would want to move all of this to the store. If I was concerned about race conditions with the resolution of the API call vs. the current dispatch, I would manage that with a check to Dispatcher.isDispatching() in the action creator called from the response handler.

Keeping the validation and the API call in the action creator has the advantage of keeping action creators out of the store. The advantage of having the validation and API call in the store, however, is that application logic resides in the store along with state management.

See also: http://stackoverflow.com/questions/27363225/tracking-ajax-request-status-in-a-flux-application/27459732#27459732

Semantic tangent:
In our action types, we often don't have an agent or other details. They primarily have the form of OBJECT_VERB. There is no agent. In this case, the user has actually submitted the message to the application. They pressed the enter key on their keyboard. And this is what the action is saying about something that happened in the real world. The application has not submitted the message to the store or the API, but this is an internal detail. The results of an XHR may not seem like something happening in the real world, but I would argue that they are -- we become painfully aware of this while developing for the mobile web.

Hello Bill and Rinat,

I would love to read more enriching discussions like this. I have to admit that since the first time I saw Flux, it was really familiar to DDD & EventSourcing (which is a great concept in my opinion). This is my output for the discussion:

1. Store is something called bounded context in DDD terms, therefore it's quite common to duplicate state between multiple stores
2. Action represents interaction (be that a user's interaction or API callback) with the application and therefore it's something that happened in the past and there should not be any way to reverse it. (Rinat you have already mentioned it)
3. Action naming should always reflect what actually happened rather than expose implementation detail

I wish more developers would be aware of those points before they start using Flux in production, as it would lead to much cleaner design. Flux is really powerful weapon but can harm badly if it's not used properly.