Road to 4.0 #1076
Comments
|
long live the MobX hopefully it could defeat Redux in one day |
|
bq. Proxy arrays, kill faux array |
|
@andykog I think 3.0 should be maintained still, but want to prepare for the future as well. Promised for a long time now that certain issues will be fixed when proxies are available, and their support is getting more decent now :) |
|
@mweststrate Although we do have some clients who use IE11 explicitly, I do very much support going all in with |
|
Not everybody is so lucky that they can ignore IE users. You can't tell managers that we have to drop about 4% of customers because that will make mobx core simpler. This puts many user in a position where they have to decide wheather they gonna stick to an older mobx version or use something different for their apps. My opinion is that this is to early for switching to proxies. |
|
Compatibilty of:
I don't think I would be able to switch immediately to v4 but I would support using proxies and Map anyway, it's not like 3.0 is going to stop working. |
|
About 5% of our traffic is still stuck on IE. Regardless, I think it's a
really cool idea to start exploring the new proxy features. I think we
should be super duper explicit about what v4 is all about. We may want to
call it mobx-next or something. I do worry that if we wanted to make
significant changes to 3.x we'd have to jump past v4. That could be a
little funky.
…On Thu, Jul 6, 2017 at 2:56 AM, Vincent Prouillet ***@***.***> wrote:
Compatibilty of:
- proxy: http://caniuse.com/#search=proxy
- Map: https://developer.mozilla.org/en/docs/Web/JavaScript/
Reference/Global_Objects/Map
I don't think I would be able to switch immediately to v4 but I would
support using proxies and Map anyway, it's not like 3.0 is going to stop
working.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1076 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AAIrch_yNRH0QHVYvPv7SFJWuSX2Mfz_ks5sLJMdgaJpZM4ONAsS>
.
--
-Matt Ruby-
[email protected]
|
|
+1 for |
|
I could be wrong, but I think
can be implemented now without any loss of browser support (with a polyfilled ES6 Map)? If so, it might be worth this - and any other breaking additions which needn't affect browser support - being the basis of v4, and v5 (or mobx-next) forming the basis for the big move to using Proxy? |
|
https://github.com/ascoders/dynamic-object here's an object observer with proxy that features similar functionality like mobx, using almost purely Proxy. Indeed the project is written by a Chinese, hence I doubt your ability to read the documents and comments, but you guys can take it as a code reference. |
|
I would be against |
|
Some quick notes:
|
|
@urugator tnx! Also: Upgrade to latest TS |
|
Can we avoid "dispose" somehow, for example storing listeners to WeakMap with observable as a key? pseudocode: |
|
Managing reactions/autorun disposal is my one difficulty with Mobx. Especially when the autorun is on something other than a component (and thus without an unmount/dispose...) |
|
Having struggled recently with async computed functionality, I woukd propose it out of the box. |
|
@rasdaniil +1 Better, clearer support for async, both for computed and for action, would be high on my list. I don't know how feasible it is to improve, but |
|
Check the recently added asyncAction in mobx-utils package! Removes the
clumsiness
Op do 27 jul. 2017 17:21 schreef Andrew Metcalf <[email protected]>:
… @rasdaniil <https://github.com/rasdaniil> +1
Better, clearer support for async, both for computed and for action, would
be high on my list. I don't know how feasible it is to improve, but
runInAction feels very kludgy to have to use after every await in an
async action.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1076 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABvGhFo-5r6a8qx8B2X2gRd4TUazpR5Nks5sSKsAgaJpZM4ONAsS>
.
|
MobX releases:
By the time MobX v4 is released, IE usage will be lower. Voilà |
|
@stevefan1999 Redux is OK but still, I do get quite intrigued when I listen as an argument that Redux is for large apps and MobX for small/medium. Not to mention that after a while the amount of files and complexity a Redux based project has to deal with is absurd. @mweststrate 👍 for killing faux arrays |
|
Good time to looking for the future. I approve the plan of switching to proxies underneath. Besides, React 16 requires Map & Set in runtime environment and it's mandatory. |
|
@OshotOkill - But Map and Set can be polyfilled. Proxy cannot. |
|
@jamiewinder But wouldn't the existing partial polyfill for Proxy cause a rewritten version of mobx to behave just like the current version does (i.e. new properties are not tracked)? Then mobx4 could just have a compatibility flag that disallows adding new properties to objects and browser compatibility would stay the same. |
|
@phiresky I'm not really sure what the extent of the limitations of that polyfill are apart from the ones you highlighted. One that does start out is the faux array issue of MobX - observable arrays are not arrays. If MobX were to rely on a proxy polyfill, then we'd be in an ever more precarious position where an observable array may or may not 'be' an array depending on whether you're using the polyfill. I think the switch to proxies should be absolute. i.e. if you need to support non-proxy browsers, then I'm afraid you'll have to stick to the previous version. However, I'm very likely one of those people who'll have to do this, and I'm missing some of the other features that are hoping to be added such as non-string keyed observable maps which can be added but will be a breaking change. It'd be nice (though I wouldn't presume to ask for it) to see a MobX 4 that adds these features (and require polyfilled Map, Set), and a MobX 5 that forces you to use Proxy, but this might lead to confusion and having to maintain two active versions. So I'm not sure. |
|
Also interesting; when will the new babel decorator implementation be
ready? Should 4.0 be based on the old or new implementation (and
semantics).
Op ma 4 sep. 2017 om 10:44 schreef jamiewinder <[email protected]>:
… @phiresky <https://github.com/phiresky> I'm not really sure what the
limitations of that polyfill apart from the ones you highlighted. One that
does start out is the faux array issue of MobX - observable arrays are not
arrays. If MobX were to rely on a proxy polyfill, then we'd be in an ever
more precarious position where an observable array may *or may not* 'be'
an array depending on whether you're using the polyfill.
I think the switch to proxies should be absolute. i.e. if you need to
support non-proxy browsers, then I'm afraid you'll have to stick to the
previous version. However, I'm very likely one of those people who'll have
to do this, and I'm missing some of the other features that are hoping to
be added such as non-string keyed observable maps which can be added but
will be a breaking change.
It'd be *nice* (though I wouldn't presume to ask for it) to see a MobX 4
that adds these features (and polyfill Map, Set), and a MobX 5 that
*forces* you to use Proxy, but this might lead to confusion and having to
maintain two active versions. So I'm not sure.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1076 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABvGhLyuvLuVPmNxWFW0_n_1YCJv5Bg-ks5se7h7gaJpZM4ONAsS>
.
|
|
For implementation details see https://github.com/ascoders/dob, #776 |
|
Just a quick note, because I see people mentioning only IE here. React Native is still not supporting Proxies, which is more important then IE in my opinion (other platforms are fine). Does anyone know when they plan to start supporting them? |
|
@solkimicreb As I know Proxy supported in iOS starting from 10.0. I didn't tested yet but it should be available on iOS because React Native uses system JSCore. On Android Proxies is not supported yet. |
|
I like the second example the best as it is straight forward, but I think the trickyness is the need to double declare every field (or maybe only the non The third example is not really an improvements, as it keeps the same type juggling ( But unifying decorate({
field: 3,
field2: Buffer,
get c1() { },
get c2() { expr },
method() {}
}, {
// no need to decorate 'field', observable is the default
field2: observable.ref, // needs decorating
// no need to decorate 'c1', getters are assumed to be computed
c2: computed({ opts }), // computed decorator with option
method: action.bound // method fields need decoration to turn them into actions (otherwise they are assumed to be views)
})The nice thing about this is that no values appear in the second argument, which keeps it very consistent with decorators that also don't work on the actual values (decorating is done before field initialization), and it indeed shouldn't make any difference whether the first argument is an object, class, etc etc, semantics would always be the same. Biggest downside is see is that declaring a lot of actions is verbose, the other variations are probably rare enough to justify needing to be 'declared twice' (Type-checking note to self: every key in decorators arg must be in target arg, except for |
Decorators work on properties by definition. It simply accepts options, exactly the same way as Don't allow to pass anything, but decorator, to decorate(observable({
a: 5,
field: Buffer,
}), {
field: observable.ref,
})You may preserve extendObservable(existing, {
a: 5,
field: observable.ref // NOPE! it stores decorator to field as value, use decorate instead
}) |
to clarify: what I mean is that if all fields are declared in the target argument, the type can be inferred correctly from that. However, once values are declared in the second argument, the second argument is required to infer the correct type, and to even achieve that the type system must be tricked into the decorator not returning a descriptor, e.g.: |
Is it useful for people who don't use typescript/transpiler(no type checking), therefore don't have an access to decorators, therefore are the ones using Is it doable in way that I can trade verbosity for type checking? So if the value is in the first arg, I have more verbose code, but strict typing...? |
No, that set of people is disjunct. Many people use flow without decorators, or typescript implicitly without decorators (when using VS code in a plain javascript project it will still use the typescript compiler to infer type information)
Yes that would be possible. But I am wondering, is the verbosity that bad? The only case where one must double declare the fields, is with For actions that is not strictly necessary, because In other words, I think we could largely follow your proposal in unifying extendObservable(target, values, decorators?) {
// infer decorators from values
for (key in values) {
if (!(key in decorators)) {
if (hasGetter(values, key))
decorators[key] = computed
if (!isFunction(values[key]))
decorators[key] = observable
}
}
// decorate!
return decorate(Object.assign(target, values), decorators)
}Advantages: type safe |
|
I like it, some thoughts:
extendObservable(this, this, { // getters are not enumerable in classes
ref: observable.ref
method: action,
})
// EDIT: ahh, it wont' work ...these're not own, but on prototype, right?
observable({
b: Buffer,
}, {
b: decorators.ref // or decorators.observableRef ?
})
`` |
Decorate would work fine afaik?
Sure, this is just rough draft code :)
I don't think so, when used as decorator, the second arg is always |
It's not like that // similar to mobx-react's inject
decorate({
a: observable,
method: action,
})(class Store {
constructor() {
this.a = 5;
}
method() {}
});So maybe we should leave the actual
Then that's a good news :) Hopefully it's also compatible with new decorator proposal(s) ... Can we shorten |
|
Hi all, if you want to experiment with the new Mobx 4 api, you can try it now! Just install The changelog can be found here Give it a try! Let me know how much the impact is of the api changes :). You might note that this version is slower then mobx3, but that is just a side effect of the recent api refactoring, mobx4 will be faster then mobx 3 (alpha.1 is representative performance wise) |
|
@mweststrate very exciting! Btw, as a TypeScript user myself I have a quick question: will the "experimentalDecorators" offered in TS still work with mobx4 in the convenient form |
|
Yes!
Op do 1 mrt. 2018 15:39 schreef Peter Kieltyka <[email protected]>:
… @mweststrate <https://github.com/mweststrate> very exciting! Btw, as a
TypeScript user myself I have a quick question: will the
"experimentalDecorators" offered in TS still work with mobx4 in the
convenient form @observable field = 3 ?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1076 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABvGhAr7wxtUUosn7Q1vhCp_Kvyb__CQks5taAgsgaJpZM4ONAsS>
.
|
|
About computeds:
// Buil-in value types
console.log(new String("hello").valueOf() === "hello"); // true
console.log(new Number(5).valueOf() === 5); // true (NaN requires a special treatment)
console.log(new Date(1519916831621).valueOf() === new Date(1519916831621).valueOf()) // true
console.log(new Date(1519916831621).valueOf() === 1519916831621); // true
// Arbitrary value types
const arbitraryValueLikeObject1 = Mobx.observable.box("a");
const arbitraryValueLikeObject2 = Mobx.observable.box("a");
console.log(arbitraryValueLikeObject1.valueOf() === arbitraryValueLikeObject2.valueOf()); // trueSo what I propose:
|
|
Not sure if it's just temporal, but I've noticed we're accessing
|
agreed
I don't think in mobx we don't really need to make this distinction (this can always be done in a custom equals function), because the only case where the difference would actually be different, is where an non-plain object implements a Did you note that 3.6.1 / 4.0.0 had a revision of the deep-equality mechanism because it contained a bug? It now follows the underscore implementation. This means that even non-primitive objects are traversed, and things like Point & Vector should work fine as well |
|
For the |
Unless their internal structure is different from what their
I am probably missing something ... when I |
agreed, will do
the main concern is a smaller build, not performance. When running the performance test suite on the server with and without the |
|
Mobx 4 beta is now available! npm install [email protected]. Migration guide: https://github.com/mobxjs/mobx/wiki/Migrating-from-mobx-3-to-mobx-4 |
|
...so it's stil |
|
@urugator correct, I started renaming, but then it got weird because that would involving renaming |
|
I thought that |
|
No, `@computed.struct` is the same as `@computed.options({ equals:
comparer.structural})`. `@computed.equals` has been removed in favor of
`.options`. But `struct` is such a common pattern that I think it deserves
a short hand :-). The goal of the API is not to just be as small as
possible, but to make the 80% use cases as easy as possible, and make the
remaining 20% rest possible with an api that is as small as possible.
Op di 6 mrt. 2018 om 11:18 schreef urugator <[email protected]>:
… I thought that computed.struct is also removed ...same as computed.equals
...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1076 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABvGhGacoqvYZI-HR6acDa6LeNU97py_ks5tbmJkgaJpZM4ONAsS>
.
|
|
I see, I thought it's |
|
Released:
Which together fix some build & typescript issues :) |
|
released |
|
Released 4.0.0! |
|
@mwestrate awesome! Congrats for the ride! Really happy with Mobx :) |
and others
Hi all!
Time to start thinking about the next major of MobX. These are some of the ideas I have around them. Global goal:
Leverage modern features in evergreen browsers to address current quirks in the MobX api
Quirks being:
Tools to address the quirks: levering proxies #776 and native map implementations #800
Breaking changes
observable(object)will now make all properties (including future ones) observable. To limit / specify the set of observable properties one will have to useextendObservableisArrayLikewill be deprecatedArray.movewill be deprecatedAlso fix #940 if not done before
Tasks:
extrasnamespace for better tree shakingThe text was updated successfully, but these errors were encountered: