A couple of weeks ago, I wrote a post titled, "On The Irrational Demonization Of Two-Way Data-Binding In Angular". That post was a reaction to the unfortunate degree of misinformation that I keep seeing and hearing about Angular. And, apparently this post struck a chord with the fine people over at Adventures in Angular (AiA) as I was subsequently invited back to be a guest on episode 224 of the AiA podcast.
| || || |
| || |
| || || |
On the podcast, I drew a delicious parallel to the Harvey Dent quote from Batman: You either die a hero; or, live long enough to see yourself become the villain. I think this translates perfectly to the world of web development:
| || || |
| || |
| || || |
Underlying all of this is a growing sense that as I get older, I need to take-on more of the perspective that life is just fascinating. And, that I have to worry less about what people think about my choices, and worry only about keeping my mind open to new opportunities and avenues of exploration.
I loved the Harvey Dent analogy. Glad to see the community recognizing your contributions and helping to get your voice out there!
Thank you, good sir. I had a blast - it's a great bunch of developers.
Let make it clear: Immutable pattern rely on the fact that it is the
only way to get an efficient change detection without relying on any
Software engineering relies on pattern and convention so why such a posture for change detection.
For instance, two way binding exists in the Microsoft world for a long time with success through the implementation of INotifyPropertyChanged interface.
As for many pattern/technics when things become complex you should master your subject to make it work right but after having used two way binding for 30 years on mission critical applications (real time, complex business logic, heavy computation…) I can tell that it works well and that it is quite less complex than immutable with redux.
Why relying on a common implementation/convention is bad?
With Angular I've been using OnPush Change Detection with two way binding over custom mutable entity without any problem.
The implementation is crystal clear and very easy.
The only constraint is to use a custom framework over json business model to get the change tracking: is it such a crazy choice ?
When I see all the pitfalls you have to solve with redux architecture when you need to target complex model (involving aggregation and relationship). I prefer to stick to good old recipe as "Two-way binding" over mutable entity rather to embrace a technology that implies an unnecessary complexity.
My 2 cents
I think we are in agreement. I love two-way data binding. And, like
you, I've grown to appreciate the
strategy so that we can limit the amount of work any component in the
component-tree has to do based on meaningful input-binding changes.
Of course, if you mutate data in-place, you just have to take into
account that it may not be picked-up by the
such, you just have to be careful about how / if / when you modify
in-memory data structures.
But, I agree that such considerations don't immediately require something more formalized like Redux or other stores.
That said, I am still trying to wrap my head around all the state-management stuff. I don't reach for it super often; but, I want to be able to use it properly when it makes sense.
I loved your Harvey Dent analogy, you're so right, and I'm right there with you.
It's exhausting. Not only am I worried about solving problems; but, now I feel like I have to carry a lot of emotional burden over my choices. Meh.