Question about naming and interfaces

I was just curious what was the reasoning behind .value from fromPromise and current() from fromResources and lazyObservable as those names don’t appear anywhere else in mobx.

In RxJs most of the return values are Rx.Observable. Coming from there, one would expect these to implement some common interface like boxed values (.get). What’s the equivalent predictable interface for the return values inmobx and mobx-utils?

[urugator]

Btw check the current description for initialValue of fromResource in the README.md 😃

[urugator]

Observability in MobX is not defined by interface. Any object can be observable (consumed by Mobx) no matter what the interface is. Unlike RxJS there aren’t methods which consumes a special “observable” interface. Why would you introduce an abstraction, if it’s not used or required by anything? The values produced by Rx.Observable (the value supplied to observer’s next) also have an arbitrary interface, these are the actual interfaces you have to work with, but these can’t be observed, therefore must be wrapped into Rx.Observable, which is not the MobX case. Yes you can create a function, which accepts any Rx.Observable … imagine that there wouldn’t be any function in RxJS requiring this interface and only thing you could do with Rx.Observable is to obtain (get) some arbitrary value it produces. How is it useful? You have a generic type without any generic methods…

Because the ObservablePromise is not just an observable result of promise, the RxJS analogy would not look like this:

promise.subscribe(value => {
  console.log(value);
})

but rather like this:

promise.subscribe(promise => {
  console.log(promise.value);
  console.log(promise.state);
})

The MobX analogy of the former would actually be:

const value = computed(() => fromPromise(promise).value);
console.log(value.get()) // now we are truly working with single boxed value, so the .get() makes sense

And observable promise with a common interface inspired by Rx.Observable would imho looked like this:

const promise = fromPromise(Promise.resolve(5));
promise.get().value;
promise.get().state;

normalize data sources to a common interface

The returned objects does not neccesarily represents the same thing as suggested in above code samples, therefore they don’t have to share the same interface. Again object returned from fromPromise does not represent the data “sourced” from Promise, it represents the Promise itself (but consumable by MobX). However most of these returned objects have in common that they “wrap” some “value” (this is quite vague definition however - should class UserList have .get() to return the actual array of users? probably not right?). So we could came up with a consensus that these “value holders” can always expose the “most significant value” with .get() which is aligned with boxed observables. But we will end up with an interface:

promise.get()
promise.state;

how consistent is that? So maybe:

promise.value();
promise.state();

This seems reasonable to me, but it’s not aligned with boxed, so we would have to change them:

boxed.value();
computed.value();

That seems nice from the perspective of “API seems familiar”, but is it useful as an abstraction? Do these “values” really represent the same thing? Is it neccesary?

If those function just simply converting an arbitrary interface to another arbitrary interface then they are not really helpful

They convert specific non-observable interface to an observable object, whose interface tries to reflect/describe the original non-observable thing (which may be a single value or something more complex).

While current() to me feels like equally unhelpful

I can imagine that it could suggest (maybe even distinguish) that the value changes spontaneously over time, unlike the boxed which must be explicitely set. But get() seem equally fine to me in this case.

does it mean there is next() and previous() as well

Currently not, but technically could be, or initial() perhaps … I am just speculating what could be the author’s thoughts at the time of writing…

Btw I don’t mind aligning the naming, I just feel the motivation/reasoning could be a bit off (especially in relation to RxJS).