Changes to Ripple's reactivity system

[trueadm]

The team have been busy collecting feedback and there has been an overwhelming response that Ripple's current design towards reactivity using $ prefixed variables and properties has shortcomings:

• They're verbose and littered everywhere. They were designed to show intent, but if everything is $ prefixed, then they lose their charm and in reality that means they become a syntax burden. Comparisons to PHP and jQuery $ spam were common, plus it just didn't scale like I originally thought it would.
• The $ prefix has technical problems too, when working with external data incoming, having to prefix object properties to show intent feels cumbersome, not to mention incompatibility with libraries like Lexical that also make usage of $ prefixing.
• If the intent was to show you what was reactive, then it falls down when working with things like arrays, which have numerical indexed properties which can't contain $ prefixes.
• It gives a false fallacy when working with wrapping reactivity patterns, such as functions, methods etc – which don't contain the $ but are still reactive.
• Reactive properties from Ripple are not accessible outside of .ripple modules, as the compiler can't inject the correct logic to make the $ magic work – this has been a big criticism.

So, $ prefixed variables were clearly a flawed design, and we've come up with a solution that we feel solves many problems and drastically simplifies the compiler output. So we're completely removing the $ prefixing logic from Ripple.

The new way – track

track()

We're removing the complicated magic that works, until it doesn't. And we're introducing something we're excited to share:

import { track } from 'ripple';

component Counter() {
  let count = track(0);
}

Here we create a Tracked object that is managed by Ripple. It doesn't expose an API for reading it, it's designed to be a black box that you know contains your state, in the case count. It's TypeSafe and wraps your value.

To access the value inside a Tracked you use @ prefixes at the place of usage:

import { track } from 'ripple';

component Counter() {
  let count = track(0);

  <div>{@count}</div>
}

This tells the compiler that you want to read the value inside the Tracked.

You can also mutate and update count using the @ prefix:

import { track } from 'ripple';

component Counter() {
  let count = track(0);

  <div>{@count}</div>

  <button onClick={() => @count++}>{"Increment"}</button>
  <button onClick={() => @count = 5}>{"Set to 5"}</button>
}

Furthermore, you can easily put a Tracked inside an object to pass it around and use @ inside a object property:

import { track } from 'ripple';

component Counter() {
  let count = track(0);

  const obj = { count };

  <div>{obj.@count}</div>

  <button onClick={() => obj.@count++}>{"Increment"}</button>
  <button onClick={() => obj.@count = 5}>{"Set to 5"}</button>
}

This composes the exact same way. Which makes it really nice to pass reactivity between boundaries or used as props:

import { track } from 'ripple';

component Counter() {
  let count = track(0);

  <Child {count} />
}

component Child({ count }) {
  <div>{@count}</div>
} 

You can even create hook like functions to create and compose state:

import { track, effect } from 'ripple';

function createCounter() {
  let count = track(0);

  effect(() => {
    console.log('Count changed:', @count);
  });

  const updateCount = () => {
    @count++;
  };

  return [ count, updateCount ];
}

component App() {
  const [ count, updateCount ] = createCounter();

  <button onClick={updateCount}>{'Increment'}</button>
}

track(fn)

If you want to create a reactive function, you can just use functions:

import { track } from 'ripple';

component Counter() {
  let count = track(0);
  let double = () => @count * 2;

  <div>{@count}</div>
  <div>{double()}</div>

  <button onClick={() => @count++}>{"Increment"}</button>
}

This works just fine, but in cases where you want the reactive value to be memoized to improve performance and reduce computations, we also offer a track with a function passed to it:

import { track } from 'ripple';

component Counter() {
  let count = track(0);
  let double = track(() => @count * 2);

  <div>{@count}</div>
  <div>{@double}</div>

  <button onClick={() => @count++}>{"Increment"}</button>
}

Now double will never re-compute unless count has changed.

As you can see it keeps to Ripple's theme of being simple and elegant. This design means we get much better type safety, inference and because we no longer need $ prefixed on props, attributes and the rest of it, it becomes far fewer things to learn. You can just assign to the component prop or DOM property like you've always done – no need for that pesky $ prefix.

This also means the $children prop will now simply become children.

Why track?

We thought about using state(), but really state is such an overloaded term. For example, if you don't want to track your variable, and you want to use a RippleArray, then that's fine – and that too is state. We're not a framework that uses signals, so we instead use tracked values – which is actually the same underlying concept that's always been there, so we're just exposing it.

We also considered using computed or derived instead of track, but we decided having a single API for reactivity was better than having a dozen of different ones.

We're open to thoughts on the naming and the design. However, please let us know what you think!

[Darhagonable]

I personally feel like state() and derived() would be more fitting naming and easier coming from other frameworks.

I have one concern with the way derived values are handled either via function or memoization.
A developer might think they could just do this and be confused why it doesn't work.

import { tracked, memo } from 'ripple';

component Counter() {
  let count = tracked(0);
  let double = @count * 2;

  <div>{@count}</div>
  <div>{@double}</div>

  <button onClick={() => @count++}>{"Increment"}</button>
}

[trueadm]

I think we could go with derived instead of memo but I don't think state is right – any object can potentially be stateful. It's misleading and a general confusion point for Svelte 5 that state is a variable binding. Especially if you can deeply mutate that object.

[wobsoriano]

what about computed 😉

[JulienLecoq]

Coming from Angular I’m used to "computed" but your explanation about "memo" makes a lot of sense actually. "derived" or "computed" does not make it explicit that something is memoized. So "memo" looks alright to me.

I think that computed, derived, or memo are all good. And thinking in the direction of the memoized aspect, we could even think of synonyms such as "cached" for example.

[tomByrer]

I'm wondering if track() == useSignal()?

[WebEferen]

@tomByrer nope. We are not using signals at all. It's completely different approach

[JReinhold]

To access the value inside a Tracked you use @ prefixes at the place of usage
This tells the compiler that you want to read the value inside the Tracked.

Maybe this is a dumb question, but why is the @ necessary?

Isn't the variable reference alone enough to tell the compiler this?
To phrase it differently, do you ever want to not access the value inside a Tracked, and just access the Tracked directly?

[trueadm]

Because you could be importing a prop that the compiler knows nothing of:

component Child(props) {
  console.log(props.@count);
}

[levibassey]

To phrase it differently, do you ever want to not access the value inside a Tracked, and just access the Tracked directly?

yes, when you're moving the variable across function boundaries, for example

function createCounter() {
  let count = tracked(0);

  effect(() => {
    console.log('Count changed:', @count);
  });

  const updateCount = () => {
    @count++;
  };

  return [ count, updateCount ];
  
  // if the variable reference alone got you the value, you'd have to wrap it in a closure to get updates
  // return [() => count, updateCount]
}

without the @ you'd have the wrap all your returned values in a closure, like how svelte 5 does it

[opensas]

Because you could be importing a prop that the compiler knows nothing of:

component Child(props) {
  console.log(props.@count);
}

can't we rely on typescript information to know if a variable is tracked?

type Props = {
  count: Tracked<number>
}
component Child(props: { props: Props {
  console.log(props.@count);
}

anyway, I think we need some way to make the distinction between the value and the variable itself, wouldn't the @count be the same as the cont.value we see in other frameworks?

[leonidaz]

Really love it!!! It seems very intuitive and makes total sense. It's like bringing C to JS.

I do have a concern about when to use memo and when not to use it since it works both ways. And if there are use cases where not using them will get into "trouble" and vice versa.

Maybe I need more time to understand it, play with it and look at the compiled code.

Right now everything is seamless and I don't need to use any special syntax, it's all handled behind the scenes with a compute wrapper.

But now, it will be everything like before computed automatically (or are there gotchas), plus I need to think where and how to use memo. And it's not very clear what the difference is because it seems that may not be any in certain situations.

So, basically this introduces a level of unpredictability which can make people uneasy and constantly ask questions, especially given how in react people have to employ useMemo everywhere.

Perhaps it should always be required? Or given the architecture, things will be reactive anyway?

Again, awesome idea and amazing work to get the reactivity figured out!

[kuechlerm]

The @ stumped me for a second, but when you consider the cases where you do not use an @ I think it is helpful to see where you interact with a tracked value.

Maybe a bit off-topic but with this in mind, do you see a way where the LSP can signal to the editor / dev that a variable / property is a Tracked (when displaying type information of stuff that is suggested by autocompletion and also values / props that are already in the code)?

I like "tracked" and have no feelings about "memo". I think it is helpful to have names that are somewhat unique to effortless realise that you are looking at Ripple code.

[leonidaz]

we're going to rely on TS and see if we can get some distinct syntax highlighting for the types that we'll expose.

This is still TBD but we think it's doable at this point.

[opensas]

we're going to rely on TS and see if we can get some distinct syntax highlighting for the types that we'll expose.

This is still TBD but we think it's doable at this point.

so vscode will tell us something like count: Tracked<number>???
what about nested propeties, will it be something like

type State = {
  count: Tracked<count>,
  nested: Tracked<complex-obj-here>,
  // or perhaps something like
  nested: {
    leaf1: Tracked<xxx>
    leaf2: Tracked<yyy>
}

[leonidaz]

Yes, it should work now, but you need to declare them. If you take a nested object and use Tracked type it only tracks the object itself as reactive which is how ripple works. It does recognize initializations automatically.

maybe, gotta try and see, we can create a type TrackedDeepObject where every nested prop is reactive and TrackedShallowObject for just the first level.

[mauriziocescon]

Nice change! I wonder:

1. If memo is a Tracked, does it mean I can change its value directly? And the value gets changed if count changes?

import { tracked } from 'ripple';

component Counter() {
  let count = tracked(0);
  let double = memo(() => @count * 2);

  <button onClick={() => @double = 5}>{"Set double to 5"}</button>
  <button onClick={() => @count = 2}>{"Set double to 4"}</button>
}

2. do you plan to forbid / warn about props mutations inside children?

import { tracked } from 'ripple';

component Counter() {
  let count = tracked(0);

  <Child {count} />
}

component Child({ count }) {
  <div>{@count}</div>
  
  <!-- I'd say ❌ -->
  <button onClick={() => @count++}>{"Increment"}</button> 
}

Thanks a lot!

[trueadm]

Assigning to a memo/computed will temporarily override the value until a new change comes in

[trueadm]

Should we just rename memo to computed or derived?

[WebEferen]

I would pick computed as memo here will be a bit more confusing.

[leonidaz]

Should we just rename memo to computed or derived?

I don’t have a problem with the name memo, it’s short and easy to say. I just wanna first understand the difference when to use it and when not to use it or actually what happens when you don’t use it, how the computed value is still calculated

[WebEferen]

How about changing tracked() to atom().
It can be easily pronounceable when multiplied (imagine: 5 atoms within the component).
Has good meaning of the reactive / atomic / small change.

Sounds pretty good and also some developers (especially React ones) are familiar with atoms.
There is a react library called jotai that does (sort of) reactive state management and it actually names it's state as atoms.

[trueadm]

We're not going to use signal because we're not using a signal. If you know what a signal means (I do, I'm a TC39 advocate for that proposal) than you simply can't do that. It's a bit like saying this is a "petrol car" but the car is actually an "electric car", even if they are both similar looking and performing cars . You're lying about the mechanics and that doesn't bode well.

[JulienLecoq]

Yeah, I do use signals every day for my Angular apps and also implemented a signal library for a UI library I’m working on in Odin.

For me it’s just an implementation detail, but I wouldn’t argue on that since it’s just a minor concern. As I said in another comment, tracked is a good name. I like it too 👌

And I’m also considering the "tracked" way for my library in a v2 so I’m really interested to see how it goes in the futur 😊

[JulienLecoq]

Actually the word signal() would be closer to the Solid signals which we also try to avoid (same as state, reactive and other popular ones)

Haha I don’t like state() it does not says anything about how the reactivity works behind the scene, it’s used in so many different ways that makes it impossible to predict the behavior between one or another framework.

[SIB61]

@JulienLecoq Ripple as a library doesn't use signals for reactivity. Just like React doesn't. you use signals in angular because signals are implemented in angular. As signal refers to a very specific way of reactivity implementation and ripple doesn't use that implementation so naming a reactive value as signal is like lying.

[JulienLecoq]

@SIB61 #236 (reply in thread)

[tpbeldie]

I have a small observations that other people might have. In my opinion, it is too verbose and adds more in the sea of frameworks. I'll recommend either go this route:

tracking count = 0;
track count = 0;
watch count = 0;
ref count = 0;
state count = 0;
derived count = 0;

Or a more symbolic approach in var name:

let *count = 0;
let &count = 0;

Or as function, but get rid of tracking... too verbose, too unique (not necessarily good).

let count = track(0);
let count = watch(0);
let count = ref(0);
let count = state(0);
let count = derived(0);

Do not reinvent the wheel. Just use the wheel to push yourself further.

[opensas]

I agree that if the implementation has nothing to do with signals we shouldn't add to the confusion calling them so, I think it's better to reflect what they actually are, so track sounds fine

derived or computed sounds good if they are really so, if it's just a way to cache values and avoid recalculating them memo reflects better that purpose

one question, why do we even need it?

I mean, isn't the purpose of a tracked variable to automatically update the context where it is being accessed whenever it changes?

Or the memo call is just for those cases where count is assigned the same value it had before? and in that case, can't the compiler catch those cases and simply avoid recalculating dependent variables?

let double = memo(() => @count * 2); // I don't quite get why we need the memo() func

[JulienLecoq]

Yeah, but it's definitely not signals. So why would we call it a signal?

Because it behaves exactly the same on the user side (if I’m not mistaken). I still have to take a closer look on how you manage "deep signals", or the problem of the equality function for the update mechanism on objects and arrays.
Anyways, if you think it needs another name than "signal" it’s not a problem at all, it’s just a name after all that denotes reactivity and tracked seems to be a very good fit for that. Also it can helps to avoid confusion with the JS signal proposal if this is accepted.

As long as we avoid the useless "create" verb of SolidJS I’m all good. It’s really something that I don’t like. It makes the code so much more verbose for no reason imho.

[JulienLecoq]

I agree that if the implementation has nothing to do with signals we shouldn't add to the confusion calling them so, I think it's better to reflect what they actually are, so track sounds fine

derived or computed sounds good if they are really so, if it's just a way to cache values and avoid recalculating them memo reflects better that purpose

one question, why do we even need it?

I mean, isn't the purpose of a tracked variable to automatically update the context where it is being accessed whenever it changes?

Or the memo call is just for those cases where count is assigned the same value it had before? and in that case, can't the compiler catch those cases and simply avoid recalculating dependent variables?

let double = memo(() => @count * 2); // I don't quite get why we need the memo() func

memo() allows to cache the result of the function body. So if you call the double() function for example 10 times in a row without changing the count, the function body will only be run once instead of 10. It allows to remove useless computation. The body will only be reevaluated if at least one of its tracked value change.

[opensas]

@JulienLecoq thanks for the explanation, but I thought that ripple worked like svelte or solid, meaning that the component was only executed once, like a regular js function, and not with every change like react does. that's why the memo() didn't make sense to me
I guess I'm still missing something

[trueadm]

We've removed memo we're going with track for both cases.

[opensas]

It's really great that the team is paying so much attention to early feedback, congrats!

I have one question

Will typescript (and thus the compiler) be aware of a variable being tracked, something like

let count: Tracked<number> = tracked(0)

because in that case, the compiler could "know" that it's a reactive, I mean, tracked variable and thus generate the code to access or mutate the value, without the need of the '@'

am I right?

---

on the other hand, having ts recognize a Tracked variable, would allow typescript to check and enforce when we actually need a tracked variable, something like what we had with svelte 3 and Writable

---

and a suggestion, I think it would be great if the '@' (in case we still need it) would be just syntax sugar

meaning that we could write

import { tracked, memo } from 'ripple';

component Counter() {
  let count = tracked(0);
  let double = count.get() * 2; // @count * 2;

   [...]
   
  <button onClick={() => count.set(count+1)}>{"Increment"}</button> // @count++
}

that way it would be crystal clear what the compiler is actually doing

(ok perhaps the compiler is doing much more than just that...)

---

btw, how are you currently handling nested reactivity?

If I have a complex object, do I have to issue @state.parent.child = 999or state.parent.@child = 999 and how does reactivity is triggered when a nested object is updated?

[WebEferen]

Let's split that into three sections:

1) Will typescript (and thus the compiler) be aware of a variable being tracked.
Yes, it will be aware of what is actually being tracked. It will actually type variable as Tracked (typename is a subject to change).
So you should be able to easy and safely modify it's content (like number * @_count [without underscore]).

2) Sugar syntax and reactive.get()
We discussed internally that we don't want to follow the path of Sveltes .value, or context like .get() to retrieve the value. The compiler would be smart enough to actually strip the @ and based on it's presence it will either serve the reference to pass or the value itself. This is why we don't need actual .get() or other known accessors.

3) Nested reactivity
Shortest answer to your question is to actually use the closest tracked property (and track it again):

import { tracked } from 'ripple';

export component App() {
  let initial = tracked({ a: 10, nested: { b: 0 } });

  <button onClick={() => { @initial = { ...@initial, a: 15, nested: { b: 5 } } }}>{@initial.nested.b}</button>
  <p>{@initial.nested.b}</p>
  <p>{@initial.a}</p>
}

Edit: Sorry I've made a typo. There's no direct setter for objects (reactive setter), so you cannot do @initial.nested.b = 5. You need to deconstruct the object and recreate it, then change the value.

[JulienLecoq]

Seems like a deepTracked would be a good fit for such use case to avoid unnecessary recomputation/rerender.

Also, to avoid deconstructing the object an "immer" wrapper could be nice no? That’s what I’ve done for my apps based on signals in Angular.

[opensas]

@WebEferen thanks a lot for the quick reply

I think it's a good thing that typescript is aware of reactivity, and can thus enforce, the use of tracked variables

I hope you can find a better way to deal with nested reactivity, deconstructing objects is not the best DX in my opinion. perhaps the compiler could do something like what @JulienLecoq proposed with immer behind the curtains

achieving transparent, fine-grained and performant nested reactivity with no proxies would be something that no framework has achieved so far, at least as far as I know

[leonidaz]

"Just keep track of it, man."

I and @WebEferen are actually heavily leaning towards:

track() with track.by() and untrack()

it totally makes sense. you're telling Ripple, "hey Ripple, track this for me" and "track it by using this expression", but now "untrack this for me"

it's very elegant and simple, much simpler than in other frameworks, basically it's just one word. no clunky derived or computed, useMemo, abuseMemo...

The track.by is connected to track (literally and semantically) and they both return the same thing, and overwriting it temporarily makes more sense than other words. Explanation: variable set by track.by can be temporarily overwritten, until track.by's dependencies change.

It is short to write, remember and easy on the tongue to pronounce. And this is also good for non-native English speakers as this is a pure form of a verb.

"C’mon, just track it, man."

[opensas]

I think that instead of, or in addition to, untrack it would be useful to be able to explicetely tell the dependencies, sometimes it's easier to read an reason about what I DO want to track than what I don't want to

it could be a track.by(exp, dependencies) with dependencies being an optional array of things to track, a change in any of the dependencies would trigger reactivity, and nothing else)

[levibassey]

I think that instead of, or in addition to, untrack it would be useful to be able to explicetely tell the dependencies, sometimes it's easier to read an reason about what I DO want to track than what I don't want to

yeah, no. it's not that often that you need to untrack something, so having to list dependencies even when you intend to track everything sucks and having 2 ways to do the same thing is no good

[levibassey]

I and @WebEferen are actually heavily leaning towards:

track() with track.by() and untrack()

how about just track() and untrack, no need for untrack.by

[opensas]

I think that instead of, or in addition to, untrack it would be useful to be able to explicetely tell the dependencies, sometimes it's easier to read an reason about what I DO want to track than what I don't want to

yeah, no. it's not that often that you need to untrack something, so having to list dependencies even when you intend to track everything sucks and having 2 ways to do the same thing is no good

It seems I want's clear enough. I'm not proposing two different ways to do the same thing, nor passing always all the dependencies

just having an optional extra parameter to override the dependencies, being able to explicitly define the dependencies, for those rare cases where you want to have more control over the reactivity process

[levibassey]

ok, fair, I personally don't see the need but it's not a bad idea

[bradleat]

Isn’t the @ all you need?

You can trace the @ back to the declaration and track it at compile time.

[aleclarson]

not across function boundaries. javascript is too dynamic for that, IIUC.

also, reactivity in javascript is infective. if one @ retroactively turns a variable reactive, then all references must be wrapped (at compile time), which adds complexity to the compiler.

finally, explicit tracking is better at communicating developer intent

[murnifine]

I like the idea, track() and memo() very elegant 😎
The pronunciation is short and clear.

import {  track, memo } from 'ripple';

component Counter() {
  let count = track(0);
  let double = memo(() => @count * 2);

  <div>{@count}</div>
  <div>{@double}</div>

  <button onClick={() => @count++}>{"Increment"}</button>
}

But it's a bit strange because track() already makes the variable reactive, so why do we still have to use @, when it's clear that the variable count is already reactive. Just do it like this.

import {  track, memo } from 'ripple';

component Counter() {
  let count = track(0);
  let double = memo(() => count * 2);

  <div>{count}</div>
  <div>{double}</div>

  <button onClick={() => count++}>{"Increment"}</button>
}

The use of @ would make more sense if the reactivity occurred when the variable was used, but I don't know if this idea can be implemented. for example:

import {  memo } from 'ripple';

component Counter() {
  let count = 0;
  let double = memo(() => @count * 2);

  <div>{@count}</div>
  <div>{@double}</div>

  <button onClick={() => @count++}>{"Increment"}</button>
}

[JulienLecoq]

Even with "track()" it’s not clear that a variable is reactive because you have to go to the declaration of this variable to know this.

If you only look at its usage, without the @, you can’t determine that a given variable is reactive. VueJS has the same problem, you can’t know by the usage if something is reactive. SolidJS and Angular solves this by using function calls which makes it explicit that something is reactive.

Also, the @ allows to make it reactive so if you want to untrack it, you just have to remove the @ which is nicer than calling something like untrack(myReactiveVariable)

[leonidaz]

We’re planning to try to do special syntax highlighting and also Typescript will tell you, e.g. on mouseover. There’s not much usage for just the tracked object (without @) except for passing it to others. So, there are not even opportunities to use untrack on it. You need untrack where you would use @Tracked if you don’t want the block that uses it be dependent on its reactivity.

[basst85]

I’d keep tracked() for the source and rename memo() to computed() (and alias derived()?). “Computed” communicates a reactive, cached derivation and “memo” reads like a perf hint (React-style) rather than a graph node. And computed() feels familiar across other frameworks.

[Xander-de-Keijzer]

I really like this

import {  track, memo } from 'ripple';

component Counter() {
  let count = track(0);
  let double = memo(() => @count * 2);

  <div>{@count}</div>
  <div>{@double}</div>

  <button onClick={() => @count++}>{"Increment"}</button>
}

But wouldn't it be possible to omit the () => and @ in memo? It already indicates the reactive memoization, so something like:

  let count = track(0);
  let double = memo(count * 2);

[levibassey]

svelte had this issue with their $derived and later had to introduce $derived.by, ripple could do the same thing, which is not bad, but I'm personally not a fan of having multiple ways of doing the same thing

[Darhagonable]

id say the idea is for the function to be optional

[Xander-de-Keijzer]

You could still just do this right?

let filter = track("all")
const filtered_todos = memo(
    if(filter === "done") {
        todos.filter(t => t.done)
    } else if(filter === "active") {
        todos.filter(t => !t.done)
    }
    todos
)

Or we could just have a more custom syntax like this

let count = track(0)
let double = memo { count * 2 }

let filter = track("all")
const filtered_todos = memo {
    if(filter === "done") {
        todos.filter(t => t.done)
    } else if(filter === "active") {
        todos.filter(t => !t.done)
    }
    todos
}

[levibassey]

JS devs will take any obscure syntax over writing just 4 extra characters, why so allergic to functions lol

[Xander-de-Keijzer]

I'm not a JS dev, just sharing some ideas based on Kotlin Lambda's

[riderx]

I dont get why memo exist ?
There is case where the tracked didn’t change and you want to re compute it ?
Same for the @ you already know you named the variable with tracked why add another layer?
Look at vue 3 and ref and compute it’s super simple.
No one get confused, coming from Vuejs i would come to ripple if you keep it simple

[levibassey]

Same for the @ you already know you named the variable with tracked why add another layer?

[levibassey]

I dont get why memo exist ?

memo is the same as computed in vue, so I don't get your complaint

[riderx]

Thanks for the @ it make sense.
For the compute it doesn’t TBH.
I mean the function exemple should by default do the memo, unless there is case where that doesn’t make sense?

Otherwise you end up like react where app have stupid low performance because people forgot to memo everything.

The cool part in vue is you never have to memo it’s by default.

and this increase a lot the overall quality of what is produced.

[joshua1]

The @ when reading values is fine , but when writing values ? i think it makes sense and reads well to just assign the value without the @ appended

import { tracked } from 'ripple';

component Counter() {
  let count = tracked(0);

  <div>{@count}</div>

  <button onClick={() => count++}>{"Increment"}</button>
  <button onClick={() => count = 5}>{"Set to 5"}</button>
}

[trueadm]

That doesn't make any sense. count++ also reads the value.

[tpbeldie]

Debate closed, for I have spoken:

let count = track(0);
let double = memo(() => @count * 2);

effect(() => {
  console.log("Count is:", @count);
  console.log(untrack(() => @count)); 
});

We can close the thread, admin!

//.

May I also suggest:

let val = raw(count);

As substitute of count.value.

[aleclarson]

Excuse me if this has been asked before.

Why is tracking not opt-out, instead of opt-in? (Because you need Ripple to be a superset of TypeScript?)

Imagine this:

component Foo {
  let count = 0
  let double = count * 2

  <span>Count is: {count}</span>
  <Bar count={@count} />
}

• The count variable is implicitly tracked, because it uses let.
• The double variable is implicitly tracked as well, and it depends on count; therefore, it will re-evaluate when count is mutated.
• Both count and double are typed with number. Reactivity is transparent.
• References to tracked variables inside components subscribe by default.
• Opt out: Use the const keyword for "compute once" variables.
• Pass by reference: Use the @ unary operator to "box" a tracked variable (postponing subscription until it's referenced e.g. within the Bar child component).
• Component props: Props are tracked by default.

Just curious if you considered this approach and what your conclusions were. Thanks!

[levibassey]

how would this work with deep reactivity?

[trueadm]

I covered this in my posts on X.com, but we tried this with Svelte 5, it's not practical. Reactivity isn't contained to components, it can be in generic functions and in effects. So this means that you start adding a ton of overhead for things that are never intended to be reactive.

[aleclarson]

how would this work with deep reactivity?

A couple ways to go. Could be opt-in.

I'm a fan of valtio's approach. Deeply reactive by default.

Example (click this)

component Foo {
  let frame = {
    position: { x: 0, y: 0 }, 
    size: { width: 10, height: 10 },
  }

  <div style={{ top: frame.position.y, left: frame.position.x, width: frame.size.width, height: frame.size.height }} />
  <button onClick={() => frame.size.width *= 2}>Widen</button>
  /* etc. */
}

• By default, only built-in objects would be deeply reactive (e.g. plain objects, arrays, Maps, and Sets).
• For custom class declarations, use extends with the RippleObject/RippleArray/etc class.
• Opt-out: Use const to opt-out of nested tracking.

  const notTracked = { a: 0 }
  let tracked = { b: notTracked }
  // tracked.b is reactive
  // tracked.b.a is not *unless* re-assigned to a reactive object

  Another option would be to have a ref(object) function that prevents deep reactivity.

[levibassey]

yeah, but this requires proxies and I'm not a fan of deep reactivity with proxies being the default

[aleclarson]

I covered this in my posts on X.com, but we tried this with Svelte 5, it's not practical. Reactivity isn't contained to components, it can be in generic functions and in effects. So this means that you start adding a ton of overhead for things that are never intended to be reactive.

I will go look, thanks.

I guess the main hurdles are:

• Ripple wants to transform reactive references at compile time, so it either needs explicit markup or assume everything is a reactive reference (bad for performance).
• Ripple wants the ability to declare tracked variables in module scope.

Did I miss anything?

[leonidaz]

We've had a conversation on discord on #general and also, I've been thinking about this as well....

So, track / tracked / whatever can be both tracked and memo.

But if you actually need to track a function swap, which is by far a much less common case, then you use a special function, maybe just track.func() or trackFunction or we can come up with something better.

So, this way, for most devs, for 98% of the time you just use one function track() and don't need to think "do i need to use track or memo here", and we document and teach that for tracking actual function changes use trackFunction ?

[trueadm]

Let's just stick with track for now :)

[leonidaz]

or actually for tracking function swaps, we can just add a second parameter to track and we don't need another function.

function track<T>(value: T): Tracked;

function track(fn: () => void, swapOnly: boolean): Tracked;

[RATIU5]

I noticed this code snippet that you provided:

import { track } from 'ripple';

component Counter() {
  let count = track(0);

  <Child {count} />
}

component Child({ count }) {
  <div>{@count}</div>
} 

Since count is directly being passed in to another component, how are users to know that they need to access it via @, without going up the component props tree and determining if it's a track() value? This is rather minor and might not be directly in the scope of this topic, but I'm just curious how easy it will be able to spot especially if components pass props around in different files.

[leonidaz]

use'd use TS to declare like anywhere else to know what it is. e.g. count: Tracked<number>

[RATIU5]

Ah that would make sense. Wasn't sure if TS would be able to pick that up, but that would work.

[opensas]

I guess that ripple could be smart enought to warn you when, depending on the context, it looks like you should be using @var instead of var for a Tracked var

If I understand correctly if you export pass @var to a function you would be passing the static value, if you pass the var it would be a reactive reference

am I right?

[leonidaz]

Yes on passing. For being smart enough, ripple could compile things a bit differently in dev mode and warn people on mutations or trying to use Tracked in templates, loops, if’s, etc.

Also we’ll encourage people to use Typescript to annotate code. And we’ll try to get special syntax highlighting in editors that can support it.

But even without dev compile, the app will break most of the time.

[RickDT]

we decided having a single API for reactivity was better than having a dozen of different ones.

👏 very good

[levibassey]

@trueadm what's async going to look like with this new model?

[trueadm]

Nothing concrete right now to share. I’ll get around to it soon

[emeraldlinks]

I honestly love the way this whole thing is going. however, if we use track for lets say let count = track(0);
we get track(value: number): Tracked. it all works except a slight warning when you try performing some operations like maths <button onClick={() => @count++}>{"+"}
An arithmetic operand must be of type 'any', 'number', 'bigint' or an enum type.

also let matched: Route | null = track(null);
this does not ensure that Tracked matched is actually a type Route.
Type 'Tracked' is missing the following properties from type 'Route': path, componentts(2739)

i might be wrong but could you help me me understand a little bit?

[WebEferen]

For the onclick I'd say that you'd need to use addition without returning the value of count:

<button onClick={() => { @count++ }}>{"+"}</button>

[WebEferen]

But regarding the typesafe properties ensuring, we need to find a way to make sure that @variable when you reassign it would match the type provided initially

[trueadm]

Thank you for all the support and ideas. We've landed on using track and track(fn). You can now use this today in Ripple and the docs, playground, website and README have all been updated!