This React naming convention is rubbish

Stu Pocknee

26 Aug 2025

coding

⌨️⌨️⌨️

The one I am talking about:

const [name, setName] = useState("Joe");

I'm fine with the mechanics of this "destructured getter/setter tuple" arrangement. It's the "value, setValue" tuple naming that irks me.

⌨️⌨️⌨️

Some history.

I started coding C# in the early 00's. When XAML came online I latched on to it. Bindings were (and still remain) a nightmare at times, but compared to the old manual ways of wiring-up UI updates they were a godsend.

<TextBlock Text="{Binding Name}" /> 

At some point in the 10's I started creating fairly involved web applications. It coincided with the advent of KnockoutJs. I saw the similarities with XAML, so grabbed that library with both hands.

Knockout introduced me to the horrible concept of setting and reading a variable in the following way.

//set variable equal to 6
foo(6);

//read variable
var result = foo();

There are various reasons to dislike this way of doing business, not least the difficulties in having to call a function in order to evaluate a 'variable' while debugging. But in the spirit of being grateful that javascript could do this at all, I held my nose and got on with the job.

React was something I avoided. Not sure why. By the time it came about I'd probably been coding for 15-20 years and was pretty much done with grabbing the "next shiny thing". I had tools that worked, so I stuck with them.

By the advent of the 20's I had moved away from web programming.

When I returned to it a little while back I found my old faithful Knockout library was pretty much a dead project.

Reluctantly, I cast about for something else.

I settled on SolidJS. Not really sure why.

Mumble mumble.. something about being like React except more moderner and more betterer.....

So far it's been an ok decision. I've built some half decent things.

⌨️⌨️⌨️

The issue.

The thing I struggle with is this particular naming convention:

const [name, setName] = createSignal("Joe");

For those paying attention, this is very similar to React's method above and (as I understand it) derives from this source.

Why don't I like it?

I've previously noted I like my code to exhibit certain traits, including:

• Specificity - say exactly what you mean
• Simplicity - use fewer of all the things
• Clarity - write code in a way that maximizes the readers ability to interpret it

Having a "foo" variable and a "setFoo" variable immediately introduces a discontinuity.

To me, if you have a "setFoo" and it is a setter, you need a "getFoo" as a getter. End of story.

const [getName, setName] = createSignal("Joe");

Better? A little.

The problem with these 'variables' is that they are not variables. They are functions.

You use them like this:

// form a new name
const newName = `{Mr ${getName()}`; 

//update the name
setName(newName);

Problem?

Well, yes. In my code I have plenty of functions with names like:

score();
getCurrentDate();
setLatestResults(results);

These are not SolidJS signals. They are functions that involve some calculations, or database access, or whatever. They aren't variables. I hate that I often can't can't immediately discern whether something is a variable, a regular function, or a "special function" (SolidJS signal).

Consequently, I have my own naming convention for SolidJs Signals.

const [getNameFn, setNameFn] = createSignal("Joe");

• Getters are named as getters.
• Setters are named as setters.
• Both are clearly marked as functions, despite being 'variables'. Ending in 'Fn' reminds me to add the ().
• The convention is unique in my code, meaning I immediately know these functions are reactive variables.

Is it more verbose? Yes. I don't care. It's clearer and, for me, better.

Am I being pedantic? Of course. Can you call yourself a coder if you're not? 🤷

⌨️⌨️⌨️