React/Flux and xhr/routing/caching

Question

This is more of a \"whats your opinion/Am I correct in thinking this?\" question.

Trying to be as strict as possible while understanding Flux, I was trying

Answer 1

A few differences in my implementation:

1. I like stores employing a flyweight pattern. That is, unless forced to, all operations are "getOrRetrieveOrCreate"

2. I've had to forgo promise heavy development in favor of events/state. Async communication should still use promises, that is, things in actions use them otherwise communication occurs using events. If a view always renders the current state, then you need a state like "isLoading" to render a spinner. Or you need an event to get fired then update a state on a view. I think responding from an action with a promise may be an anti-pattern (not entirely sure).

3. URL changes fire the appropriate action. GET should work and be idempotent so a URL change should generally not result in a failure. It may however result in a redirect. I have an "authRequired" decorator for some actions. If you aren't authenticated then we redirect you to the login page with the target URL listed as a redirect path.

4. For validation we are thinking about starting from an action, firing a "xyzModel:willSaveData", before we start; then firing either "xyzModel:didSaveData" or "xyzModel:failedSaveData" events. The store listening to these events will indicate "saving" to the views that care. It may also indicate "hasValidationError" to views that care. If you want to dismiss an error. You can fire an action from a view that indicates that the error "wasReceived", which removes the "hasValidationError" flag or optionally could do something else like clear out all validation errors. Validations are interesting because of the different styles of validation. Ideally, you could create an app that would accept most any input due the limitations imposed by your input elements. Then again, servers may disagree with those choices :/.