middleware

[pkieltyka]

I think it'd be great to have a middleware adapter interface for getters/setters and maybe other stuff. It would be useful to attach things like a logger during debugging situations to find out the code path of code being set. I feel it would be pretty easy to add too

btw (as an aside point), mobx6 came out today and its certainly cleaner then mobx4/5, but I still feel the micro footprint of micro-observables and smaller surface api makes for a better experience. However mobx is definitely more battle tested and has things like middleware for logging. My main thing with micro-observables is ensuring im not re-rendering more often than I want, and also to ensure consistency of the data as its being updated, perhaps this is why mobx encourages to make updates within an action() call. Maybe micro-observables should also have some explicit call to make a batch'd update in a single tick instead of having multiple state updates go across render ticks and make for unnecessary re-renders.

another interesting fact.. micro-observables/src/* is 328 lines of code, and mobx/src/* is 5312 lines of code.. 93% smaller which is a pretty awesome achievement, but I still think more can be done to micro-observables to make it better while still keeping the surface api as small as possible and keeping spirit of explicitness

(UPDATE: just found in the docs Observable.batch(block: () => void) for batch updating, nice)

[pkieltyka]

also, a bit off topic.. but as an FYI we tried to port micro-observables to mobx6 to see how they feel and its quite similar of an interface which is cool: horizon-games/cacheness@6a5d3a7

I still prefer micro-observables, but thought you might be interested in this experiment / comparison

[simontreny]

Hi Peter!

Middleware is definitely something on the roadmap. Actually, there are two middlewares/plugins that I'd like to write: micro-observables-persist that would serialize and write observables to localStorage/AsyncStorage (and that could also be used for SSR) and micro-observables-devtools that would send changes over a websocket to be able to inspect the app state in a debugging tool.

Also thanks for the insight on MobX 6, this definitely looks neat! Personally, I still think that MobX's main issue is the implicitness it creates and the fact that it promotes mutability. It's pretty nice to write MobX code as there are almost no extra work to do (especially now with makeAutoObservable) but it makes it hard to debug and to see what causes rerender of your components. But that's a small price to pay and MobX is definitely a great choice for React state-management!