Permalink
Comparing changes
Choose two branches to see what’s changed or to start a new pull request.
If you need to, you can also or
learn more about diff comparisons.
Open a pull request
Create a new pull request by comparing changes across two branches. If you need to, you can also .
Learn more about diff comparisons here.
...
31
contributors
Commits on Dec 5, 2019
Commits on Dec 6, 2019
-
-
Remove error for @typescript-eslint/no-namespace (#7803)
Declare namespaces are supported by babel now, and babel will throw with a nice error message for non-declare namespaces, so this rule is unnecessary. Closes #7651.
Commits on Dec 9, 2019
-
-
-
-
Fix typo in comment:
?.is right, not.?(#8124)This is just a comment fix. Actual optional chaining operator syntax is `?.`, not `.?`.
Commits on Dec 13, 2019
-
Add current version and bin location to --info output (#8168)
Make the --info subcommand outuput the current version information and the location of the file being run. Our issue template tells users to provide the output of --info, so having the current version is incredibly helpful, especially since it doesn't necessarily match the globally installed version that envinfo outputs. Knowing the location helps us determine whether the running bin is globally installed or in the local node_modules.
-
-
-
Commits on Dec 14, 2019
-
Bump internal dependencies (#8176)
* 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
Commits on Dec 15, 2019
-
Add package-runner note to readme (#8132)
* Add package-runner note to readme * Add link to `yarn create`
-
Commits on Dec 16, 2019
-
Minor refactors in create-react-app (#8178)
- 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.
Commits on Dec 18, 2019
Commits on Dec 19, 2019
Commits on Dec 20, 2019
Commits on Dec 30, 2019
-
Replace favicon in templates (#8194)
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
Commits on Jan 12, 2020
Commits on Jan 21, 2020
Commits on Jan 22, 2020
-
Remove React.FC from Typescript template (#8177)
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) => { /*...*/ } ```
Commits on Jan 30, 2020
-
Remove outdated babel plugins (#8353)
Updates dependencies and removes babel plugins that are now covered by `@babel/preset-env`. Co-authored-by: hdineen <hdineen@hubspot.com>
-
-
Update custom template docs with instructions for testing custom temp…
…late locally (#8092) Co-authored-by: Ian Schmitz <ianschmitz@gmail.com>
-
Update setting-up-your-editor.md (#8247)
`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.
-
Remove outdated docs regarding vscode eslint extension and type… (#8307)
Co-authored-by: Ian Schmitz <ianschmitz@gmail.com>
-
-
Commits on Jan 31, 2020
-
-
-
docs: Add troubleshooting documentation on ENOSPC (#8380)
Co-authored-by: Ian Schmitz <ianschmitz@gmail.com>
-
-
- babel-plugin-named-asset-import@0.3.6 - babel-preset-react-app@9.1.1 - cra-template-typescript@1.0.1 - cra-template@1.0.1 - create-react-app@3.3.1 - eslint-config-react-app@5.2.0 - react-app-polyfill@1.0.6 - react-dev-utils@10.1.0 - react-error-overlay@6.0.5 - react-scripts@3.3.1
There are no files selected for viewing
Large diffs are not rendered by default.
Large diffs are not rendered by default.