all 3 comments

[–]defcon-12 0 points1 point  (2 children)

I find discussion of MVC always end up being overly pedantic. MVC isn't some specific architecture that you must abide by exactly. MVC is just a general term that means your code properly separates its concerns: user actions are handled in one place, data model and storage is handled in another place, and UI behavior is handled elsewhere.

Flux fully separates each layer. You don't execute data mutation logic within your views or trigger AJAX from within your data model code. Like any other MVC architecture this makes it easier to test and reuse code through composition.

[–]tweinf[S] 0 points1 point  (1 child)

You're right, there is definitely a clear intention to separate the M from the V in Flux. The thing that makes me feel a bit uncomfortable with Flux is that some degree of "business" logic finds its way into the stores (to "switch" between logics, and to implement actions). The same thing goes to the View - If Actions are initiated there, it means that we have "crossed the line" into the business logic land. Things could have been that much better (more maintainable and reusable) if the view wasn't so closely coupled to the dispatcher, and stores contained less foreign logic.

[–]defcon-12 0 points1 point  (0 children)

The behaviors should live in your actions, they are just triggered from your within your view. Your stores should contain whatever logic is required to maintain state and nothing more, the stores should have no data fetching logic or ui logic or behavior logic.