Roadmap ideas - umbrella issue for future development

[mweststrate]

Hi all, feel free to add suggestions to this issue for things that should be added / removed / improved in observable. I'll gather all the items on which there is consensus, running / planned items, or items we need at Mendix in this first message. Ideas can be added by replying.

If people want to contribute on any of this just let me know!

Planned

Breaking(?)

Non-breaking

1. introduce reactive graph transformations (running, see Reactive graph transformations #67)
2. improve core implementation (to make it easier to comprehend / contribute) and run autorun functions in separate transactions (running, see also Autorun should run in isolation of derived values #71)
3. simplify + reduce memory consumption by removing debug context object, and initialize more internal structures lazily (running)
4. introduce observable sets (Observable sets #69)

Ideas

Non-breaking

1. Provide RxJS integration.
2. introduce explicit get / set methods on arrays
3. Find a cooler name for the lib and give it a fresh introduction including a cool website? 💯 🍰 👊
4. Improve docs
5. write blog posts on the following subjects:
   • Explain inner workings Create those pretty pictures to show us how mobservable & TFRP works (dnode, etc) #24
   • Explain why / how having reactive state and pure derivations solves a lot of problems

(Possibly) Breaking

1. Remove .observe() from observable scalars and functions (smaller api, there is an better alternative, code base reduction). Conflicts with mobservable.observe should support observing individual properties #59
2. Remove error handling for derived values; fail fast and fail hard. Currently logged exception seems to be just confusing and distract from the cause
3. Make @observable non recursive by default (introduce @shallowObservable #55, Introduce shallowObservable #56). I think there is general consensus for this one; less magic.
4. Make fast arrays the default, see Creating observable array should be optimized #68. This means that observable arrays can no longer be enumerated using for .. in. 😢
5. ... maybe don't use observable as a swiss knife and expose more explicit methods like mobservable.object, mobservable.array, etc..
6. ... maybe don't call observable arrays arrays, but lists instead. Makes it more clear that those aren't real array's, but makes it less clear that they support the complete array api, including index assignments.

Rename ideas

1. Separate @observable into @observable and @derivable (for getters) to communicate more clearly the ideas behind mobservable
2. Rename observeUntil into when
3. Think of a clearer / less scary name for autorun, maybe reactive?

Also see #34 (road to 1.0) for some past ideas.

[kmalakoff]

Some feedback:

(1) Provide RxJS integration - I'm assuming / hoping this will be done outside of mobservable (eg. expose generic hooks in core and release a separate module). I might deprioritize this compared to improving the fundamentals.

(2) introduce explicit get / set methods on arrays - maybe clarify this in a Wiki page with an example and link back to this proposal discussion. Is this to deal with the loss of API with the array optimizations?

(3) Remove error handling for derived values - I find myself running into cycle detected a lot (will try to isolate use cases) and definitely would like to discuss improvements in general. Maybe this should be broken out into a Wiki page / issue to discuss and generalize Upgrade error handling and reporting.

(4) maybe don't use observable as a swiss knife and expose more explicit methods like mobservable.object, mobservable.array, etc. and Remove .observe() from observable scalars and functions - Maybe this should be generalized as API redesign / refactor / upgrade, merge with other topics (like the next one below), and create sub-points? I've been thinking a lot about this (for example, how to reduce the surface area, decrease learning curve, and provide analogies across ES5, ES6, and TS) and would volunteer to help with brainstorming and proof of concepts on this.

(5) Separate @observable into @observable and @derivable (for getters) to communicate more clearly the ideas behind mobservable - not sure about the naming (maybe computed?), but I've been thinking that there should be an analogy with ES5. For example, I'm not sure if these are equivalent, but there should be some easy-to-understand equivalence:

Observable:

// ES6
class Store {
  @observable prop = null;
}
var store = new Store();

// ES5  - prototypical inheritance
function Store() {
  extend(this, {
    /* @observable */ prop: null
  });
}
var store = new Store();

// POJS
var store = extend({}, {
  /* @observable */ prop: null
});

Computed / Derived / View:

// ES6
class Store {
  @observable things = [];
  @computed /* get ? */ filteredThings() { return this.things.filter(...); }
}
var store = new Store();

// ES5 - prototypical inheritance
function Store() {
  extend(this, {
    /* @observable */ things: [],
    /* @computed */ filteredThings: function() { return this.things.filter(...); }
  });
}
var store = new Store();

// POJS
var store = extend({}, {
  /* @observable */ things: [],
  /* @computed */ filteredThings: function() { return this.things.filter(...); }
});

If this is the case, then maybe we just deal with extension and no observables directly (eg. they must be associated with an instance given the get /set magic of mobservable). I'm getting into details, but just wanted to make a case for simplifications and maybe combining topics...

(6) Think of a clearer / less scary name for autorun, maybe reactive?. In knockout, there is no separate concept for autorun. You just use a computed and never use the return value. It keeps the API surface area down and hooks into normal lifecycle methods. I wonder if autorun can be eliminated by following a similar approach? That would be even less scary! 😉

[joelharkes]

autorun names:

• executeOnEveryChange()
• listenAll
• triggerOnChange
• onChange
• change
• observeAll

i do agree autorun is a bit of a abstract name. as long as mobx.Observe also exists autorun is not per se necessary. Since Observe does the same thing for 1 variable/property. i'd suggest calling it mobx.observeAll/Every/Any()?

[mweststrate]

@joelharkes most people won't see responses on closed issues. But observe != 1 property autorun. Autorun respects transactions and such, observe doesn't. Generallly prefer to use reaction instead to listen to individual property changes

[joelharkes]

Hey no problem, just thought i'd drop my 2 cents. isn't reaction a very ambiguous word?

but so technically it's an onTransactionCompleted event? (I've been using mobx for a while, yet to dive into the source code (thanks for making this awesome library!)).

Tip: you can easily see people's questions on mobx by filtering on the tag on SO: https://stackoverflow.com/questions/tagged/mobx

[mweststrate]

Yes it is. Most api's in MobX are named after what they intend to achieve on a conceptual level, not to what they do Op vr 4 mei 2018 om 15:21 schreef Joël Harkes <[email protected]>:

…

Hey no problem, just thought i'd drop my 2 cents. isn't reaction a very ambiguous word? but so technically it's an onTransactionCompleted event? (I've been using mobx for a while, yet to dive into the source code (thanks for making this awesome library!)). Tip: you can easily see people's questions on mobx by filtering on the tag on SO: https://stackoverflow.com/questions/tagged/mobx — You are receiving this because you modified the open/close state. Reply to this email directly, view it on GitHub <#74 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABvGhDj64LuxDVfzmpYOL7tQKf7Cxgzaks5tvFXUgaJpZM4G1_Uu> .