mweststrate

7 ms·

1.
UI as an afterthought. About FE architecture and the impact of React hooks(michel.codes)
2 points by mweststrate 8y ago|0 comments
2.
Immer: Create the next immutable data tree by modifying the current one(medium.com)
2 points by mweststrate 9y ago|0 comments
3.
by mweststrate 9y ago
> I look at mobx I get reminded of.. Looking like, and being like are two different things :) Mobx reminds people (rightfully) of Meteor, Knockout, Angular etc, but when working with it you will see it is quite a different best. Just li
4.
The fundamental principles behind MobX(medium.com)
2 points by mweststrate 10y ago|0 comments
5.
by mweststrate 10y ago
See https://github.com/mobxjs/mobx/issues/681#issuecomment-26234... (that thread started only yesterday, so it isn't very long yet), but yes, MobX is in use in large complex production apps for a long ti
6.
by mweststrate 10y ago
yep that was the glitch I was referring to indeed :)
7.
by mweststrate 10y ago
The idea is very much like knockout and meteor, but the reactivity implementation is completely different. First all it is generic and not designed for just the UI. MobX is completely glitch free and synchronous and has explicit distincti
8.
by mweststrate 10y ago
Online courses: Introductoin by LearnCode.academy: https://www.youtube.com/watch?v=_q50BXqkAfI More in depth: https://egghead.io/courses/manage-complex-state-in-react-app...
9.
How to decouple state and UI (a.k.a. you don’t need componentWillMount)(medium.com)
2 points by mweststrate 10y ago|0 comments
10.
Serializr: serialize and deserialize JavaScript object graphs to JSON with ease(medium.com)
1 points by mweststrate 10y ago|0 comments
11.
3 Reasons why I stopped using React.setState(medium.com)
9 points by mweststrate 10y ago|0 comments
12.
Why we chose MobX over Redux for spectacle editor(formidable.com)
5 points by mweststrate 10y ago|1 comments
13.
by mweststrate 11y ago
For your first question: nope, the important edge case is that deep changes on _non_ observable objects won't be observed. But that is no different from the edge that deep changes on (conceptually) immutable objects are not observed.
14.
by mweststrate 11y ago
In MobX it actually doesn't matter whether the events happen inside or outside the component. Components themselves are part of the nervous system. They react to changing observables that are used in the rendering. Regardless how those
15.
by mweststrate 11y ago
I think it is quite different, at least if I read the docs correctly mercury is much closer to Redux / OM then MobX + React. MobX doesn't work with cursors and your tree doesn't have to be a normalized tree (it can be any (mu
16.
Make state management simple again: Intro to MobX(mobxjs.github.io)
15 points by mweststrate 11y ago|11 comments
17.
by mweststrate 11y ago
Sure, the promise of VDoms is performance. And vDOM has improved DOM performance a lot. But also not nearly enough to support the complexity of most real life applications that handle a decent amount of data (say, 1000 visible components at
18.
by mweststrate 11y ago
Exactly. Integrating many apps is something we do as well. We have a large application that handles roughly 500 different domain classes (just scan through https://apidocs.mendix.com/modelsdk/latest/ to see how va
19.
by mweststrate 11y ago
"With mutable data structures, it is trivial to guarantee that there is only one version of a certain domain object in memory." That statement refers to the fact that you loose (automatic) referential integrity when you start usin
20.
The best way to build large scale apps with Flux(medium.com)
4 points by mweststrate 11y ago|0 comments
21.
by mweststrate 11y ago
Object.observe was a bad idea. Even when it was available in chrome I didn't consider using it. However, the ES6 proposal for object proxies will hopefully become generally available as those can solve the same issue way more elegantly
22.
Becoming fully reactive: an explanation of Mobservable(medium.com)
28 points by mweststrate 11y ago|2 comments
23.
How to create strongly typed npm modules using Typescript(medium.com)
4 points by mweststrate 11y ago|0 comments
24.
by mweststrate 11y ago
We use both; local component state as long as nobody else (might) be interested (this usually the case for generic components that are not application specific, such as page controls, checkboxes etc). But as soon as state starts to creep up
25.
Mobservable: blazing fast Reactjs without Flux or immutable data structures(survivejs.com)
4 points by mweststrate 11y ago|0 comments
26.
Pure rendering in the light of time and state(medium.com)
2 points by mweststrate 11y ago|0 comments
27.
by mweststrate 11y ago
Hi, the keys are used indeed in the example to prevent re-rendering. However, it does not prevent diffing the virtual dom. In other words, the new list with components needs to be compared with the old list. That comparison is fast because
28.
Reactive React: the pursuit of high performing, easily maintainable React apps(mendix.com)
6 points by mweststrate 11y ago|3 comments
29.
Nscript: Write bash-like shell scripts using JavaScript(npmjs.com)
8 points by mweststrate 12y ago|0 comments