3 ms·
2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).
by toastercat 5y ago
2-way data binding is still a useful pattern with discipline, and still also common in React (using event handlers).
- eins1234 5y agoAny error-prone pattern can remain useful with enough discipline, but we've learned time and time again that relying solely on discipline to cover for error-prone patterns doesn't scale.
- toastercat 5y agoDefine "we". :) I understand this sentiment though, and I also understand designing a flexible system with zero footguns is nigh impossible. My point however was that two-way databinding is not rare in React, and there are other potential footguns to be had in idiomatic React anyway (hooks, React Context).
- deleted 5y ago[deleted]
- eins1234 5y agoI realized maybe we have different definitions of 2-way data-binding also haha... My objection is towards the Angular 1 style patterns where by passing some local component state to some children, you also implicitly allow those children to update it by binding it to some prop or by mutating it directly. This means the moment you need to share some piece of state, you can no longer reason about the state of your component in isolation nor control the ways in which it can be updated. This is at the core of what makes this approach so error prone IME. In React, state is passed from parent to children as read-only values for which direct modification has no effect (this is the "unidirectional data flow"). The only way for a child component to update the state of a parent component is for the parent to explicitly pass down a function that exposes that functionality as part of its explicit API contract with its children. Even in the worst case where we just naively pass down state updater functions directly (this is the case that's most similar to Angular-style 2-way-binding, which might be what you're referring to), this still results in state updates that are far easier to trace and debug as you can simply follow the function reference down to the call sites (instead of having follow all use cases of the state you passed down and trying to figure out which use cases bind or mutate). In the best case, it allows for components to offer only the minimum possible API surface to children by further restricting the set of possible state transitions (i.e. passing down openModal, closeModal functions, instead of the setIsModalOpen state updater function directly), and you can look at the parent component in isolation and confidently assert that no other possible state updates can possibly occur. FWIW I don't have much experience with Svelte, so can't speak for which approach it's more similar to. But when I hear 2-way data binding the Angular style is the first thing that pops up in my mind from all the PTSD, so if Svelte's approach is more similar to the React style then I have nothing to object to.
- awestroke 5y agoIt's never two-way in react. You're always in charge of updating the state in the event handler, which means you know where the update came from
- toastercat 5y agoNot to argue semantics, but that pattern is still called two-way databinding in my neck of the woods. In this deprecated page from the official docs, two-way databinding is defined as: > Two-way binding — implicitly enforcing that some value in the DOM is always consistent with some React state — is concise and supports a wide variety of applications. [1] https://reactjs.org/docs/two-way-binding-helpers.html https://reactjs.org/docs/two-way-binding-helpers.html
- awestroke 5y agoWell, that mixin has never been the standard way and has been deprecated for years (and for good reasons)
- toastercat 5y agoThe mixin is irrelevant to the point I was making. :) The point is that even the official React docs defines two-way binding as I describe it.