docs: update useParams hook return statement
#67384
Conversation
|
Allow CI Workflow Run
Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer |
| @@ -18,7 +18,7 @@ export default function ExampleClientComponent() { | |||
| // `params` -> { tag: 'shoes', item: 'nike-air-max-97' } | |||
| console.log(params) | |||
|
|
|||
| return <></> | |||
| return null | |||
There was a problem hiding this comment.
Since it is an example component, it seems like the fragment was used to abstract the rest code, not just returning null.
How about something like this?
| return null | |
| return <>{/* ...rest */}</> |
There was a problem hiding this comment.
My example was more about what happens when you don't return anything. I wanted to keep the functionality the same as for the previous docs.
In my real-life production code, we don't expect anything in the return statement anyway for this component, and the <></> react fragment is confusing for new developers.
But your change is good too!
Can we do it in the next pr?
Let me know what you think!
There was a problem hiding this comment.
| return null | |
| return '...' |
There was a problem hiding this comment.
Let's go with this! Will further use'...' throughout the examples instead of null or <></> 😄
There was a problem hiding this comment.
Let's go with return '...'!
https://github.com/vercel/next.js/pull/67384/files#r1664243618
Hi 👋🏻
The Change
I noticed that in one example of the
useParamshook, there is an old-fashioned return statement that returns a react fragment instead of null. This step was part of the workaround from the typescript environment from 2016, which is now obsolete.Recently, I researched why some people do it today and whether we should continue doing it in a react environment.
I created a document discussing it:
https://github.com/Kuboczoch/web-dev-best-practices/blob/master/react/conditional-rendering_return-react-fragment.md
tl;dr
Why?
It helps to provide the best practice to other developers who are just starting with web development and are mindlessly copy-pasting the code. In this case, people do not need to research workarounds for TypeScript from six years ago.