4 ms·
The point is that in both React and XAML apps, you (usually) don't write code to mutate the View. In your code, the View is just a declarative construct. There
by Aleman360 11y ago
The point is that in both React and XAML apps, you (usually) don't write code to mutate the View. In your code, the View is just a declarative construct.
There's nothing stopping you from making immutable ViewModels in MVVM, other than bad perf (which React would presumably also suffer from on larger apps).
- xixixao 11y agoThe point is React is not just View, each component is a view plus the part of the "controller"/"presenter" that would take care of populating the view. And the controller/presenter is where state is always encapsulated, which React gets (mostly) rid off.
- tracker1 11y agoFacebook doesn't seem to perform so badly in terms of a larger app. More varied components on a page than most applications in general. Most of the quirkiness I see in FB tends to come from how they deal with eventual consistency with their backend in order to scale to millions of simultaneous users. Most applications don't have the latter problem.
- Aleman360 11y agoI bet they do a lot of shouldComponentUpdate, which kills the functional purity. XAML control properties do the equivalent of shouldComponentUpdate by default. Same ideas, just doing diffs in different places.
- dustingetz 11y ago> I bet they do a lot of shouldComponentUpdate, which kills the functional purity. functional purity enables shouldComponentUpdate