docs: update `useParams` hook return statement

[Kuboczoch]

Hi 👋🏻

The Change

I noticed that in one example of the useParams hook, 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

While returning a React.Fragment instead of null in a React component was a workaround for TypeScript limitations in 2016, this is no longer necessary. Returning null is more efficient, makes the code more readable, is officially supported, and aligns with current best practices.

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.

[ijjk]

Allow CI Workflow Run

• [ ] approve CI run for commit: 5b1ed13f920b2f0c9a2a56b2e76405e38e6d2c44

Note: this should only be enabled once the PR is ready to go and can only be enabled by a maintainer

[delbaoliveira]

Thank you for sharing @Kuboczoch, I wasn't aware that <></> was used as TS workaround for returning null. Like @devjiwonchoi mentioned, we use it to indicate that more that can be returned from the component, not to return null. We'll keep that in mind in the future.

[Kuboczoch]

Thank you for sharing @Kuboczoch, I wasn't aware that <></> was used as TS workaround for returning null. Like @devjiwonchoi mentioned, we use it to indicate that more that can be returned from the component, not to return null. We'll keep that in mind in the future.

Thanks, regarding the pr I will update it when I have a free time and request a review once more 👍