[krishanath]

>> it appears hugely over complex and unnecessary

Which it is, actually!

Think about how MVC works in iOS, or ASP.NET MVC or JSP Model 2, etc. In the case of the latter two, your state is stored in the session as simple, regular objects. Have you felt the need for actions and reducers and immutability etc. when using session state? I have not.

When programming JavaScript SPA, you can program in the style of MVC also. There is no need for actions, reducers and so on, unless your app is for example a word processor and you need undo/redo (as mentioned by another comment on this thread.) Most of the time you are getting data from the backend, temporarily storing stuff in memory, modifying it and sending it back to the backend. There is no need for actions/reducers and such other nonsense for that.

When I mention this someone always points me to the "you may not need redux" article by the creator of redux, in an attempt to legitimize some use cases of redux. There may indeed be some legitimate uses cases for redux. But it has become the de facto standard way of building React applications, and that's totally unjustified.

[lsdafjklsd]

In the apps that I've built, having many components manage their own private state makes it hard to coordinate said components, because all of the application state is stuffed inside different jars that you can't easily peak into.

It's been much easier to pull all app state into a central, db like structure, and allow components to connect and query that structure for whatever data they need. It makes making changes to components in the future easier, because all of my data is normalized in a structure, and it's all possibly available to any component in the app.

I've found that with MVC, if you design the private state a certain way, and in the future need largeish independent components to coordinate, well, you're going to have a bad time.

So redux or not, I'm definitely a fan managing state as it's own separate thing, and having components able to query and connect to that data structure, without having to pipe props down a tree of components, which leads to an app that's hard to change.

[zebraflask]

Agreed! Redux is cool but often overkill for basic CRUD apps, which the majority of JavaScript SPAs tend to be. My approach has been to take a long look at the app structure - if there's a way to refactor it to remove Redux (or what have you), that's probably the most sensible thing to do. Simple code > clever code where performance and maintainability are concerned.

I wouldn't mind a use case where Redux would be necessary or at least beneficial, for the practice, but I've yet to run across it after building half a dozen or more SPAs. These would be enterprise SPAs used in production, btw.

[newbear]

Hey, this is a bit tangental but since you mention building enterprise SPAs I'll guess your experience will be able to help me. So, I'm not as experienced but can get around to learning any code and as I need to start building a portfolio I dove in again to build one. But things were breaking and I couldn't get rolling as fast I thought and although for a longer term bigger project I would spend the time tweaking I want to get something up fast and thought that I need to use a simpler tool. So, I'm curious what to you use to build your SPAs? What's the process like for you? Thanks

[zebraflask]

The process stuff would probably be off-topic. But for something to get started with quickly, this is good:

https://github.com/kriasoft/react-starter-kit

Redux-friendly, too.

[beaconstudios]

MVC isn't especially easier than event sourcing (which is basically what redux is) once you get to larger applications. I think the two map quite nicely onto Fowler's design stamina theory (https://martinfowler.com/bliki/images/designStaminaGraph.gif) in that redux is harder to work with for small apps but the complexity scales linearly. MVC is easy for small apps but has a tendency towards spaghetti in larger codebases.

[krishanath]

>> MVC is easy for small apps but has a tendency towards spaghetti in larger codebases.

Disagree. There is no reason to believe MVC tends towards spaghetti in large codebases. Controllers and views implement a small portion of the application's functionality. When the applications get larger individual controllers and views do not even know that the application got larger, so this scales very well.

[arximboldi]

I disagree.

It doesn't because encapsulated mutation does not compose. Typical example: your data model fires signals notifying change as soon as you change them, then thew view updates. All good, until you have to build transactional updates and then you get flicker, broken invariants due to partial values being propragated, etc, etc. You need to understand how everything is wired up together to really know what is going on because effects are interleaved with logic, even when each component individually feels decoupled and nice.

What Redux/value-based data model does is to really separate those concerns. Your update logic is a function that just can mess all it wants with the new values it produces. It is composable because you can just build logic by calling smaller logical unit and you know everything you need to know by looking at the inputs and outputs.

It is way simpler (and less!) code in all but the most trivial of the examples.

[whitefish]

If your model layer objects are firing events you have problems already because it obscures the call graph. I try to avoid that style. The controller should update the model objects, then if a view update is needed it should be triggered by the controller not the model layer object.

[arximboldi]

Then your controller needs to know about 1) all existing views and 2) all effects of model update logic. Again, you end up with low decoupling with points that you can only change with global knowledge (and lots of potential effect interleaving). If you already have a "plain data" model, the next logical step is to just get rid of stateful controller and use a simple data-flow Redux-like flow for updating the UI.

I give in that the tricky part is finding UI frameworks that play nicely. You need something React-like to efficiently re-evaluate the Model -> UI functions, or use an immediate-mode API. Alternatively one can manually write some function to update a stateful UI by comparing the previous and current model and often it's enough. It is a bit like your controller but it is agnostic to the specific actions that happened but just look at the model changes (i.e. no global knowledge needed). I recently discussed this here:

https://github.com/arximboldi/lager/issues/1#issuecomment-34...

[whitefish]

Sorry, that’s not making sense. In the MVC I am used to there’s only one controller active at one time and that controller owns the entire screen.

[dceddia]

It scales well in theory, and as long as the devs understand separation of concerns, and keep on top of refactoring, and don't overcomplicate things with extra layers of abstraction.

I've worked on some Angular (1) apps that became very messy over time. I think it all depends on the project. React/Redux can get messy too.

[beaconstudios]

the things I find scale badly in MVC are primarily related to general OOP scalability issues - dependency hell, bloated classes, loss of separation of concern, and the big one being poor cohesion and state mutation propagation. I think my argument is broadly more like "OOP is needlessly hard", something that isn't really inherent to MVC.

[ess3]

I think the main problem is that MVCs aren't really a good way to write interfaces. You have so many state values that needs to be stored somewhere (dropdowns, input values etc). I'm not saying that redux is a good use-case everywhere but trying to write MVCs on the web is not a good fit. React is not a MVC library and not only the view part of it either...

[Scarblac]

Isn't that part of what MVC tried to solve in the first place, by giving every single UI element its own model?