Libraries that use render props include React Router, Downshift and Formik.
In this document, we’ll discuss why render props are useful, and how to write your own.
Use Render Props for Cross-Cutting Concerns
Components are the primary unit of code reuse in React, but it’s not always obvious how to share the state or behavior that one component encapsulates to other components that need that same state.
For example, the following component tracks the mouse position in a web app:
render(){ return( <divstyle={{height:'100vh'}}onMouseMove={this.handleMouseMove}> <h1>Move the mouse around!</h1> <p>The current mouse position is ({this.state.x}, {this.state.y})</p> </div> ); } }
As the cursor moves around the screen, the component displays its (x, y) coordinates in a
<p>
.
Now the question is: How can we reuse this behavior in another component? In other words, if another component needs to know about the cursor position, can we encapsulate that behavior so that we can easily share it with that component?
Since components are the basic unit of code reuse in React, let’s try refactoring the code a bit to use a
<Mouse>
component that encapsulates the behavior we need to reuse elsewhere.
// The <Mouse> component encapsulates the behavior we need... classMouseextendsReact.Component{ constructor(props){ super(props); this.handleMouseMove =this.handleMouseMove.bind(this); this.state ={x:0,y:0}; }
Now the
<Mouse>
component encapsulates all behavior associated with listening for
mousemove
events and storing the (x, y) position of the cursor, but it’s not yet truly reusable.
For example, let’s say we have a
<Cat>
component that renders the image of a cat chasing the mouse around the screen. We might use a
<Cat mouse={{ x, y }}>
prop to tell the component the coordinates of the mouse so it knows where to position the image on the screen.
As a first pass, you might try rendering the
<Cat>
inside
<Mouse>
’s
render
method
, like this:
{/* We could just swap out the <p> for a <Cat> here ... but then we would need to create a separate <MouseWithSomethingElse> component every time we need to use it, so <MouseWithCat> isn't really reusable yet. */} <Catmouse={this.state}/> </div> ); } }
This approach will work for our specific use case, but we haven’t achieved the objective of truly encapsulating the behavior in a reusable way. Now, every time we want the mouse position for a different use case, we have to create a new component (i.e. essentially another
<MouseWithCat>
) that renders something specifically for that use case.
Here’s where the render prop comes in: Instead of hard-coding a
<Cat>
inside a
<Mouse>
component, and effectively changing its rendered output, we can provide
<Mouse>
with a function prop that it uses to dynamically determine what to render–a render prop.
{/* Instead of providing a static representation of what <Mouse> renders, use the `render` prop to dynamically determine what to render. */} {this.props.render(this.state)} </div> ); } }
Now, instead of effectively cloning the
<Mouse>
component and hard-coding something else in its
render
method to solve for a specific use case, we provide a
render
prop that
<Mouse>
can use to dynamically determine what it renders.
More concretely,
a render prop is a function prop that a component uses to know what to render.
This technique makes the behavior that we need to share extremely portable. To get that behavior, render a
<Mouse>
with a
render
prop that tells it what to render with the current (x, y) of the cursor.
One interesting thing to note about render props is that you can implement most higher-order components (HOC) using a regular component with a render prop. For example, if you would prefer to have a
withMouse
HOC instead of a
<Mouse>
component, you could easily create one using a regular
<Mouse>
with a render prop:
// If you really want a HOC for some reason, you can easily // create one using a regular component with a render prop! functionwithMouse(Component){ returnclassextends React.Component { render(){ return( <Mouserender={mouse=>( <Component{...this.props}mouse={mouse}/> )}/> ); } } }
So using a render prop makes it possible to use either pattern.
Using Props Other Than
render
It’s important to remember that just because the pattern is called “render props” you don’t
have to use a prop named
render
to use this pattern
. In fact,
any
prop that is a function that a component uses to know what to render is technically a “render prop”.
Although the examples above use
render
, we could just as easily use the
children
prop!
<Mousechildren={mouse=>( <p>The mouse position is {mouse.x}, {mouse.y}</p> )}/>
And remember, the
children
prop doesn’t actually need to be named in the list of “attributes” in your JSX element. Instead, you can put it directly
inside
the element!
<Mouse> {mouse=>( <p>The mouse position is {mouse.x}, {mouse.y}</p> )} </Mouse>
You’ll see this technique used in the react-motion API.
Since this technique is a little unusual, you’ll probably want to explicitly state that
children
should be a function in your
propTypes
when designing an API like this.
Be careful when using Render Props with React.PureComponent
Using a render prop can negate the advantage that comes from using
React.PureComponent
if you create the function inside a
render
method. This is because the shallow prop comparison will always return
false
for new props, and each
render
in this case will generate a new value for the render prop.
For example, continuing with our
<Mouse>
component from above, if
Mouse
were to extend
React.PureComponent
instead of
React.Component
, our example would look like this:
classMouseextendsReact.PureComponent{ // Same implementation as above... }
classMouseTrackerextendsReact.Component{ render(){ return( <div> <h1>Move the mouse around!</h1>
{/* This is bad! The value of the `render` prop will be different on each render. */} <Mouserender={mouse=>( <Catmouse={mouse}/> )}/> </div> ); } }
In this example, each time
<MouseTracker>
renders, it generates a new function as the value of the
<Mouse render>
prop, thus negating the effect of
<Mouse>
extending
React.PureComponent
in the first place!
To get around this problem, you can sometimes define the prop as an instance method, like so:
classMouseTrackerextendsReact.Component{ // Defined as an instance method, `this.renderTheCat` always // refers to *same* function when we use it in render renderTheCat(mouse){ return<Catmouse={mouse}/>; }
In cases where you cannot define the prop statically (e.g. because you need to close over the component’s props and/or state)
<Mouse>
should extend
React.Component
instead.
Flow is a static type checker for your JavaScript code. It is developed at Facebook and is often used with React. It lets you annotate the variables, functions, and React components with a special type syntax, and catch mistakes early. You can read an introduction to Flow to learn its basics.
To use Flow, you need to:
Add Flow to your project as a dependency.
Ensure that Flow syntax is stripped from the compiled code.
Add type annotations and run Flow to check them.
We will explain these steps below in detail.
Adding Flow to a Project
First, navigate to your project directory in the terminal. You will need to run the following command:
If you use Yarn, run:
yarnadd --dev flow-bin
If you use npm, run:
npminstall --save-dev flow-bin
This command installs the latest version of Flow into your project.
Now, add
flow
to the
"scripts"
section of your
package.json
to be able to use this from the terminal:
This command will create a Flow configuration file that you will need to commit.
Stripping Flow Syntax from the Compiled Code
Flow extends the JavaScript language with a special syntax for type annotations. However, browsers aren’t aware of this syntax, so we need to make sure it doesn’t end up in the compiled JavaScript bundle that is sent to the browser.
The exact way to do this depends on the tools you use to compile JavaScript.
Create React App
If your project was set up using Create React App, congratulations! The Flow annotations are already being stripped by default so you don’t need to do anything else in this step.
Babel
Note:
These instructions are
not
for Create React App users. Even though Create React App uses Babel under the hood, it is already configured to understand Flow. Only follow this step if you
don’t
use Create React App.
If you manually configured Babel for your project, you will need to install a special preset for Flow.
If you use Yarn, run:
yarnadd --dev @babel/preset-flow
If you use npm, run:
npminstall --save-dev @babel/preset-flow
Then add the
flow
preset to your Babel configuration. For example, if you configure Babel through
.babelrc
file, it could look like this:
{ "presets":[ "@babel/preset-flow","react" ] }
This will let you use the Flow syntax in your code.
Note:
Flow does not require the
react
preset, but they are often used together. Flow itself understands JSX syntax out of the box.
Other Build Setups
If you don’t use either Create React App or Babel, you can use flow-remove-types to strip the type annotations.
Running Flow
If you followed the instructions above, you should be able to run Flow for the first time.
yarn flow
If you use npm, run:
npm run flow
You should see a message like:
No errors! ✨ Done in 0.17s.
Adding Flow Type Annotations
By default, Flow only checks the files that include this annotation:
// @flow
Typically it is placed at the top of a file. Try adding it to some files in your project and run
yarn flow
or
npm run flow
to see if Flow already found any issues.
There is also an option to force Flow to check
all
files regardless of the annotation. This can be too noisy for existing projects, but is reasonable for a new project if you want to fully type it with Flow.
Now you’re all set! We recommend to check out the following resources to learn more about Flow:
Flow Documentation: Type Annotations
Flow Documentation: Editors
Flow Documentation: React
Linting in Flow
TypeScript
TypeScript is a programming language developed by Microsoft. It is a typed superset of JavaScript, and includes its own compiler. Being a typed language, TypeScript can catch errors and bugs at build time, long before your app goes live. You can learn more about using TypeScript with React here.
To use TypeScript, you need to:
Add TypeScript as a dependency to your project
Configure the TypeScript compiler options
Use the right file extensions
Add definitions for libraries you use
Let’s go over these in detail.
Using TypeScript with Create React App
Create React App supports TypeScript out of the box.
To create a
new project
with TypeScript support, run:
npx create-react-app my-app --template typescript
You can also add it to an
existing Create React App project
, as documented here.
Note:
If you use Create React App, you can
skip the rest of this page
. It describes the manual setup which doesn’t apply to Create React App users.
Adding TypeScript to a Project
It all begins with running one command in your terminal.
If you use Yarn, run:
yarnadd --dev typescript
If you use npm, run:
npminstall --save-dev typescript
Congrats! You’ve installed the latest version of TypeScript into your project. Installing TypeScript gives us access to the
tsc
command. Before configuration, let’s add
tsc
to the “scripts” section in our
package.json
:
The compiler is of no help to us until we tell it what to do. In TypeScript, these rules are defined in a special file called
tsconfig.json
. To generate this file:
If you use Yarn, run:
yarn run tsc --init
If you use npm, run:
npx tsc --init
Looking at the now generated
tsconfig.json
, you can see that there are many options you can use to configure the compiler. For a detailed description of all the options, check here.
Of the many options, we’ll look at
rootDir
and
outDir
. In its true fashion, the compiler will take in typescript files and generate javascript files. However we don’t want to get confused with our source files and the generated output.
We’ll address this in two steps:
Firstly, let’s arrange our project structure like this. We’ll place all our source code in the
src
directory.
Great! Now when we run our build script the compiler will output the generated javascript to the
build
folder. The TypeScript React Starter provides a
tsconfig.json
with a good set of rules to get you started.
Generally, you don’t want to keep the generated javascript in your source control, so be sure to add the build folder to your
.gitignore
.
File extensions
In React, you most likely write your components in a
.js
file. In TypeScript we have 2 file extensions:
.ts
is the default file extension while
.tsx
is a special extension used for files which contain
JSX
.
Running TypeScript
If you followed the instructions above, you should be able to run TypeScript for the first time.
yarn build
If you use npm, run:
npm run build
If you see no output, it means that it completed successfully.
Type Definitions
To be able to show errors and hints from other packages, the compiler relies on declaration files. A declaration file provides all the type information about a library. This enables us to use javascript libraries like those on npm in our project.
There are two main ways to get declarations for a library:
Bundled
- The library bundles its own declaration file. This is great for us, since all we need to do is install the library, and we can use it right away. To check if a library has bundled types, look for an
index.d.ts
file in the project. Some libraries will have it specified in their
package.json
under the
typings
or
types
field.
DefinitelyTyped
- DefinitelyTyped is a huge repository of declarations for libraries that don’t bundle a declaration file. The declarations are crowd-sourced and managed by Microsoft and open source contributors. React for example doesn’t bundle its own declaration file. Instead we can get it from DefinitelyTyped. To do so enter this command in your terminal.
# yarn yarnadd --dev @types/react
# npm npm i --save-dev @types/react
Local Declarations
Sometimes the package that you want to use doesn’t bundle declarations nor is it available on DefinitelyTyped. In that case, we can have a local declaration file. To do this, create a
declarations.d.ts
file in the root of your source directory. A simple declaration could look like this:
You are now ready to code! We recommend to check out the following resources to learn more about TypeScript:
TypeScript Documentation: Everyday Types
TypeScript Documentation: Migrating from JavaScript
TypeScript Documentation: React and Webpack
ReScript
ReScript is a typed language that compiles to JavaScript. Some of its core features are guaranteed 100% type coverage, first-class JSX support and dedicated React bindings to allow integration in existing JS / TS React codebases.
You can find more infos on integrating ReScript in your existing JS / React codebase here.
Kotlin
Kotlin is a statically typed language developed by JetBrains. Its target platforms include the JVM, Android, LLVM, and JavaScript.
JetBrains develops and maintains several tools specifically for the React community: React bindings as well as Create React Kotlin App. The latter helps you start building React apps with Kotlin with no build configuration.
Other Languages
Note there are other statically typed languages that compile to JavaScript and are thus React compatible. For example, F#/Fable with elmish-react. Check out their respective sites for more information, and feel free to add more statically typed languages that work with React to this page!
StrictMode
is a tool for highlighting potential problems in an application. Like
Fragment
,
StrictMode
does not render any visible UI. It activates additional checks and warnings for its descendants.
Note:
Strict mode checks are run in development mode only;
they do not impact the production build
.
You can enable strict mode for any part of your application. For example:
In the above example, strict mode checks will
not
be run against the
Header
and
Footer
components. However,
ComponentOne
and
ComponentTwo
, as well as all of their descendants, will have the checks.
Additional functionality will be added with future releases of React.
Identifying unsafe lifecycles
As explained in this blog post, certain legacy lifecycle methods are unsafe for use in async React applications. However, if your application uses third party libraries, it can be difficult to ensure that these lifecycles aren’t being used. Fortunately, strict mode can help with this!
When strict mode is enabled, React compiles a list of all class components using the unsafe lifecycles, and logs a warning message with information about these components, like so:
Addressing the issues identified by strict mode
now
will make it easier for you to take advantage of concurrent rendering in future releases of React.
Warning about legacy string ref API usage
Previously, React provided two ways for managing refs: the legacy string ref API and the callback API. Although the string ref API was the more convenient of the two, it had several downsides and so our official recommendation was to use the callback form instead.
React 16.3 added a third option that offers the convenience of a string ref without any of the downsides:
Since object refs were largely added as a replacement for string refs, strict mode now warns about usage of string refs.
Note:
Callback refs will continue to be supported in addition to the new
createRef
API.
You don’t need to replace callback refs in your components. They are slightly more flexible, so they will remain as an advanced feature.
Learn more about the new
createRef
API here.
Warning about deprecated findDOMNode usage
React used to support
findDOMNode
to search the tree for a DOM node given a class instance. Normally you don’t need this because you can attach a ref directly to a DOM node.
findDOMNode
can also be used on class components but this was breaking abstraction levels by allowing a parent to demand that certain children were rendered. It creates a refactoring hazard where you can’t change the implementation details of a component because a parent might be reaching into its DOM node.
findDOMNode
only returns the first child, but with the use of Fragments, it is possible for a component to render multiple DOM nodes.
findDOMNode
is a one time read API. It only gave you an answer when you asked for it. If a child component renders a different node, there is no way to handle this change. Therefore
findDOMNode
only worked if components always return a single DOM node that never changes.
You can instead make this explicit by passing a ref to your custom component and pass that along to the DOM using ref forwarding.
You can also add a wrapper DOM node in your component and attach a ref directly to it.
In CSS, the
display: contents
attribute can be used if you don’t want the node to be part of the layout.
Detecting unexpected side effects
Conceptually, React does work in two phases:
The
render
phase determines what changes need to be made to e.g. the DOM. During this phase, React calls
render
and then compares the result to the previous render.
The
commit
phase is when React applies any changes. (In the case of React DOM, this is when React inserts, updates, and removes DOM nodes.) React also calls lifecycles like
componentDidMount
and
componentDidUpdate
during this phase.
The commit phase is usually very fast, but rendering can be slow. For this reason, the upcoming concurrent mode (which is not enabled by default yet) breaks the rendering work into pieces, pausing and resuming the work to avoid blocking the browser. This means that React may invoke render phase lifecycles more than once before committing, or it may invoke them without committing at all (because of an error or a higher priority interruption).
Render phase lifecycles include the following class component methods:
Because the above methods might be called more than once, it’s important that they do not contain side-effects. Ignoring this rule can lead to a variety of problems, including memory leaks and invalid application state. Unfortunately, it can be difficult to detect these problems as they can often be non-deterministic.
Strict mode can’t automatically detect side effects for you, but it can help you spot them by making them a little more deterministic. This is done by intentionally double-invoking the following functions:
Class component
constructor
,
render
, and
shouldComponentUpdate
methods
Class component static
getDerivedStateFromProps
method
Function component bodies
State updater functions (the first argument to
setState
)
Functions passed to
useState
,
useMemo
, or
useReducer
Note:
This only applies to development mode.
Lifecycles will not be double-invoked in production mode.
At first glance, this code might not seem problematic. But if
SharedApplicationState.recordEvent
is not idempotent, then instantiating this component multiple times could lead to invalid application state. This sort of subtle bug might not manifest during development, or it might do so inconsistently and so be overlooked.
By intentionally double-invoking methods like the component constructor, strict mode makes patterns like this easier to spot.
Note:
In React 17, React automatically modifies the console methods like
console.log()
to silence the logs in the second call to lifecycle functions. However, it may cause undesired behavior in certain cases where a workaround can be used.
Starting from React 18, React does not suppress any logs. However, if you have React DevTools installed, the logs from the second call will appear slightly dimmed. React DevTools also offers a setting (off by default) to suppress them completely.
Detecting legacy context API
The legacy context API is error-prone, and will be removed in a future major version. It still works for all 16.x releases but will show this warning message in strict mode:
Read the new context API documentation to help migrate to the new version.
Ensuring reusable state
In the future, we’d like to add a feature that allows React to add and remove sections of the UI while preserving state. For example, when a user tabs away from a screen and back, React should be able to immediately show the previous screen. To do this, React will support remounting trees using the same component state used before unmounting.
This feature will give React better performance out-of-the-box, but requires components to be resilient to effects being mounted and destroyed multiple times. Most effects will work without any changes, but some effects do not properly clean up subscriptions in the destroy callback, or implicitly assume they are only mounted or destroyed once.
To help surface these issues, React 18 introduces a new development-only check to Strict Mode. This new check will automatically unmount and remount every component, whenever a component mounts for the first time, restoring the previous state on the second mount.
To demonstrate the development behavior you’ll see in Strict Mode with this feature, consider what happens when React mounts a new component. Without this change, when a component mounts, React creates the effects:
* React mounts the component. * Layout effects are created. * Effects are created.
With Strict Mode starting in React 18, whenever a component mounts in development, React will simulate immediately unmounting and remounting the component:
* React mounts the component. * Layout effects are created. * Effect effects are created. * React simulates effects being destroyed on a mounted component. * Layout effects are destroyed. * Effects are destroyed. * React simulates effects being re-created on a mounted component. * Layout effects are created * Effect setup code runs
On the second mount, React will restore the state from the first mount. This feature simulates user behavior such as a user tabbing away from a screen and back, ensuring that code will properly handle state restoration.
When the component unmounts, effects are destroyed as normal:
* React unmounts the component. * Layout effects are destroyed. * Effect effects are destroyed.
Unmounting and remounting includes:
componentDidMount
componentWillUnmount
useEffect
useLayoutEffect
useInsertionEffect
Note:
This only applies to development mode,
production behavior is unchanged
.
We provide a codemod script to automate the conversion.
As your app grows, you can catch a lot of bugs with typechecking. For some applications, you can use JavaScript extensions like Flow or TypeScript to typecheck your whole application. But even if you don’t use those, React has some built-in typechecking abilities. To run typechecking on the props for a component, you can assign the special
propTypes
property:
In this example, we are using a class component, but the same functionality could also be applied to function components, or components created by
React.memo
or
React.forwardRef
.
PropTypes
exports a range of validators that can be used to make sure the data you receive is valid. In this example, we’re using
PropTypes.string
. When an invalid value is provided for a prop, a warning will be shown in the JavaScript console. For performance reasons,
propTypes
is only checked in development mode.
PropTypes
Here is an example documenting the different validators provided:
import PropTypes from'prop-types';
MyComponent.propTypes ={ // You can declare that a prop is a specific JS type. By default, these // are all optional. optionalArray: PropTypes.array, optionalBool: PropTypes.bool, optionalFunc: PropTypes.func, optionalNumber: PropTypes.number, optionalObject: PropTypes.object, optionalString: PropTypes.string, optionalSymbol: PropTypes.symbol,
// Anything that can be rendered: numbers, strings, elements or an array // (or fragment) containing these types. optionalNode: PropTypes.node,
// A React element. optionalElement: PropTypes.element,
// A React element type (ie. MyComponent). optionalElementType: PropTypes.elementType,
// You can also declare that a prop is an instance of a class. This uses // JS's instanceof operator. optionalMessage: PropTypes.instanceOf(Message),
// You can ensure that your prop is limited to specific values by treating // it as an enum. optionalEnum: PropTypes.oneOf(['News','Photos']),
// An object that could be one of many types optionalUnion: PropTypes.oneOfType([ PropTypes.string, PropTypes.number, PropTypes.instanceOf(Message) ]),
// An array of a certain type optionalArrayOf: PropTypes.arrayOf(PropTypes.number),
// An object with property values of a certain type optionalObjectOf: PropTypes.objectOf(PropTypes.number),
// An object taking on a particular shape optionalObjectWithShape: PropTypes.shape({ color: PropTypes.string, fontSize: PropTypes.number }),
// An object with warnings on extra properties optionalObjectWithStrictShape: PropTypes.exact({ name: PropTypes.string, quantity: PropTypes.number }),
// You can chain any of the above with `isRequired` to make sure a warning // is shown if the prop isn't provided. requiredFunc: PropTypes.func.isRequired,
// A required value of any data type requiredAny: PropTypes.any.isRequired,
// You can also specify a custom validator. It should return an Error // object if the validation fails. Don't `console.warn` or throw, as this // won't work inside `oneOfType`. customProp:function(props, propName, componentName){ if(!/matchme/.test(props[propName])){ returnnewError( 'Invalid prop `'+ propName +'` supplied to'+ ' `'+ componentName +'`. Validation failed.' ); } },
// You can also supply a custom validator to `arrayOf` and `objectOf`. // It should return an Error object if the validation fails. The validator // will be called for each key in the array or object. The first two // arguments of the validator are the array or object itself, and the // current item's key. customArrayProp: PropTypes.arrayOf(function(propValue, key, componentName, location, propFullName){ if(!/matchme/.test(propValue[key])){ returnnewError( 'Invalid prop `'+ propFullName +'` supplied to'+ ' `'+ componentName +'`. Validation failed.' ); } }) };
Requiring Single Child
With
PropTypes.element
you can specify that only a single child can be passed to a component as children.
import PropTypes from'prop-types';
classMyComponentextendsReact.Component{ render(){ // This must be exactly one element or it will warn. const children =this.props.children; return( <div> {children} </div> ); } }
Since ES2022 you can also declare
defaultProps
as static property within a React component class. For more information, see the class public static fields. This modern syntax will require a compilation step to work within older browsers.
The
defaultProps
will be used to ensure that
this.props.name
will have a value if it was not specified by the parent component. The
propTypes
typechecking happens after
defaultProps
are resolved, so typechecking will also apply to the
defaultProps
.
Function Components
If you are using function components in your regular development, you may want to make some small changes to allow PropTypes to be properly applied.
Let’s say you have a component like this:
exportdefaultfunctionHelloWorldComponent({ name }){ return( <div>Hello, {name}</div> ) }
To add PropTypes, you may want to declare the component in a separate function before exporting, like this:
functionHelloWorldComponent({ name }){ return( <div>Hello, {name}</div> ) }
exportdefault HelloWorldComponent
Then, you can add PropTypes directly to the
HelloWorldComponent
:
import PropTypes from'prop-types'
functionHelloWorldComponent({ name }){ return( <div>Hello, {name}</div> ) }
Since an uncontrolled component keeps the source of truth in the DOM, it is sometimes easier to integrate React and non-React code when using uncontrolled components. It can also be slightly less code if you want to be quick and dirty. Otherwise, you should usually use controlled components.
If it’s still not clear which type of component you should use for a particular situation, you might find this article on controlled versus uncontrolled inputs to be helpful.
Default Values
In the React rendering lifecycle, the
value
attribute on form elements will override the value in the DOM. With an uncontrolled component, you often want React to specify the initial value, but leave subsequent updates uncontrolled. To handle this case, you can specify a
defaultValue
attribute instead of
value
. Changing the value of
defaultValue
attribute after a component has mounted will not cause any update of the value in the DOM.
Likewise,
<input type="checkbox">
and
<input type="radio">
support
defaultChecked
, and
<select>
and
<textarea>
supports
defaultValue
.
The file input Tag
In HTML, an
<input type="file">
lets the user choose one or more files from their device storage to be uploaded to a server or manipulated by JavaScript via the File API.
<inputtype="file"/>
In React, an
<input type="file" />
is always an uncontrolled component because its value can only be set by a user, and not programmatically.
You should use the File API to interact with the files. The following example shows how to create a ref to the DOM node to access file(s) in a submit handler:
Most people who use React don’t use Web Components, but you may want to, especially if you are using third-party UI components that are written using Web Components.
Web Components often expose an imperative API. For instance, a
video
Web Component might expose
play()
and
pause()
functions. To access the imperative APIs of a Web Component, you will need to use a ref to interact with the DOM node directly. If you are using third-party Web Components, the best solution is to write a React component that behaves as a wrapper for your Web Component.
Events emitted by a Web Component may not properly propagate through a React render tree.
You will need to manually attach event handlers to handle these events within your React components.
One common confusion is that Web Components use “class” instead of “className”.
This code
will not
work if you transform classes with Babel. See this issue for the discussion.
Include the custom-elements-es5-adapter before you load your web components to fix this issue.