Docs: clarify cases where traditional functions are preferred#3221
Docs: clarify cases where traditional functions are preferred#3221Manvendra0023 wants to merge 4 commits intoairbnb:masterfrom
Conversation
ljharb
left a comment
There was a problem hiding this comment.
Arrow functions should only be used for inline callbacks. Everything else should use normal functions.
|
Thanks for the clarification — that makes sense. I agree that this guide should not encourage relying on hoisting, and that arrow functions should generally be preferred except for inline callbacks. My intent here wasn’t to recommend hoisting as a practice, but to document why traditional functions still exist and what technical differences remain, for readers who may encounter them in real codebases. I’m happy to remove or reword the hoisting mention to avoid implying it’s an acceptable pattern under this guide. Please let me know if you’d prefer the section to focus only on cases like named functions for debugging / stack traces, or if you’d rather drop the section entirely. |
|
I think that instead of "here's when you shouldn't use arrow functions", i think more useful guidance is "here are the only places you should use arrow functions". |
|
That makes sense — I agree that framing this in terms of “where arrow functions should be used” is clearer and more in line with the guide’s intent. I’ll update the section to focus on a short, explicit list of recommended arrow function use cases (e.g. inline callbacks), and remove or de-emphasise the “when not to use” framing. I’ll push an update shortly — thanks for the guidance. |
Co-authored-by: Jordan Harband <ljharb@gmail.com>
|
Thanks for the suggestion! Applied 👍 |
This PR adds a small clarification to the Arrow Functions section describing cases where traditional functions are still preferred, such as function hoisting, dynamic
thisbinding, and use of theargumentsobject.The goal is to improve clarity without changing the existing recommendation.