v → v, t/f?

[dy]

Revert #173.

Transform observable is different from simple value holder. The initial problem is 2-way binding: if prev observable has mapper function but no unmapper, then next observable won't be able to setup setter:

let v1 = v(2, v => v + 1)
let v2 = v(v1) // subscription obtains value `3`, which subscribes/sets back to v1, which sets it to `4` etc.

So setter-mapper is possible for subscriptions with defined unmapper.

let v1 = v(2, v => v + 1, v => v - 1)
let v2 = v1()

That is also mathematically correct, but raises question of how to differentiate v1.set → map (internal) from v2.set → unmap → v1.set (external). v1.unset()?

Or instead have t(src, map, unmap)? Does that solve the issue? Not exactly. unmap doesn't match self map here - it attempts to unmap to prev observer.

[dy]

From the other point, having a separate effect gives:

• separated interface code. v is kept as value container, without mappers. f is kept as transforming wrapper.
  • v is just a case of generic f.
• f has better control over if getter/setter is available, it can adjust own getter/setter to target. v is fixed in this matter.
  • v can also redefine get/set in the same fashion.
• v init value is taken as granted, f has type detection.
  • init must be used for subscription to source, the rest can be changed manually.
• f is accessor to some source, v is accessor to itself, it is not a wrapper.
  • v is just a particular case for f (primitive source) - instead of constant it can be stateful.
• f has no own state - it only defines getter/setter.
• f is easier to handle arrays - multiple deps, unlike v
• f is easier to define map/unmap, unlike v

Ok, if you want - call it f. But v is just a particular case of f, it is not needed then)

[dy]

done as v

[dy]

Although value is particular case of from, it has advantages.

• v can be initialized with value without confusion: v(<input/>) stores element, not tries to subscribe to observable element or input.
• f demarks better mapping vs value state, it is more readable for single-timers and gives better conceptual grasp.
• v itself can be used separately as a very thin lightweight thing.
• more apparent API difference.

[dy]

f also allows dotprop-like observable creation f(obj, 'x.y.z') which is... same as prop actually.

[dy]

Ok, with #182 sub-props are exposed as observable props on root observable.

[dy]

f has significant use-case: create observable from something. What about v.from?

• compatible with Observable
• inseparatble from v
• all abovementioned pros: init from value, mapping case, tiny [treeshakeable] v.

[dy]

The problem of v.from is that it is more important than single-constant init, which is useful but rare. What if instead use react-like initializer v(() => value) ? We guess that wrapper over another observable does not make much sense v(v1) - without mapper. So we can safely consider it a mapper v(map)

[dy]

Ok, done as initializer.