4 ms·
So you're building business logic into your view components? This used to be simple in the old days when we used MVC.
by petilon 4y ago
So you're building business logic into your view components? This used to be simple in the old days when we used MVC.
- phailhaus 4y agoNo it wasn't, MVC was a mess because your views would trigger your controllers, which would propagate changes back down to your views in entirely unpredictable and inconsistent ways. With hooks you're still free to manage business logic elsewhere, it just means that you can trivially reuse them across your application without worrying about order-dependence. So I was able to write a hook that returned connection state, and then drove my views off of that reactively.
- petilon 4y agoI think you're thinking of MVVM, not MVC.
- orwin 4y agoWhich honestly was most SaaS products. My first internship was MVVM and killed my motivation to ever do web development. 9 years later my new work involves some react (barely 15% of the job tbh) and I really don't hate it as much.
- phailhaus 4y agoIt's MVC. Having your views driven off models is nice in theory, but a disaster in practice as the number of models proliferates. You lose control over how and when your views render, which results in all sorts of subtle and strange bugs that are difficult to debug. Each view may have its own logic for what to do when the model changes in specific ways, and what controller events to fire in response. Without unidirectional data flow, trying to even reproduce a bug becomes a nightmare.
- petilon 4y agoMVC is unidirectional.
- phailhaus 4y agoNope, not between views. View triggers controller, updates model, triggers some random set of views to update, which triggers controllers, which triggers other models, etc. There is no hierarchy there, nor any batching to avoid rendering inconsistent intermediate state. You have no control of how an update affects your UI. With React, data flows down from the top of the component hierarchy, always. And it doesn't render until all state changes have been made, so you only render after your data has reached consistency.
- petilon 4y agoIncorrect. In fact, you can use React as the 'V' in MVC. That's how it was orignally designed. See here: https://github.com/facebook/react/tree/015833e5942ce55cf31aefd0a5c2be8a65ec2daa https://github.com/facebook/react/tree/015833e5942ce55cf31ae... I am done with this thread.
- davorak 4y agoOne of my complaints about reading computer science and/or programming books in the early 2000(or late 1990s?) was the contradictory definitions of MVC in books I read at the time. I think one book even indicated that MVVM(I think) was often referred to as MVC as an explanation for why this happened. So it understandable people still have conflicting definitions. Here is a random example[1] I pulled up of someone one thinking MVC is not unidirectional but MVVM is. I am not commenting on the correctness of this impression. > MVVM is better than MVC/MVP because of its unidirectional data and dependency flow. Dependency is one way,... [1] https://dev.to/vtsen/mvc-vs-mvp-vs-mvvm-design-patterns-443n#:~:text=MVVM%20is%20better%20than%20MVC,app)%20are%20based%20on%20MVVM https://dev.to/vtsen/mvc-vs-mvp-vs-mvvm-design-patterns-443n....
- deleted 4y ago[deleted]
- Cthulhu_ 4y agoThe issue is that React was never (as far as I'm aware, please correct me if I'm wrong) encorporated into a full MVC (or similar) framework; its original intent was to be just the V, taking state (the model) and rendering it. But what happened instead is that people wrote the controller parts into React components as well. In some codebases there's a very clean separation - 'logic' components that handle and manipulate state, and simpler 'view' components that just take props and render something. But I haven't yet seen a framework that uses React as just a view layer.