You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
constfoo__=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:
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" suffixconstcontrivedVariableWithLongNameSignal=useSignal(0)console.log(contrivedVariableWithLongNameSignal.value)// with double underscores suffixconstcontrivedVariableWithLongName__=useSignal(0)console.log(contrivedVariableWithLongName__.value)// with "_Signal" suffixconstcontrivedVariableWithLongName_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!
The text was updated successfully, but these errors were encountered:
Setting all prior conversation aside, I will summarize my thoughts which greatly favor a lint rule over suffix.
Assuming the following:
constfoo=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?
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?
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:
In both examples, the extra optical space between the actual names of the variables (
foo
andbar
) and the indicators (__
and_Signal
) make it more visually clear that the variables are Signals. An example to bring the point across: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!
The text was updated successfully, but these errors were encountered: