v scarcer API

[dy]

todomvc works just great, but it's a bit too heavy burden for the user to remember all the intricacies of object update - some props can be observables, others - direct values etc etc.

! one idea is $-like query for object. v(src, 'a.b.c') - that would create a listener for the property.

Would be nice to have something generic, like o({}) - an object with all-props are observables, so that you could forget that it is observable, same time for primitives it would be simple observ. So that would just expose all regular object props as is and update itself whenever any inputs change.

[dy]

Introspected on steroids? It is best for objects/arrays, but for primitives... creates a function or what?

Or prohibit observables and use proxy only? Can't prohibit - we use fn entry/observables to subscribe to updates. What would be the possible way to subscribe? v(from, callback?)? No, subscribe-able is very neat pattern, so main entry must be a function. v(x)(value => {})

Also what about mapping? You'd have to create new store via mapper anyways v(x, x => x.done ? 'ok' : 'not ok')

[dy]

As @samholmes mentioned, autosubscription to nested props raises 2 problems:

• how to organize mutators: map, push, put, pull
• how to organize non-binding access (not critical)
• how to bind to externals

[dy]

So the logic loop. Suppose we take introspected as obj = o({}). Then subscribing to that object becomes v(obj, o => o.x) or v(obj)(o => o.x). Then it's the same as just v({}, () => {}) with the difference that we initialize simple props as dependencies, so we observe props.

! what if indeed we turn direct object as dep into observable-props? It would emphasize difference between initializer and direct value init, which is good feeling.

let store = v({ items: [], count: 0})
store.items = [] // autoupdates
store.count = 1 // autoupdates

This way v acts as literally o + v. It reduces need in all internal props - they naturally propagate updates. That also removes need in internal observables.

[dy]

Is it worth patching passed object with getters/setters or instead define setters on returned proxy? Patching turns passed target into observable, same as other args. But that creates issues figuring out what to patch and whatnot. Also that is unable to patch everything - some original props need to be safe, like functions, privates, specials, array length etc.

For arrays though, if we avoid proxies - prototype methods must be patched, and... new elements are impossible to observe.

[dy]

On the other hand

• proxy stands out from regular observable fn.
• proxy is unable to be obj-spread for arbitrary new props, since it wraps function as target

So we can keep scope limited to only static props and avoid proxy. That is a bummer for new props and mutating array in particular. So static props are the balanced choice.

[dy]

Ok. Deps are sealed and simple props are observed now.