[Feature](Docs) Give names to anonymous arrow functions in docs examples
See original GitHub issueFor example, in api-routes
we have this example
export default (req, res) => {
res.statusCode = 200
res.setHeader('Content-Type', 'application/json')
res.end(JSON.stringify({ name: 'John Doe' }))
}
Exporting anonymous functions is arguably bad practice. If this agreed upon, I think any examples containing anonymous exports should be changed to use named functions
Issue Analytics
- State:
- Created 3 years ago
- Comments:8 (6 by maintainers)
Top Results From Across the Web
ES6 Features for Google Apps Script: Arrow Functions
Just like regular anonymous functions, there are two main parts to arrow functions: the parameters and the statements or expressions that make ...
Read more >Arrow function expressions - JavaScript - MDN Web Docs
Arrow functions are always unnamed. If the arrow function needs to call itself, use a named function expression instead. You can also assign...
Read more >Understanding Arrow Functions in JavaScript | DigitalOcean
Arrow functions are a new way to write anonymous function ... A function declaration is a named function written with the function keyword....
Read more >Arrow Functions in JavaScript - codeburst
However, the Arrow functions can be used for non-Anonymous, i.e. named functions: /* This code sample is from the MDN Docs of Arrow...
Read more >Arrow Functions: JavaScript ES6 Feature Series (Pt 2) - ITNEXT
As I mentioned briefly above, function expressions, since they're assigned to variables, can omit a name, and be what's known as an 'anonymous...
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
@lcswillems
this goes hand in hand with better refactoring support in editors
Personally, I consider default exports to be bad practice because of mentioned reasons and actively lint against them. In places where I have to use default exports, e.g. nextjs pages, I
// eslint-disable-next-line import/no-default-export
.Obviously the PR is going to be reviewed by one of the Next.js maintainers but I wanted to say that it looks good to me. Nice contribution @Jashnm !