question: managing UI state in a fluxible implementation about fluxible HOT 6 CLOSED

Typically, we would fire an optimistic update to display the UI as if the XHR succeeded or show a loading screen while the XHR call is in progress. You can see an example of the events being fired in our ToDo example. The UPDATE_TODO_START triggers the store callback, which can modify the store state and notify the component.

from fluxible.

In other words… moving UI state into the store?

On 3 Feb 2015, at 11:53 pm, Seth Bertalotto [email protected] wrote:

Typically, we would fire an optimistic update to display the UI as if the XHR succeeded or show a loading screen while the XHR call is in progress. You can see an example of the events being fired in our ToDo example https://github.com/yahoo/flux-examples/blob/master/todo/actions/updateTodo.js. The UPDATE_TODO_START triggers the store callback, which can modify the store state and notify the component.

—
Reply to this email directly or view it on GitHub #34 (comment).

from fluxible.

Yes, you would have an application store or something similar that could manage the state.

from fluxible.

This seems like a terrible way to handle UI state. May be a better approach is to have UI listen for these events directly in the dispatcher ?

from fluxible.

I keep all state in stores. If it's something ephemeral (e.g. it doesn't affect anything else) I'll wrap my controller component with an automated one.

from fluxible.

@cesarandreu could you show me an example of that? gist?

from fluxible.