Skip to content
GitLab
  1. 31 Jan, 2020 17 commits
  3. 30 Jan, 2020 8 commits
  5. 23 Jan, 2020 1 commit
  7. 22 Jan, 2020 1 commit
    • Retsam's avatar
      Remove React.FC from Typescript template (#8177) · dada0357
      Retsam authored 
      This removes `React.FC` from the base template for a Typescript project.

Long explanation for a small change: 

`React.FC` is unnecessary: it provides next to no benefits and has a few downsides.  (See below.)  I see a lot of beginners to TS+React using it, however, and I think that it's usage in this template is a contributing factor to that, as the prominence of this template makes it a de facto source of "best practice".  

### Downsides to React.FC/React.FunctionComponent

##### Provides an implicit definition of `children`

Defining a component with `React.FC` causes it to implicitly take `children` (of type `ReactNode`).  It means that all components accept children, even if they're not supposed to, allowing code like:

```ts
const App: React.FC = () => { /*... */ };
const Example = () => {
	<App><div>Unwanted children</div></App>
}
```

This isn't a run-time error, but it is a mistake and one that would be caught by Typescript if not for `React.FC`. 

##### Doesn't support generics.
I can define a generic component like:
```ts
type GenericComponentProps<T> = {
   prop: T
   callback: (t: T) => void
}
const GenericComponent = <T>(props: GenericComponentProps<T>) => {/*...*/}
```

But it's not possible when using `React.FC` - there's no way to preserve the unresolved generic `T` in the type returned by `React.FC`.

```ts
const GenericComponent: React.FC</* ??? */> = <T>(props: GenericComponentProps<T>) => {/*...*/}
```

##### Makes "component as namespace pattern" more awkward.
It's a somewhat popular pattern to use a component as a namespace for related components (usually children):

```jsx
<Select>
	<Select.Item />
</Select>
```

This is possible, but awkward, with `React.FC`:

```tsx
const  Select: React.FC<SelectProps> & { Item: React.FC<ItemProps> } = (props) => {/* ... */ }
Select.Item = (props) => { /*...*/ }
```

but "just works" without `React.FC`:

```tsx
const Select = (props: SelectProps) => {/* ... */}
Select.Item = (props) => { /*...*/ }
```

##### Doesn't work correctly with defaultProps

This is a fairly moot point as in both cases it's probably better to use ES6 default arguments, but...

```tsx
type  ComponentProps = { name: string; }

const  Component = ({ name }: ComponentProps) => (<div>
	{name.toUpperCase()} /* Safe since name is required */
</div>);
Component.defaultProps = { name: "John" };

const  Example = () => (<Component />) /* Safe to omit since name has a default value */
```
This compiles correctly.  Any approach with `React.FC` will be slightly wrong: either `React.FC<{name: string}>` will make the prop required by consumers, when it should be optional, or `React.FC<{name?: string}>` will cause `name.toUpperCase()` to be a type error.  There's no way to replicate the "internally required, externally optional" behavior which is desired.

##### It's as long, or longer than the alternative: (especially longer if you use `FunctionalComponent`):
Not a huge point, but it isn't even shorter to use `React.FC` 
```ts
const C1: React.FC<CProps> = (props) => { }
const C2 = (props: CProps) => {};
```

### Benefits of React.FC

##### Provides an explicit return type

The only benefit I really see to `React.FC` (unless you think that implicit `children` is a good thing) is that it specifies the return type, which catches mistakes like:

```ts
const Component = () => {
   return undefined; // components aren't allowed to return undefined, just `null`
}
```

In practice, I think this is fine, as it'll be caught as soon as you try to use it:

```ts
const Example = () => <Component />; // Error here, due to Component returning the wrong thing
```

But even with explicit type annotations, `React.FC` still isn't saving very much boilerplate:

```ts
const Component1 = (props: ComponentProps): ReactNode => { /*...*/ }
const Component2: FC<ComponentProps> = (props) => { /*...*/ }
```
      dada0357
  9. 21 Jan, 2020 1 commit
  11. 16 Jan, 2020 1 commit
  13. 12 Jan, 2020 2 commits
  15. 30 Dec, 2019 1 commit
    • Alex Guerra's avatar
      Replace favicon in templates (#8194) · c03bb366
      Alex Guerra authored 
      The old favicon was the same as the official react documentation, which is a minor annoyance during development when trying to find the tab you want. The new favicon is just the old with inverted colors.

Closes #7957
      c03bb366
  17. 20 Dec, 2019 1 commit
  19. 19 Dec, 2019 1 commit
  21. 18 Dec, 2019 1 commit
  23. 16 Dec, 2019 1 commit
    • Alex Guerra's avatar
      Minor refactors in create-react-app (#8178) · 30eaab4e
      Alex Guerra authored 
      - Remove templates version minimum stopgap.
- Replace indexOf with more idiomatic alternatives.
- Inline errorLogFilePatterns.
- Alphabetize validFiles.
- Simplify log file removal code.
- Move unconditional console.log() call outside of isSafe.
- Differentiate conflicting directories from files.
- Document yarn version special case.
- Inline printValidationResults.
- Standardize checkAppName output on failure.
- Add link for checkThatNpmCanReadCwd.

Functionally the code should be exactly the same.
      30eaab4e
  25. 15 Dec, 2019 2 commits
  27. 14 Dec, 2019 1 commit
    • Andreas Cederström's avatar
      Bump internal dependencies (#8176) · f26de73e
      Andreas Cederström authored 
      * Bump dependencies in react-dev-utils

* Bump dependencies in react-app-polyfill

* Bump dependencies in create-react-app

* Bump dependencies in react-error-overlay

* Bump dependencies in react-scripts

* Bump react
      f26de73e
  29. 13 Dec, 2019 1 commit