Lazy Reactivity

[wycats]

If you have a large array of objects and want to turn it into a reactive array of reactive objects, you'd probably do something like this:

const array = reactive.array(input.map(reactive.object));

This would eagerly convert your entire array into a reactive array of reactive objects.

But, in similar use cases as the incoming adoption API, you may want an array that incrementally adopts entries in the array as they are accessed.

I think this is a natural extension of reactive.array, and I'm sticking the idea here for discussion. I'll follow up once adopting reactive objects has landed.

Note that this is not trying to solve the use-case of arbitrarily recursive reactivity. In general, "array of objects" is an important use-case that is distinct from attempting to make all recursive access reactive.

[justjake]

Perhaps adoption APIs should allow a callback parameter onFirstAccess<T>(property: PropertyDescriptor<T>, propertyValue: T[keyof T)?
This could lead callers into a crazy swamp, but otherwise you are overly constraining the solutions for a problem that could be unique for the caller.

You allow the consumer to choose if they want to implement wild recursive semantics, but your framework isn't providing it directly. The framework already owns responsibility for "special reactivity magic happens on property access"... is this too much scope creep?

interface Block {
  id: string,
  title: string,
  children: Block[]
}

const adoptArrayOfBlock: PropertyAdopt<Array<Block>> = (prop, val) =>
  reactive.adopt.object(val, adoptBlockProperty)
const adoptBlockProperty: PropertyAdopt<Block> = (prop, val) => 
  prop === 'children'
  ? reactive.adopt.array(value, adoptArrayOfBlock)
  : val
const reactiveBlock = reactive.adopt.object(block, adoptBlockProperty)

[wycats]

I think that some version of this makes sense. One thing I was thinking about, in particular (while falling asleep last night 😱) is that you really want to be able to define keys and equals comparisons along a path.

Keys in particular are the main way that mutating an array has similar performance to replacing an array, and I think making it possible to define keys for arrays that the lazy reactivity was adopting would be critical to a nice design here.

One possibility would be defining policies for specific traversal paths, which would be a little more declarative but still fairly explicit.

[NullVoxPopuli]

Over in ember-land, I made something that sounds similar -- I just called it map: https://ember-resources.pages.dev/modules/util_map
I use this for transforming large sets of data where I only access a little bit at a time.

idk if that's the approach you'd want to take, but I imagine the starbeam equivalent could be something like:

const lazilyWrappedArray = reactive.array.map(inputArray, (element) => new WrapperThing(element));

initially, nothing would happen other than the wrapper object/class is created.
But if you were to do:

let first = lazilyWrappedArray[0];
// or
let nth = lazilyWrappedArray[n];

then the first and nth objects only would be wrapped in WrapperThing.

This object can also define an iterator so that

for (let wrapped of lazilyWrappedArray) {

}

works, and if you break out early, you don't pay the cost of mapping over everything.

Caveats:

• object identity must be maintained (map's cache is WeakMap-based) otherwise no cache is had