Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[pull] master from facebook:master #1

Open
wants to merge 2,438 commits into
base: master
Choose a base branch
from
Open

Conversation

pull[bot]
Copy link

@pull pull bot commented Apr 23, 2021

See Commits and Changes for more details.


Created by pull[bot]

Can you help keep this open source service alive? 💖 Please sponsor : )

heyimalex and others added 30 commits December 30, 2019 13:53
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
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) => { /*...*/ }
```
Updates dependencies and removes babel plugins that are now covered by `@babel/preset-env`.

Co-authored-by: hdineen <[email protected]>
`Auto Fix is enabled by default. Use the single string form.` warning is shown in `.vscode/settings.json` due to changes in vscode-eslint. 
As autoFix is set to default, object format in `eslint.validate` is deprecated.
* Expands scope of openBrowser tab control

Adjust openChrome.applescript to allow manipulation of
other Chromium-based browsers (defaulting to Chrome).
Requires list of compatible browsers to try in openBrowser.js

* Fix typo

* Remove Safari
* setupTestFrameworkScriptFile is deprecated

__Note:_ `_setupTestFrameworkScriptFile_` _is deprecated in favor of_ `_setupFilesAfterEnv_`_.__

ref: https://jestjs.io/docs/en/configuration#setupfilesafterenv-array

* Update docusaurus/docs/running-tests.md

Co-Authored-By: Simen Bekkhus <[email protected]>

Co-authored-by: Simen Bekkhus <[email protected]>
Added the relevant topic linked directly, instead of saying it's just in the next section.
Adjusted the text so it sounds more like a recommendation rather than a requirement.
The topic linked is basically explainer to how you'd reference it using the global window object and ways to avoid linter errors. Thus I used 'reference' to give users a hint of what it the linked page would be for.
Rider is JetBrains .NET IDE, which supports the React plugin identically to other JetBrains IDEs such as Idea and WebStorm.
* Enable custom sockjs pathname for hot reloading server.

* Update docusaurus/docs/advanced-configuration.md

Co-Authored-By: Brody McKee <[email protected]>

* let WDS_SOCKET_PATH be undefined

* adding env variables for sockHost and sockPort options

Co-authored-by: Brody McKee <[email protected]>
iansu and others added 15 commits February 22, 2021 11:21
The variable is also used in dev.
* Update getProcessForPort.js

* Update getProcessForPort.js

Co-authored-by: Zhou Peng <[email protected]>
Co-authored-by: Dan Abramov <[email protected]>
Bumps [y18n](https://github.com/yargs/y18n) from 4.0.0 to 4.0.1.
- [Release notes](https://github.com/yargs/y18n/releases)
- [Changelog](https://github.com/yargs/y18n/blob/master/CHANGELOG.md)
- [Commits](https://github.com/yargs/y18n/commits)

Signed-off-by: dependabot[bot] <[email protected]>

Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
@pull pull bot added ⤵️ pull merge-conflict Resolve conflicts manually labels Apr 23, 2021
@facebook-github-bot facebook-github-bot deleted the branch tizmagik:master July 7, 2021 15:44
@facebook-github-bot facebook-github-bot deleted the master branch July 7, 2021 15:44
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment