Reactive Collections Syntax in ripple files

[Hebilicious]

Hi Ripple community, I'm joining the party slightly late, and I love what I'm seeing so far.
There are a few things that I would like to propose, regarding the syntax for collections currently .

Here's the current syntax to declare a reactive collection :

const arr = #[] //sugar for TrackedArray
const obh = #{}  //sugar for TrackedObject
const set = new TrackedSet()
const map = new TrackedMap() 

arr.push(1) //reactive
obj.stuff = 1 //reactive
set.add(1) //reactive
map.set([1, 2]) //reactive

(There's also TrackedDate, but dates aren't collections)

As someone coming from vue where you can use ref with these 4 things, I can't help but feeling that this is a downgrade.
Is there a good reason to not re-use the neat track/@ here ?

const arr = track([])
const obj = track({})
const set = track(new Set())
const map = track(new Map())

@arr.push(1) //reactive
@obj.stuff = 1 //reactive
@set.add(1) //reactive
@map.set([1, 2]) //reactive

I feel like this is the best of both worlds, as @ is more succint than .value, but it still clearly delimits what is reactive and what isn't.
The tradeoff is that the @syntax obviously only works in .ripple files.
But maybe something like useTrack could be introduced to use track in plain js/ts files?

PS: I've read that under the hood ripple isn't using signals. So maybe track([]) could be sugar for TrackArray.from([])

[trueadm]

We considered this but it's too magical and also not very explicit. The type system will not know that these arrays etc are actually tracked arrays, and there's no way to make TS do that – we tried when making Svelte 5. Under the hood they're proxied objects and that means people lose out on knowing if an object is tracked or not – to be able to know when something can be reactive. Another reason is that sometimes you just want to track an array and not have it tracked. This is what we do in the JS framework benchmark, because creating a fully tracked array is wasteful if you don't need it be fully tracked.

[Hebilicious]

Thank you for replying so quickly and making ripple.

Regarding the typesystem, track(collection) could return TrackedCollection right ?
I hear what you're saying that there's currenlty 3 different cases :

• let a = []
• let b = track([])
• let c = #[]

From my personal experience, 1 and 3 are the most useful (could be wrong). So maybe something liketrack([], { shallow: true }) could be an option.

[leonidaz]

And to expand, excluding the inability to TS type things.

Vue went for deep reactivity as their default, just like Svelte. And similarly they're using proxies. Ripple also uses proxy's for arrays and objects but only with shallow reactivity as the default. So, in their case for non-primitive values, all nested objects require their own Proxy and each proxy slows things down.

We discussed this several times and strongly felt that deep reactivity as the default is usually a huge overkill and may lead to significant performance issues. Like the ole saying goes, "If all you have is a hammer, everything looks like a nail".

In real life, it's not that often that you want everything to be reactive. So, Ripple gives you full control of how to define your reactivity. Ripple provides the primitives, and, if needed, people can make things deeply reactive. Since they're in control, they know exactly (they should at least) what they're doing so they can find issues and bottlenecks and fix them much more easily.

This also allows Ripple to separate reactivity of the variable itself from its contents, which provides additional flexibility in structuring your code as well as better performance for many use cases to avoid much more expensive reactivity cascading effects.

Bottom line, reactivity is not free. And when everything is reactive, it really can add up to not such a great experience for either developers or users.

[Hebilicious]

Thanks for the reply and the added explanations.

I'm not suggesting to make all collections deeply reactive, I'm suggesting to use track([]) instead of #[] to define a reactive array. There should be a way to create shallow reactive collections as well.

Whether the most straightforward syntax should be deeply or shallowly reactive or not is an interesting point. I feel like if you give people a sweet shorthand syntax like #[], they will use it by default over a regular array.

[leonidaz]

I'm not suggesting to make all collections deeply reactive, I'm suggesting to use track([]) instead of #[] to define a reactive array.

We use track to make that assignment reactive, not the contents. It actually means "wrap this for me in a Tracked object", which can be used to transport across function / component boundaries and unwrapping it will give back the value and at the same time register the read to the change tracking system which will re-render the block where the read occurred.

So, you could have a reactive array where the variable is tracked as well:

const arr = track(#[1, 2, 3]);

and to read:

<span>@arr[0]</span>

And you can reassign it too, so anywhere where @arr was used will get re-rendered.

if (true) {
  @arr = #[5, 6, 7, 8];
}

Whether the most straightforward syntax should be deeply or shallowly reactive or not is an interesting point. I feel like if you give people a sweet shorthand syntax like #[], they will use it by default over a regular array.

I mean we can't really protect people from themselves. But we added it because people were freaking out about having to import a TrackedArray.

[Hebilicious]

Understood thanks for the clarification. I get the freaking out situation because I'm freaking out to have to import TrackedSet and TrackedMap as well...

So there is actually 4 cases :

• let a = []
• let b = track([])
• let c = #[]
• let d = track(#[])

It's not very clear in the docs what b and d would do, or when/if they should be used.
My understanding is that

track wraps a value and make it reactive only if its a primitive.
This is similar to a vue ref, but with a @ syntax to unwrap instead of .value and no reactive collection.

TrackedX are explicit reactive collections , so that #[0] is similar to vue reactive([0]), which return TrackedArray (ie vue Reactive<[number]>)

Am I correct ?

[trueadm]

track wraps a value and make it reactive only if its a primitive.

No, track wraps or "boxes" anything you give it. Including objects and arrays. In order to created a TrackedArray or TrackedMap you have to use new TrackedArray or new TrackedMap – or the shorthand #[]/#{} syntax.

A tracked values via track is not deeply reactive, so mutations to the thing you put into track are not reactive.

[Hebilicious]

Got it, that's what I understood but poorly wrote. Thanks for explaining.

[yamiteru]

If I understand this correctly track is like let in a sense that it keeps track of the "references" (values for primitives and references for complex types) via something like Object.is.

So const a = track([]) will react to the change of the reference which in this case means re-assigning the array where before !== after.

On the other hand const a = #[] will react to the change of the contents of the array, e.g. a.push(0).

We can then mix and match these two concepts together depending on our use-case (aka. do I want to track re-assignment and/or content change?).

I understand and generally like shorthand syntaxes although it does increase the learning curve and/or confusion.

Ultimatelly the choice is between verbosity and simplicity which I think would be OK if all complex values had both the verbose and simple syntax.

What I don't like is that I'll have to write and read code like this:

const a = #[]
const b = new TrackedSet()

I would much better do this:

const a = #[]
const b = #Set()

Or something like this:

const a = new TrackedArray()
const b = new TrackedSet()

[trueadm]

We could definitely do that, but it would be confusing too why someone couldn't do #WeakMap or #WeakSet or #MutationObserver, unless we make it a compiler error and strictly contain it to certain types

[yamiteru]

I guess making it a compiler error makes sense.

You already contain the # symbol only to certain types anyway (it just happens so that usually people don't create object with Object or arrays with Array but it's basically the same thing).

[trueadm]

We shipped this today, so closing.

[leonidaz]

We also have new #Date #URL #URLSearchParams

[trueadm]

Yeah we won't do those. They're just not used enough and also #URL and #URLSearchParams are just terrible. I can see validity in #Date but people should probably be avoiding using Date entirely given Temporal is its replacement (well eventual, Chrome support is coming soon).