Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I've been against mixing logic and views for the longest time and I still wouldn't mind if separation would have been introduced, but recently I gave up.

Either I'll be unnecessary stubborn and miss this awesome new tech or I'll shovel my opinion aside and do try working with this approach.... or at least until someone else introduces new framework that comes with code separation.

It's not the end of the world.



The react philosophy of the world is that mixing mutable state and views is bad, logic and views is fine. To be honest this makes a lot of sense to me as a functional programmer.

After learning react something conked in my brain. As I rehashed the arguments against logic in views, I realized that they recapitulated FP's arguments against uncontrolled mutable state, just without the nuance. Nothing wrong with purely functional logic/computation itself. And that delineation feels a lot less arbitrary than "logic in views is bad".

To be clear, I'm not arguing you should implement domain logic in your views. That's a dumb strawman.

But the religious fervor that people have against logic in views is absurd. Reexamine why you think logic in views is bad, and I think you'll find the arguments are actually against 1. poor factoring resulting in ridiculously complex views (and hiding logic is a halfass, crappy way to control complexity) or 2. mutable state.


Are user triggered events for a view part of the view, or something else? I think this is where such a separation of concerns comes in... a view is more than just how it is rendered, it is also events for the view. There are also child components, and handling these events, or encapsulating them into events to be triggered by a given view.

When you think of it this way, it makes sense. From a designer perspective it doesn't, and you have to adapt designs into a view, just the same, you usually do anyway.


I think you've got it exactly backwards. Events are not part of the view.

Events happen to be triggered by the view and they affect global state which is then reflected in the view.

This is the separation of concerns you want. Components don't need to know about events beyond triggering the ones they need. Components only worry about rendering state.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: