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
A bit. The thing about React components is that all methods should be private so we just save ourselves the typing and don't insert the leading underscore.
What do you mean? If I have e.g. a ref to an element, I can call methods on it just fine. I've seen this used to implement e.g. getValue methods on things like complex, uncontrolled input components for forms.
If you consider this an anti-pattern, it could be useful to add a clarifying comment to say to not do this. There are definitely problems with this pattern - it's not container-safe, for one.
Personally, I think this pattern is horrifically bad. Things that are not private are not private - sticking an underscore in front of them doesn't make them private, it just lulls you into the false belief that you can make a breaking change without bumping a major version.
It's not private if it's accessible in the runtime. If it's private - ie, via closure or WeakMap - no convention or unit tests are needed. If it's not, it's public, and you must test it, and whether you document it or not, it is public and breaking it counts as a breaking change. At that point, using a leading underscore is just fluff, so why would you need a convention for it?
Reacted by Donavon West, Stian Liknes, Tom, Ryan M., David Ash, Michael Altamirano, Yvonne Ng, Second Datke, Hans Ott, Bryan Manuele and 5 more
Reacted by 乔健, skykit-karlkroening, minomikula, Jeremy Banks and Tonci Kokan
We should probably just remove this section from the main style guide or rephrase it. Same with the React style guide. This whole attachment to "private" is what makes the rules seem confusing.
Reacted by Jordan Harband, Jimmy Jia, miguel and Tom
@ljharb Your points are very valid and I guess the Javascript Ecosystem has a history of "working around the language" read CoffeeScript, TypeScript, React & JSX etc.
But you must agree the leading (and trailing) underscore is pretty much prevalent in the Industry.
And there are some more heavyweights too apart from the above.
Your point about working with the language is well taken. I personally feel though that this style guide could be better off taking a solid consistent stand throughout.
@gaurav21r I believe Polymer is from Google, so your three examples are really just two. Also, someone being a "heavyweight" is a poor reason to make any choice.
This style guide does take a solid and consistent stand: do not use ES5 getters/setters; and do not use underscores at all (trailing or leading), nor anything else that attempts to convey soft "privacy". The reasons are hopefully communicated well. If they can be improved, PRs are most welcome!
Just because a language provides functionality does not mean it is the best or most appropriate choice to achieve a goal, nor that using an alternative is "going around the language". You can do lots of things with eval or with, but that doesn't mean it's ever a good idea.
I didn't really understand all this fuss about truly private variables until I connected it with the concept of Hyrum's Law.
With a sufficient number of users of an API,
it does not matter what you promise in the contract:
all observable behaviors of your system
will be depended on by somebody.
This is intuitive to me and makes clear sense. With that in mind and the scale of Airbnb it makes sense why this rule exists in their style guide and how 'fake private' is really just plain old 'public'.
Activity
goatslacker commentedon Aug 28, 2015
A bit. The thing about React components is that all methods should be private so we just save ourselves the typing and don't insert the leading underscore.
taion commentedon Aug 28, 2015
What do you mean? If I have e.g. a ref to an element, I can call methods on it just fine. I've seen this used to implement e.g.
getValuemethods on things like complex, uncontrolled input components for forms.If you consider this an anti-pattern, it could be useful to add a clarifying comment to say to not do this. There are definitely problems with this pattern - it's not container-safe, for one.
afilp commentedon Oct 25, 2015
I am also interested in an explanation to that. Not all methods are "internal" if we consider that we may call a component's method from the parent.
Example:
parent.jsx
childComponent.jsx
So, what is our general take on this? Do we still write all methods without any underscore?
taion commentedon Oct 25, 2015
👍 Facebook, for example, use this pattern extensively: https://github.com/facebook/relay/blob/v0.4.0/src/container/RelayRootContainer.js
hbrls commentedon Oct 26, 2015
@taion what about v0.14
taion commentedon Oct 26, 2015
What about it?
ljharb commentedon Oct 26, 2015
Personally, I think this pattern is horrifically bad. Things that are not private are not private - sticking an underscore in front of them doesn't make them private, it just lulls you into the false belief that you can make a breaking change without bumping a major version.
It's not private if it's accessible in the runtime. If it's private - ie, via closure or WeakMap - no convention or unit tests are needed. If it's not, it's public, and you must test it, and whether you document it or not, it is public and breaking it counts as a breaking change. At that point, using a leading underscore is just fluff, so why would you need a convention for it?
taion commentedon Oct 26, 2015
@ljharb
That's totally fine - I personally don't mind writing my code either way (as long as I can point to a style guide and say that I'm following it).
The issue is that this style guide appears to be inconsistent between https://github.com/airbnb/javascript#22.4 and https://github.com/airbnb/javascript/tree/master/react#methods. I don't see how it's possible to follow both.
ljharb commentedon Oct 26, 2015
React is a special subset - you could follow both by using
_-prefixes in non-React code. I don't see a logical disconnect there.taion commentedon Oct 26, 2015
Okay. If that's intentional, I can live with it.
ljharb commentedon Apr 12, 2016
JS doesn't have privacy. Underscore-prefixed things are just as public as anything else.
goatslacker commentedon Apr 12, 2016
We should probably just remove this section from the main style guide or rephrase it. Same with the React style guide. This whole attachment to "private" is what makes the rules seem confusing.
taion commentedon Apr 12, 2016
Either way would be fine – it's the inconsistency that's galling.
Though I'd note again that FB do in fact use leading underscores, real privacy or no 😛
[guide] [breaking] Disallow leading underscores - there’s no such thi…
22 remaining items
nicbou commentedon May 6, 2016
Yes, and I am asking "how?", because there clearly isn't a way to do so with ES6 classes.
ljharb commentedon May 6, 2016
This isn't the proper venue for it, but if you ping me in the gitter channel, I'll be happy to show you how it's easily possible for your example.
nicbou commentedon May 6, 2016
Sure thing! Let's talk about it Monday. The weekend is too short for arguments about code ;)
gaurav21r commentedon Aug 29, 2016
@ljharb Your points are very valid and I guess the Javascript Ecosystem has a history of "working around the language" read CoffeeScript, TypeScript, React & JSX etc.
But you must agree the leading (and trailing) underscore is pretty much prevalent in the Industry.
And there are some more heavyweights too apart from the above.
Your point about working with the language is well taken. I personally feel though that this style guide could be better off taking a solid consistent stand throughout.
Eg with https://github.com/airbnb/javascript#accessors--no-getters-setters It seems we are encouraging people to go "around" the language and use custom setters like
setPropertywhich is code convention based and not language based (getters & setters).I may be wrong but this seems to be the same issue as the leading underscore/
ljharb commentedon Aug 29, 2016
@gaurav21r I believe Polymer is from Google, so your three examples are really just two. Also, someone being a "heavyweight" is a poor reason to make any choice.
This style guide does take a solid and consistent stand: do not use ES5 getters/setters; and do not use underscores at all (trailing or leading), nor anything else that attempts to convey soft "privacy". The reasons are hopefully communicated well. If they can be improved, PRs are most welcome!
Just because a language provides functionality does not mean it is the best or most appropriate choice to achieve a goal, nor that using an alternative is "going around the language". You can do lots of things with
evalorwith, but that doesn't mean it's ever a good idea.[guide] [breaking] Disallow leading underscores - there’s no such thi…
[guide] [breaking] Disallow leading underscores - there’s no such thi…
MatthewCochrane commentedon Jan 5, 2021
I didn't really understand all this fuss about truly private variables until I connected it with the concept of Hyrum's Law.
This is intuitive to me and makes clear sense. With that in mind and the scale of Airbnb it makes sense why this rule exists in their style guide and how 'fake private' is really just plain old 'public'.
[guide] [breaking] Disallow leading underscores - there’s no such thi…
[guide] [breaking] Disallow leading underscores - there’s no such thi…
[guide] [breaking] Disallow leading underscores - there’s no such thi…
[guide] [breaking] Disallow leading underscores - there’s no such thi…
[guide] [breaking] Disallow leading underscores - there’s no such thi…
[guide] [breaking] Disallow leading underscores - there’s no such thi…
[guide] [breaking] Disallow leading underscores - there’s no such thi…