MobX roadmap (> 2.3)

[mweststrate]

For the previous one see #219 :)

• provide standardized (de)serialization mechanism, see Patterns for @computed, ES6 classes and (de)serialization #206, A fromJS api (opposite of toJS)? #297
• provide standardized context / connect / provider mechanism in mobx-react, see Importing store directly or pass as props? #300 , Built in support for connecting stores to components mobx-react#53
• provide standardized time travelling mechanism
• introduce derived arrays, Derived arrays in MobX #166 (and for fun built a VDom with it 🎱)
• improve modifiers mechanism? see Make modifiers api simpler & uniform #211
• fix modifier stickyness, Modifiers are not sticky when reassigning to @observable fields #197 @observable asStructure #320
• support onBecome(Un)Observed events Triggering a fetch within a @computed value #307

[mweststrate]

Proposal for standardized (de)serialization: Feel free to shoot at it! (Probably it is easier to start with the examples at the bottom) https://gist.github.com/mweststrate/4c9a8e0411ae547fdfe1bc3633dc599e

Might become a stand alone package, not really mobx related so far

[mdebbar]

I tend to agree with @pkieltyka about being careful not to bloat the library with features. The great thing about mobx now is the very short learning curve. It has few concepts that are easy to grasp. Once a lot of concepts are added to mobx, it becomes more difficult to learn. I would suggest trying to keep a minimal API in mobx core, and let libraries provide more features on top of it.

[benjamingr]

I would like to suggest that we remove features from the library and keep it small, currently there are few concepts I have to learn to use it - optimally there would be even fewer:

• Doing fromJS is just assigning to an observable property, I don't think it's needed.
• Derived arrays sounds great, especially since it's a performance boost that's not user facing in any way.
• I don't think @observable should be extended further, I'd like to see other primitives in libraries and built on top of it.

I'd like to see the library smaller and see how things like Atom Reaction autorun and others be further reduced into a smaller surface API.

[mweststrate]

For the second bullet: See pull request #65 , build 3.4.0-beta.1 can be used to test and give feedback on the new Provider mechanism. Docs: https://github.com/mobxjs/mobx-react/blob/provider/README.md#provider-experimental

(First one is WIP as well)

[mweststrate]

Provider / context support is now released as mobx-react@3.4.0

[jorilallo]

@mweststrate awesome, I was waiting this to land and works perfectly - such a great addition to separating stores for better testing

[vonovak]

+1 for (de)serialization 👍

[mweststrate]

Closing this issue as it tends to become a double administration

[jbrantly]

Apologies for necroing an issue, but I couldn't find any other information after searching. The first item here "provide standardized (de)serialization mechanism" is checked. Does that mean something for that feature has been implemented somewhere?

[mweststrate]

yes, see serializr package (or mobx-state-tree, but that is WIP)

Op do 17 nov. 2016 07:17 schreef James Brantly notifications@github.com:

Apologies for necroing an issue, but I couldn't find any other information
after searching. The first item here "provide standardized
(de)serialization mechanism" is checked. Does that mean something for that
feature has been implemented somewhere?

—
You are receiving this because you modified the open/close state.

Reply to this email directly, view it on GitHub
#323 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/ABvGhExAGvQNFJPtLEdTXKpQduM8FNMWks5q-_FsgaJpZM4I1PHJ
.

[gessichen]

Do we have any samples regarding onBecome(Un)Observed ?

[hccampos]

I'd just like to point out here for anyone that happens to read this issue that so far serializr has been working great for us. Started our serialization stuff with cerialize (https://github.com/weichx/cerialize) but ended up switching to serializr for the nicer api, better compatibility with MobX and support for references and lookups. Cerialize does provide a nice utility for automatically converting keys to/from e.g. snake_case and camelCase, but that's nothing that can't easily be done in serializr with some custom serialization functions.

Also, computeds and createTransformer can then be used to create a state tree kinda like mobx-state-tree.