2 ms·
Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files wh
by lhorie 6y ago
Not necessarily. Discoverability is a function of colocation, not of immutability. One can write convoluted Redux monstrosities spanning a multitude of files where it's difficult to mentally follow how a dispatched action translates into state deltas (potentially because of too much higher-order abstractions, but also because one action may affect multiple reducers, and that in turn may affect a multitude of React tree nodes because Context or whatever). Svelte reactivity generally only staying within a single file (with some exceptions) is one approach to align system limitations with "pit of success" in a way that happens to use explicit mutation idioms.
- nsonha 6y agocould you stop saying redux, in my other comment I said the solution could be anything from react's setState to old-style encapsulation. The point is, it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature". It's a thing that you do very conservatively at best.
- lhorie 6y ago> it's kind of odd that someone'd put mutating states in their tutorial proudly as a "feature" Mutating state is actually the de-facto standard across most of the industry. Look at Vue or iOS or Android or Unity or Rails or J2EE... People literally use ORMs to make things more mutable than SQL. Yes, you can use React setState, but surely it's not lost on you that this is wrapping over a lot of mutable operations too? Worth mentioning as well that setState semantics have some amount of complexity that is attributable to mutability leaking out of the immutability abstraction (e.g. the callback argument, what happens when things like multiple calls to setState occur synchronously, etc). This is the "curse of abstraction" that comes when you are trying to implement semantics that don't exist natively and the abstraction themselves have semantic weaknesses due to the chicken-and-egg problem of the required semantics not existing natively.
- nsonha 6y agoagain with the mechanical definition of mutability. Ok "controlled" is the word, as I mentioned in other comment state encapsulation (which ORM is) is another solution for this.
- nsonha 6y ago> Discoverability is a function of colocation, not of immutability That's one way to do it, tying discoverability to coding convention (which is usually how collocation is enforced), as opposed to being an inherent property of the code.
- j-krieger 6y agoThese giant monstrosities are really easy to avoid. Redux Actions make locating a state change a breeze. I have worked on giant applications that did not use a redux-like approach to state and it was a horrendous mess.
- rsuelzer 6y agoI think it's easy to get into a mess as an applications complexity increases regardless of which state management approach one chooses. Every paradigm has a trade off.
- lhorie 6y agoFWIW, I see a lot of codebases at work (I maintain a large org-wide monorepo), and you'd be surprised at how daunting real world codebases can get. I agree that it's relatively easier to keep a codebase clean when the number of owners is small, but conversely, from my experience, when a codebase has multiple owners, keeping things organized can definitely be a challenge (in some cases I've seen, multiple teams owning overlapping sets of the codebase...) I've seen codebases with messy redux and codebases with messy non-redux architectures, and conversely also clean codebases with both types of architecture. There really is no silver bullet technology. The "you can write cobol in any language" thing is always going to be a looming plague.