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
I'd like to suggest a configuration option for whether or not the naming convention should include the $ symbol since it does avoid confusion, but it's personally a bit redundant in my opinion, it does help discern the store from the parameter though but it's just not my cup of tea
Description
Configuration option that enforce stores being passed to the function as parameters, but not enforce adding $
/* Never *//* ✓ GOOD */derived(a,(a)=>{});derived(a,(a,set)=>{});/* Always (current, default) *//* ✓ GOOD */derived(a,($a)=>{});derived(a,($a,set)=>{});/* Ignore *//* ✓ GOOD */derived(a,($a)=>{});derived(a,(a,set)=>{});/* ✗ BAD */derived(a,(b)=>{});derived(a,(b,set)=>{});derived([a,b],([one,two])=>{});
The text was updated successfully, but these errors were encountered:
Motivation
I'd like to suggest a configuration option for whether or not the naming convention should include the
$
symbol since it does avoid confusion, but it's personally a bit redundant in my opinion, it does help discern the store from the parameter though but it's just not my cup of teaDescription
Configuration option that enforce stores being passed to the function as parameters, but not enforce adding
$
Examples
The text was updated successfully, but these errors were encountered: