Possibility to remove the $ prefix

[LeoVS09]

Want to say that I am really impressed by what you are building. You have found a great blend between frameworks! I love that you keep simplicity and the imperative style of React. while making it possible to define markup alongside TS.
On top of that, simplicity in defining reactive variables is also awesome, but the PHP-like $ prefix makes me wonder about other possibilities.

I understand that for many developers, the $counter variables look good, and it's more like personal preference. But also, there's a big community of devs that aren't really fans of it, for example, React devs. I need to mention that I mostly worked on mainstream frameworks: React, Vue 2, and Angular. So my opinion is based on them. And I am still a big fan of the Vue 2 style of reactive variables. That worked without any specific syntax, and by native object property definition. It was easy to read and simple to understand for new devs.

As a result, I want to understand, can you consider simplifying the syntax a little bit, by making all variables defined inside the component reactive? This way, there will be no need to use $, which will make it easier to read for newcomers, but still will make it possible to define non-reactive variables, without any issues.

Example

There is an example of how it can look

import { effect } from 'ripple';

let maxLimit = 100 // outside of component, not reactive

component App() {
  const initialCount = 10 // const not reactive
  let count = initialCount; // reactive 

  effect(() => {
    console.log(count);
  });

  const increment = () => {
     if(count < maxLimit)
        count++
  }

  <button onClick={increment}>Increment</button>
}

[trueadm]

I get what you're saying, but having gone down this route with Svelte 5, I can tell you that it's simply not possible. Reactivity must be able to live outside of components, for example in utility functions and places like classes etc, this is a key feature and removing that would be too limiting. At the same time, treating everything as possibly reactive gets cumbersome, especially when it comes to things like destructuring and transporting reactivity on objects – something Ripple supports really well today.

[alesvaupotic]

Supporting the $ syntax. It is actually quite good and simple mechanism for newcomers and seasoned devs to distinguish between reactive variables and regular ones. Not all vars need to be reactive, as it would really mean throwing away CPU cycles. As someone who used to program within 64Kb, yes, kilobytes, I am still fond of solutions which are resource efficient. Also, it is especially useful when looking at a piece of code without broad context. Once you see the $ sign, you immediately think "Oh, this will change in time", which is not obvious from just seeing console.log(count); that needs to be read in context.

About learning a new syntax: yes, it is different and not immediately obvious, but so is any function of a framework. You read the docs, learn about it and use it. For example it was quite strange to me when I saw this for the first time:

var app = new Vue({
	el: '#app',
	data: {
		message: 'Hello Vue!', 
		counter: 0
	}
});

Why data? Can't I name it variables? It wasn't straight forward to understand just from reading this piece of code that message and counter are reactive. I had to look it up in the docs. But, with time I got along with it just fine and wrote some beautiful apps with it.

Or, when someone sees const count = ref(0) for the first time out of context, how on Earth does word ref signalize a reactive state? Again, it's just a convention.

So, if we need to somehow define reactivity, $ (or any other sign, for that matter) prefix is the simplest and cleanest solution in my opinion.

Thanks, Dominic, you're doing an excellent job at making our lives easier!

[LeoVS09]

Thank you, Dominic (@trueadm), for clarification. And as I said, you're doing great work. I'm not criticizing, just want to share my opinion, which I hope can help.

I got the reasoning behind specifying some variables as reactive and some not. But my question/suggestion is more about the reason for using naming to specify some syntax, rather than using keywords or syntax for it.

What I mean is that in JS/TS, different kinds of variables are specified by specific keywords that make them distinguishable during reading. For example:

const alice = 1 // I define that it will not change 
let bob = 1 // I define that it can change 

And developers can or cannot use any prefix notation to specify that these variables are different. For example, in the Java/Android world, Google notation has used m prefix to define the scope of fields that are not public.

mAccessibilityDelegade = null // I specify that it will not be used outside of class

Some people prefer it, but the majority of developers decided that it is easy enough to read variable definitions, and there is no need to prefix everything.

Anyway, this is personal development notation. Some companies can use it, some can avoid it. It can be defined between developers. But JS and TS languages specifically avoid making notation part of the languages, to allow different developers to choose what they prefer. So this goes to my initial question. You also made a superset of TypeScript with JSX-like Syntax. So essentially, it is another language, to which you already defined a new component keyword. Can you define one more?

Example

For example, like this:

import { effect } from 'ripple';

component App() {
  $let count = 0; // it variable, but it also reactive

  effect(() => {
    console.log(count);
  });

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

Or like this

import { effect } from 'ripple';

component App() {
  reactive count = 0;

  effect(() => {
    console.log(count);
  });

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

This will allow developers who like the $ notation to continue using it, and developers who do not like it to avoid it.

import { effect } from 'ripple';

component App() {
  reactive $count = 0; // still works as valid code

  effect(() => {
    console.log($count);
  });

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

[trueadm]

The great thing about incorporating $ into the the variable name or property name is that its consistent. If we didn't want reactivity in object literals, then I'd totally go down the route of using custom syntax to define a variable, kind of like the variable decorators TC39 proposal. However, it falls short when it comes to properties – and that's important as passing reactivity around is only possible via objects or closures – that's just how JavaScript works.

When you consume a prop and it's called things how do you know what property is reactive or not? That's important as you might want to consume property called size and at that point you have no idea if this is reactive or not. You'd have to dig through the sourcecode to find out more – and I think it's important to make this clean and easy to read. Reactivity can be done many ways, and you can opt out many ways but having it clear that when creating an effect that you want to untrack the properly $size because you only care for its initial value is important. The alternative is to consider everything possibly being reactive like React, and use dependency arrays, and we all know how much of a mess that has caused the ecosystem with memoization and the requirement to understand how it all works.

[LeoVS09]

Yes, I got what you mean. So essentially, the question is how to define that some properties of an object should be reactive? This sounds like a type definition. Essentially, types in TypeScript are used to signal some specific information about properties or a variable alongside a keyword.

For example, it can be done like with arrays:

import type { Component } from 'ripple';

component Counter({ startingCount }: {startingCount: Reactive<number>}) {
  let count: Reactive<number> = untrack(() => startingCount);
  let double: Reactive<number> = count * 2;
}

For me, it is much easier to read and understand in comparison with $ notation, and there is no need to dig up code to understand something. And on top of it, $ notation is still supported.

import { untrack } from 'ripple';

component Counter({ $startingCount }:  {$startingCount: Reactive<number>}) {
  let $count: Reactive<number> = untrack(() => $startingCount);
  let $double: Reactive<number> = $count * 2;
}

[trueadm]

Yeah we had this topic on the Svelte team, unfortunately TS doesn't work this way. Whilst you can annotate it, they are ambient types and they're lost between boundaries and when you use them in type narrowing scenarios, they also get lost. You can't do that – we all wish we could, but the TS team had a lengthy discussion with us (Svelte team) about how it's not possible.

[LeoVS09]

Oh, okay, thank you for all the answers then! This made the syntax choice much clearer for me.
I also hope one day there will be an elegant solution to it

[trueadm]

We all wish we could have something that solves that goal. If we had, we'd all already be using it. The issue for Svelte was they couldn't really adopt the $ prefix because of their previous stores syntax. Ripple doesn't have that constraint.

[shiftlabs1]

This approach though would need some sort of mapper when a reactive object is being populated say with result (of same properties names without the $) from a fetch or any backend call . It will be ideal if that mapper is provided by the framework , e.g toState and fromState preferably as Object extension methods so we can do const objState=dbresult.toState(); and the other way when for example posting data to the backend await doPostData(objState.fromState())

[shiftlabs1]

This approach though would need some sort of mapper when a reactive object is being populated say with result (of same properties names without the $) from a fetch or any backend call . It will be ideal if that mapper is provided by the framework , e.g toState and fromState preferably as Object extension methods so we can do const objState=dbresult.toState(); and the other way when for example posting data to the backend await doPostData(objState.fromState())

[trueadm]

We removed the $ prefixed last year, closing