- Location - The location of the application. Usually just a URL, but the location can contain multiple pieces of information that can be used by an app
- pathname - The "file/directory" portion of the URL, like
invoices/123
- search - The stuff after
?
in a URL like/assignments?showGrades=1
. - query - A parsed version of search, usually an object but not a standard browser feature.
- hash - The
#
portion of the URL. This is not available to servers inrequest.url
so its client only. By default it means which part of the page the user should be scrolled to, but developers use it for various things. - state - Object associated with a location. Think of it like a hidden URL query. It's state you want to keep with a specific location, but you don't want it to be visible in the URL.
- pathname - The "file/directory" portion of the URL, like
React recently introduced an experimental profiler API. After discussing this API with several teams at Facebook, one common piece of feedback was that the performance information would be more useful if it could be associated with the events that caused the application to render (e.g. button click, XHR response). Tracing these events (or "interactions") would enable more powerful tooling to be built around the timing information, capable of answering questions like "What caused this really slow commit?" or "How long does it typically take for this interaction to update the DOM?".
With version 16.4.3, React added experimental support for this tracing by way of a new NPM package, scheduler. However the public API for this package is not yet finalized and will likely change with upcoming minor releases, so it should be used with caution.
This will log the currently active element as it changes. Really great for accessibility testing when you're trying to figure out what element has focus (so you can either prevent it from getting focus or make the fact that it has focus more visually obvious for example).
Note:
When this guide is more complete, the plan is to move it into Prepack documentation.
For now I put it out as a gist to gather initial feedback.
If you're building JavaScript apps, you might already be familiar with some tools that compile JavaScript code to equivalent JavaScript code:
- Babel lets you use newer JavaScript language features, and outputs equivalent code that targets older JavaScript engines.
// handy method to create a Higher Order Component out of a | |
// Render Prop Component (like a Context.Consumer). | |
// handles, statics, displayName, refs, and value forwarding | |
function createHOCFromRenderProp({prop, Consumer}) { | |
return Component => { | |
function Wrapper(props, ref) { | |
return ( | |
<Consumer> | |
{value => <Component {...{...props, [prop]: value, ref}} />} |
A collection of links to the excellent "Composing Software" series of medium stories by Eric Elliott.
How To Use React-Intl: internationalize your React app
This short tutorial assumes you know about ES6 syntax.
yarn add react-intl
or npm i --save react-intl
.
This file should contain every message for your app.
It has an object of (locale, messages) couples:
// connect() is a function that injects Redux-related props into your component. | |
// You can inject data and callbacks that change that data by dispatching actions. | |
function connect(mapStateToProps, mapDispatchToProps) { | |
// It lets us inject component as the last step so people can use it as a decorator. | |
// Generally you don't need to worry about it. | |
return function (WrappedComponent) { | |
// It returns a component | |
return class extends React.Component { | |
render() { | |
return ( |
All of the below properties or methods, when requested/called in JavaScript, will trigger the browser to synchronously calculate the style and layout*. This is also called reflow or layout thrashing, and is common performance bottleneck.
Generally, all APIs that synchronously provide layout metrics will trigger forced reflow / layout. Read on for additional cases and details.
elem.offsetLeft
,elem.offsetTop
,elem.offsetWidth
,elem.offsetHeight
,elem.offsetParent
While this gist has been shared and followed for years, I regret not giving more background. It was originally a gist for the engineering org I was in, not a "general suggestion" for any React app.
Typically I avoid folders altogether. Heck, I even avoid new files. If I can build an app with one 2000 line file I will. New files and folders are a pain.