Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Suggestion: Possible shorthand for indicating variables are Signals #2

Open
shiroinegai opened this issue Feb 14, 2023 · 2 comments
Open

Comments

@shiroinegai
Copy link

This is probably a controversial suggestion but would it possibly be a good idea for Signals to be represented by a double underscore suffix like so?

const foo__ = useSignal(0)

console.log(foo__.value)

A cursory search doesn't bring up much usage of trailing double underscores in general and it would be a much terser way to convey that a variable is a Signal if adopted. Considering how much Signals will be used for any Qwik project, I think it's reasonable to not type out "Signal" in full each and every time.

Another reason why I'm suggesting this is that the general convention for variable names are usually in camelCase and suffixing "Signal" to them just blends in with everything else, making it hard to scan your code for Signals by eye.

Since the intention is to explicitly indicate that a variable represents a Signal, it could also be represented with an extra underscore like so:

const bar_Signal = useSignal(0)

console.log(bar_Signal.value)

In both examples, the extra optical space between the actual names of the variables (foo and bar) and the indicators (__ and _Signal) make it more visually clear that the variables are Signals. An example to bring the point across:

// with "Signal" suffix
const contrivedVariableWithLongNameSignal = useSignal(0)

console.log(contrivedVariableWithLongNameSignal.value)



// with double underscores suffix
const contrivedVariableWithLongName__ = useSignal(0)

console.log(contrivedVariableWithLongName__.value)



// with "_Signal" suffix
const contrivedVariableWithLongName_Signal = useSignal(0)

console.log(contrivedVariableWithLongName_Signal.value)

Just as an aside, the first example would possibly work better for people with a preference for snake_case variables (which seems to be slowly growing in popularity) since suffixing "signal" would similarly blend in for them. Though I suppose in snake_case, capitalising "Signal" would be enough to make them easily scannable.

This is just a suggestion and I don't have strong opinions about it, just putting it out there for consideration!

@n8sabes
Copy link

n8sabes commented Feb 15, 2023

Setting all prior conversation aside, I will summarize my thoughts which greatly favor a lint rule over suffix.

Assuming the following:

const foo = useSignal(false);

a) if( foo ) { } is a valid test, but if( foo.value ) { } is likely the intention of the developer.

b) const _foo = foo is a valid assignment, but const _foo = foo.value is likely the intention of the developer.

c) foo = true is caught as an error due to const immutability, whereas foo.value = true is likely the intention of the developer.

In all of these examples the intention is foo.value. I am sure there are other syntax examples, but it seems like a lint Warning may be the best. -- If a lint warning is not possible, then suffix fooSignal.

I feel fooActionHandler is unnecessarily long, but similar reasoning should be used where necessary for consistency.

@manucorporat, since this is your baby, what are your thoughts?

@wmertens
Copy link

Why not S as a suffix, and a lint rule that looks at the name?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants