Reactive nested object state

[SIB61]

Suppose i have a object from an api response, and i want to create a reactive state for the object. Currently object properties with $ prefix works reactively. But is there any way to create a whole object reactive? even in nested layer.

[leeoniya]

this is the biggest question i have with frameworks that rely on reactive primitives. let's say i have a bunch of non-trivial state coming from a backend API that needs to be translated into UI state and reflected in DOM - a typical case in my current neck of the woods. with React, the answer is obvious and straightforward with no gotchas, you just feed the new [deserialized from network] state in and get an updated UI out, all without having to figure out what should and shouldn't be reactive (signals, voby, etc) or how to avoid spreads (Solid), or how to handle deep reactivity.

much of this reactivity seems to be done in the name of performance / granular updates (am i wrong?), but imo it's mostly settled by now that frameworks with a sparse / island-esque vdom can be exceptionally fast; i'm partial to ivi these days, though Inferno has certainly held up well over the years with no tweaks :)

[leonidaz]

Having played around with ripple and from what I understood, I think this should work pretty easily.

If you have a bunch of data from the api you can just assign it to a reactive variable and then pass it to the components as per usual. When your api data changes and you need to refetch it, just reassign the reactive variable to it (it would be a new instance of the api data) and then the rest of the app will update.

So, either you pass in the whole api data from the root as a reactive variable $data or if you declare your props as reactive in the child components, you can just pass in just the piece of the data tree that you need.

Obviously, ripple is very young and there may be some caveats / edge cases but so far to me it seems one of the easiest and most intuitive ways to deal with data reactivity.

Here's an example:

function getApiData() {
  return {very: {nested: {stuff: {value: 42}}}};
}

component GrandChild({$value}) {
  <div>{'GrandChild data: '}{$value}</div>
}

component Child({$stuff}) {
  <div>{'Child data: '}{JSON.stringify($stuff)}</div>

  <GrandChild $value={$stuff.value} />
}

export component App() {
  let $data = getApiData();
  let counter = 0;

  setInterval(() => {
    let local = getApiData();
    counter++;
    local.very.nested.stuff.value += counter;
    $data = local;
  }, 1000);

  <Child $stuff={$data.very.nested.stuff} />
}

[trueadm]

much of this reactivity seems to be done in the name of performance / granular updates (am i wrong?), but imo it's mostly settled by now that frameworks with a sparse / island-esque vdom can be exceptionally fast; i'm partial to ivi these days, though Inferno has certainly held up well over the years with no tweaks :)

Not at all. Ripple was firstly about making a great DX experience. Having worked with the AI folks at Vercel and also catching up with those from Anthropic and OpenAI, it's clear that whilst LLMs are good at working with React, they also struggle with it's expressivity – and that's largely because humans do too – and they train it on human code, and that's part of the problem. This whole project was built to make it easier to make coding simpler – and the overwhelming response (from many folks who I never would have even imagined DM me) shows there's something here.

Performance wise. I've not tested it, but it doesn't use signals, it uses lazy top-down rendering (pull only), which is a new technique that hasn't been explored yet in the frontend space. Maybe I'll get around to benchmarking it, but it's hardly all that important. The truth is that performance doesn't sell, and has never done for UI frameworks. I learnt that the hard way from Inferno, well apart from being headhunted to the React team, but those days are long gone now.

[leeoniya]

it's clear that whilst LLMs are good at working with React, they also struggle with it's expressivity – and that's largely because humans do too – and they train it on human code, and that's part of the problem.

do you mean that there are many ways to do the same thing, and the code that has been trained on does not contain a strong signal for the happy path patterns? or do you mean that React just allows you to do too much in general? if it's the latter, then what do you expect Ripple to not allow?

also, how do LLMs do with Svelte / single file components with custom DSLs, and what makes Ripple easier for LLMs to be better vs the previous approaches? and how do you validate these wins when no LLMs have yet been trained on Ripple codebases?

sorry for the wall of questions, but genuinely curious :)

[trueadm]

do you mean that there are many ways to do the same thing, and the code that has been trained on does not contain a strong signal for the happy path patterns? or do you mean that React just allows you to do too much in general? if it's the latter, then what do you expect Ripple to not allow?

The quality of React code out there isn't particularly great. It's been a constant problem with a framework that changes patterns over time, and the assumptions around topics get skewed when it comes to having to provide so much of the workload of the ecosystem to fill.

also, how do LLMs do with Svelte / single file components with custom DSLs, and what makes Ripple easier for LLMs to be better vs the previous approaches? and how do you validate these wins when no LLMs have yet been trained on Ripple codebases?

They do pretty good actually. Definitely better than React code once you provide the correct context.

also, how do LLMs do with Svelte / single file components with custom DSLs, and what makes Ripple easier for LLMs to be better vs the previous approaches? and how do you validate these wins when no LLMs have yet been trained on Ripple codebases?

It's not really about LLMs training on the data, you can easily provide the README for Ripple as context to Claude Code and get going today very well without it having any trained data. It agentic mode it will normally self-validate mistakes against previous context and correct itself. It's early days though, so it's more of a wait and see experiment at this point.

[trueadm]

We offer TrackedObject, TrackedArray, TrackedMap etc etc. You're in good hands now.