2 ms·
I don't think React really takes too much of an opinion on how we store our models -- it is, at it's core, a view layer -- a function that takes as input a mode
by jowiar 11y ago
I don't think React really takes too much of an opinion on how we store our models -- it is, at it's core, a view layer -- a function that takes as input a model and spits out a UI. I've written model layers behind React UIs that use different paradigms for manipulating the model -- they've all worked, and in hindsight, I wouldn't use one particular paradigm for everything -- there probably isn't one "right" paradigm for organizing the model, which is one of the biggest strengths of React as a framework.
One (officially blessed) example of a different model layer is combining React with something like Immutable.js, which does use setters which return new objects for each modification, allowing shallow comparisons of everything.
- dustingetz 11y agoto be clear, Immutable.js "setters" are only there because we don't have native syntax for updates. The article is talking about using setter methods to abstract over data changes so we have a place to run code when things change. That's not what immutable.js setters are for.
- braythwayt 11y ago+1! There are many, many, MANY things you can do when you make setting and retrieving a property "programmable." Injecting "method advice" to propagate changes--as the post describes--is one. Making data immutable through copy-on-write is another. Same mechanism, entirely different architectural objectives.