Skip to content

Commit eb4913b

Browse files
committed
update docusaurus
1 parent 10fd74d commit eb4913b

File tree

1 file changed

+16
-16
lines changed

1 file changed

+16
-16
lines changed

website/src/pages/index.mdx

Lines changed: 16 additions & 16 deletions
Original file line numberDiff line numberDiff line change
@@ -348,22 +348,6 @@ Template literal types are useful in various scenarios, such as:
348348
const customColor: Color = '#AD3128';
349349
```
350350

351-
### Return Types
352-
353-
<Rule
354-
prefix="Explicitly defining the return type of a function is encouraged, although not required"
355-
href="https://typescript-eslint.io/rules/explicit-function-return-type/"
356-
>{`"@typescript-eslint/explicit-function-return-type": "error"`}</Rule>
357-
358-
Consider benefits when explicitly typing the return value of a function:
359-
360-
- Return values makes it clear and easy to understand to any calling code what type is returned.
361-
- In the case where there is no return value, the calling code doesn't try to use the undefined value when it shouldn't.
362-
- Surface potential type errors faster in the future if there are code changes that change the return type of the function.
363-
- Easier to refactor, since it ensures that the return value is assigned to a variable of the correct type.
364-
- Similar to writing tests before implementation (TDD), defining function arguments and return type, gives you the opportunity to discuss the feature functionality and its interface ahead of implementation.
365-
- Although type inference is very convenient, adding return types can save TypeScript compiler a lot of work.
366-
367351
### Type any & unknown
368352

369353
`any` data type must not be used as it represents literally “any” value that TypeScript defaults to and skips type checking since it cannot infer the type. As such, `any` is dangerous, it can mask severe programming errors.
@@ -614,6 +598,22 @@ type StatusParams = StatusSuccessParams | StatusLoadingParams | StatusErrorParam
614598
export const parseStatus = (params: StatusParams) => {...
615599
```
616600
601+
### Function Return Types
602+
603+
<Rule
604+
prefix="Explicitly defining the return type of a function is encouraged, although not required"
605+
href="https://typescript-eslint.io/rules/explicit-function-return-type/"
606+
>{`"@typescript-eslint/explicit-function-return-type": "error"`}</Rule>
607+
608+
Consider benefits when explicitly typing the return value of a function:
609+
610+
- Return values makes it clear and easy to understand to any calling code what type is returned.
611+
- In the case where there is no return value, the calling code doesn't try to use the undefined value when it shouldn't.
612+
- Surface potential type errors faster in the future if there are code changes that change the return type of the function.
613+
- Easier to refactor, since it ensures that the return value is assigned to a variable of the correct type.
614+
- Similar to writing tests before implementation (TDD), defining function arguments and return type, gives you the opportunity to discuss the feature functionality and its interface ahead of implementation.
615+
- Although type inference is very convenient, adding return types can save TypeScript compiler a lot of work.
616+
617617
## Variables
618618
619619
### Const Assertion

0 commit comments

Comments
 (0)