When a JavaScript event is triggered, it sends out a signal that will propagate (i.e. travel/broadcast) bidirectionally throughout parts of the 

 that are direct ancestors of the element that triggered the event, which allows you as the developer to respond to the event at different points in the DOM. This propagation process is composed of three separate phases known as the Capturing, Target, and Bubbling phases:

Capturing - The event signal begins its travels at the top-most, global 

 object, then travels down the DOM to the...

Target - the element that triggered the event, then...

, taking the same path through the target element’s ancestors* that it took on the way down

* Ancestors include relationships like parent, grandparent, great-grandparent, etc. Events will not travel through elements that are siblings of the direct ancestral lineage of the target.

For the sake of illustration, let's assume we have a simplified HTML document that looks like this:

 and add an event listener to it that fires upon receiving notification of a user click inside that 

, then the signal propagation flow would look like this:

Diagram of an event propagating through the capturing, target, and bubbling phases

Did you notice that the <div> with the "sibling-of-parent" id wasn't shown (i.e. propagated) in the diagram above, even though that element is in-between the Window and the target? 

Also, unlike the image of the water drop and waves at the top of this blog post, note that the event signal travels somewhat counterintuitively from the outside in to where the event occurred, and then back out again.

The majority of events will propagate through all three phases, but there are a small minority of events (e.g. focus, blur) that only propagate through the two non-bubbling phases (note: the target phase always occurs). When you use 

, the default behavior is for the listener to only listen for events propagating during bubbling, but if you want to instead tell the listener to only listen during the capturing phase then there is an optional third argument you can pass to 

 where you can specify that you only want to listen during capturing. You can implement this behavior either by passing the boolean value 

 in as the third argument (the default is 

), or you could instead pass an object that includes a boolean property named 

 (there are also some additional configuration options you can pass in when you use an object: 

 methods of handling events, often referred to as Traditional/DOM Property Event Handlers (

), and you are not able to configure these older methods to use the capturing phase.

Most of the time you’ll be listening for and handling events during the bubbling phase or target phase. The event listener and the event target are often the same element, but you can also take advantage of bubbling and put listeners higher up in the DOM than the target, and this allows for a helpful strategy of handling events known as Event Delegation.

Before I get into Event Delegation I want to make sure that you're familiar with the following concepts:

Event Object - A JavaScript object that contains information about an event that has occurred. It contains a lot of different information about the event (including the properties below). This object is automatically passed in as the first argument of the function that handles an event (the parameter is often written as "event", "evt" or "e") so that you can read from it to determine what action, if any, the program should take.

This property of the Event Object tells you the element that triggered a particular event.

event.currentTarget - This property of the Event Object tells you what element has an event listener attached.

, the Event Object also has a cool property called 

, which is an array that shows each element that an event has propagated through. Next time you're writing an event handler I'd recommend logging this property so you can see how the propagation is working.

 are often the same element, but when you have an event listener higher up in the DOM that's listening and handling an event that was triggered on a nested element lower in the DOM, then you're using the Event Delegation pattern. For instance, in our example HTML document, we could attach a 'click' event listener to the 

 element and handle the event when the user clicks on a nested element like the 

Diagram of event.target in relation to event.currentTarget

 because it has the event listener attached to it. Once the target 

 is clicked the event signal bubbles up the DOM to trigger the event handler function associated with the 

What Event Delegation allows you to do is handle events efficiently from an element that is higher up in the DOM instead of attaching an event listener to each lower-level element that may potentially trigger an event that you'd like to handle. This helps save program memory and also saves you the need of writing code that adds an event listener to elements that are dynamically created after the initial page load.

To see an example of how Event Delegation looks with some code, here's a new, simplified HTML document containing a todo list:

So far we have one todo on the list ("Learn about event delegation") that we can assume has been saved to a database. Each rendered todo will consist of an a 

 attribute that represents the unique sting identification number of the todo that's saved to the database. Nested inside that 

 to edit the todo text, and another to delete the todo (I've nested these buttons inside of a 

 just to make it easier to style the list items with Flexbox). If the user selects the Edit button, the span will change to an input with the todo text and the Edit and Delete buttons will change to Cancel (as in cancel the edit) and Save, respectively. All four different types of buttons will have a class that identifies the buttons.

A somewhat naive solution to handling the button clicks would be to add one event listener for each button of each todo. The better way to handle it would be to rely on event delegation and just add one event listener to a common ancestral element like the 

, and then in the handler function use the 

 and some simple logic to determine what button was clicked and which todo ID it corresponds to so we know which ID to target in our database:

 syntax yet, it's just a more streamlined way to handle more lengthy if/then logic) with four separate cases that handle each of the buttons that the user might select. Since we're relying on event delegation and we don't have an event listener attached to each button, we just have to be sure we have some logic like this in place in order to determine which button was selected (the default case would be for if the user selects somewhere within the list that isn't a button, in which case we do nothing but log a message to the console). So there is a bit of tradeoff in that we typically have to add a bit more logic when we use delegation, but at least we can keep our code clean and un-littered from countless unnecessary event listeners!

How events travel through the Document Object Model

unsplash

JavaScript Event Propagation

There are many different approaches you can take to writing CSS for your React Components. One of the more commonly used approaches is to use a CSS-in-JS library, and one of the more popular CSS-in-JS libraries is Styled Components (Note: throughout this post I often refer to Styled Components as “SC”). Some of the benefits of include:

You can scope your CSS directly to the elements that use it and not have to worry so much about unexpected style cascades or specificity rules (although keep in mind that 

 will still cascade to descendent components of your SCs, so the styles aren’t strictly scoped to just the element you’re applying your SC styles to, but this inheritable behavoir is often desirable).

 to allow you to harness the power of JavaScript to dynamically apply styles based on state and props (you’ll see plenty of examples of this throughout this post). 

It allows you to have your CSS colocated in the same part of your codebase as the code that uses it, which can make it much easier to maintain your CSS and make your code more reusable. It can also help with performance since you don’t have to uncessarily load a bunch of styles that your page doesn’t use.

The way that you use SCs aligns well with React’s component and composition-based model, and just like with React Components you can name your SCs anything you want, which can make your components more readable since you don’t always have to reference classes, ids and other element attributes to try and figure out an element is.

The way you write your style rules is, for the most part, the same as normal CSS, which helps with consistency and makes it easier to transition CSS rules to SC.

As cool as the Styled Components library is, when you first start learning it after only writing vanilla CSS it can be slightly awkward because you have to adjust your mental model from targeting everything in a pure CSS file with selectors like classes, to writing your styles as JavaScript and implementing the style as an actual component that's rendered directly inside of a React component. As you continue to read this post and learn SCs you may start noticing how some things look unusual, but just keep in mind that most of that unusual looking stuff is just plain JavaScript and you'll get used to it pretty quickly and start to see how powerful it can be. 

Now that you're ready to start using it, here’s the basic syntax for creating a Styled Component:

Here’s an actual example of a real SC definition and its implementation inside a React component:

 SC definition is up above the part of the React Component that actually renders the component (in this case, the 

 function). This is a common pattern and additionally 

it’s recommended that you never put your SCs inside of your React component render function

 As you create more and more SCs inside of a given file it may start to seem like it's adding more noise and complexity to the file, but you'll get used to it before long and you can easily collapse the rules in your code editor to compress things a bit. If it's really bothering you, you can even define your SCs in a separate file to clean things up a bit (see the post by Sara Vieira that’s linked at the end of this post for an example).

One of the more helpful and utilized features of Styled Components is that you can adapt and apply styles based on props that are passed to the SC. The props can come from anywhere in your app, but ultimately they must end up on the actual implementation of the Styled Component element (where the SC is used inside of the React component). The props passed to the SC implementation are automatically passed to the SC definition, and since the definition uses tagged template literals you can use JavaScript interpolation inside of the 

 to dynamically determine how your styles are applied.

The props that get passed to a Styled Component are different than the props that get passed to an actual React component, although any props that are passed to a React component can be used as the value of a prop that gets passed to a SC. I know this might be confusing to read right now but it’ll make sense as you see more examples below. I’d also recommend that once you start using SC that you try logging and comparing the props that you pass to a React component to the props that you pass to a SC within that React component.

Here is an example of one way you can adapt based on props:

To pass props to the Styled Component definition above it’s the same type of syntax as normal React props:

Styled Components is typically smart enough to filter out non-standard HTML attributes (e.g. in the examples above 

 aren’t actual DOM attributes) so that they don’t end up getting rendered to the element in the DOM.

 definition above, I have the full property/value declaration (

) inside of the template literal back ticks, but you can also use patterns like the one below where just the values are being interpolated but the properties (

Depending on how you’re using interpolations to adapt based on props, you may need to enclose the CSS property values in quotes. For instance, in the 

 example if I didn’t enclose the words 

 in quotes, I would get an error because the program would be looking for variables of those names but they don’t exist. Same thing with the number units for the 

 property; if those weren’t in quotes I would get an error because variable names can’t start with a number.

As you may’ve noticed, you’ll often be using short-circuiting 

, and ternary statements to concisely control the logic for your interpolations. If the code within an interpolation evaluates to 

, or an empty string then the interpolation will be ignored by SC, while any other styles below the ignored rule won’t be affected. By using the 

 operator you can effectively set a default value. In this example, if 

 is passed to the SC it will use whatever that color is, otherwise it will fallback to salmon (for the sake of brevity just assume that all rules are within a Styled Component like 

 operator you can short circuit so that if the initial expression is false, the corresponding value won’t be applied. In this example if the 

 props exists it will use that color, otherwise it will do nothing with the color:

When writing interpolations you can destructure any props from the prop object to make things even more concise. For instance, if we refactor the example above to use destructuring we’d end up with this adorable little CSS declaration:

Most of the interpolations that you write will probably be inline and concise as possible, but if you have more complex computational logic where you need or just prefer to write some code over multiple lines, or if you just want to locate the computational logic in a place other than inside a tempalte literal where the SC is defined, you can put the logic inside of a separate function and return the result of the function to a variable, and then you only use the variable in the interpolation. For instance, imagine that the following function expression is located up above the SC definition or maybe even exported from a completely different file:

Since it’s always a good idea to keep your code reusable and DRY, you can inherit style rules from previously defined SCs and extend or overwrite those properties as needed. For instance, if we wanted to use the same properties as the 

 element from above but just give it a different background color and add a border, you could do this:

Another API that allows you to reuse styles is the 

 prop, which allows you to easily change what type of element or Styled Component gets rendered, while keeping the styles from the original SC/element.

Pseudo Classes, Pseudo Elements, Combinators, and Nesting

Styled Components allows you to write the same pseudo classes, pseudo elements, and 

 you're used to, and you can also write nested rules:

The weird thing you may notice about these examples is the use of the ampersand (&), which Styled Components uses as a placeholder for the parent style (if you’ve ever used a CSS pre-compiler like Sass, it’s similar to how ampersands are used there), so when the Styled Component gets converted into plain CSS it will replace any instances of 

 with the the outer Styled Component element it’s within. You can also have selectors without the ampersand preceeding it, and in this scenario Styled Components will target children of the outer Styled Component that have the corresponding selector (although I've found that for most common use-cases you'll probably be using the ampersand).

Here are some examples of pseudo classes and pseudo elements:

Here are some examples of nesting and CSS combinators.

You can even do some more advanced stuff like 

Just like with vanilla CSS, spacing is important with Styled Components. For instance, 

 (no space between). The former will select any elements that are children of the & component (whatever that component/element may be) while the latter will only select instances of the & component that have the 

Styled Components provides a helper function called 

 that you can use to define global CSS rules. Keep in mind that you can also still define global rules with vanilla CSS, so usually you only  need to use 

 if you want global styles that use interpolation to adapt rules based on props.

Not much to see here but I recommend reading 

 by Corina Udrescu to see a cool way you can use SC and interpolations to manage your breakpoints.

 function helper that you can use for your animations:

 values above, when you have CSS properties that take multiple types of values (e.g. typically shorthand properties like 

, etc.), you can mix interpolated values with static values on the same rule.

When you’re working on a project that uses both vanilla CSS and Styled Components you may unexpectedly find that a rule in your vanilla CSS mistakenly has more specificity than your SC, and in this scenario if you’re not able to decrease the specificity of the vanilla CSS rule (maybe because there are elements elsewhere that depend on that rule) you can try adding ampersands to your SC rule to give it more priority:

SC will then generate a CSS rule that’s equivalent to:

The rule above results in a specificity of 20 since each class attribute has a total specificity weight of 10 (For more info on specificity see 

 by Vitaly Friedman). If you needed it to be more than 20 you could add additional ampersands and possibly other CSS selectors that would increase the specificity to the desired amount. As with vanilla CSS, you should try to avoid using the 

Typically when you’re writing SCs you’ll be applying your CSS to a regular ol’ HTML element, whether it’s the element itself (e.g. 

) or another element that already has SCs applied to it that you are inheriting from (e.g. 

), but you can also apply SCs to other React components that you’ve created or that you’re that you’re importing from a third-party library. To do so you just need to pass that element the 

 attribute so that SC knows that this is an element that it can apply it’s magic to. For instance:

If you try to inspect SC elements in Dev Tools you may notice that the elements have a cryptic, randomly generated 

, which obviously isn’t very helpful when you’re trying to figure out what Styled Component in your codebase it corresponds to. If you used Create React App to setup your app you can easily get SC to generate more descriptive names that include the file name and SC name (e.g. 

import styled from 'styled-components/macro'

. If you’re not using Create React App you can still get these descriptive names by using 

, but I haven’t strayed from the CRA path yet so I can’t speak on the plugin at this point.

With the topics we’ve been over in this post you should have plenty of weapons to wield in the fight for fabulosity against the army of the Unstyled (I’m sorry, I don’t know how to close out blog posts), although there are many other tactics that Styled Components can arm you with so I recommend going through the docs, including the Advanced section (I primarily just discussed topics from the Basics section, but not everything). I also recommend these blog posts if you’re feeling particularly peckish for more:

This blog post by Max Stoiber, one of the creators of Styled Components, discusses some of the motivation behind creating Styled-Components (it also has some links at the end to other good resources you may want to check out): 

https://www.smashingmagazine.com/2017/01/styled-components-enforcing-best-practices-component-based-systems/

This blog post by Chidume Nnamdi talks about the types of things that Styled Component is doing “under the hood” with tagged template literals to turn that weird SC syntax into regular CSS: 

https://blog.logrocket.com/build-your-own-styled-components-library/

This blog post by Josh Comeau goes over some slighly more advanced Best Practices for composing Styled Components (as well as a few other things that I've discussed): 

https://www.joshwcomeau.com/css/styled-components/

This blog post by Sara Vieira discusses how you can separate your Styled Component definitions from the components they're being used in: 

https://blog.cloudboost.io/separate-your-code-with-styled-components-ec4fd1ee3ef8

Learn Enough Styled Components to be Dangerously Fabulous

In the first post in this pair on React state I gave a general overview of state and discussed some of the key differences when working with state in functional components and class components. In this post, I’m going to be focusing more on some of the common code patterns that you can use when setting state across different shapes of data, including basic primitives, arrays, objects, and arrays of objects. This post will be pretty example-heavy, so in an effort to try and narrow our focus, here are some things to keep in mind about the code examples I’ll be using:

I’ll exclusively be using functional components with the 

 hook but many of the patterns are quite similar when you’re using class components so it generally isn't too difficult to translate.

Whenever I’m working with state held in objects and arrays I’ll be making immutable updates to the state by making copies of the state before making the updates. I’ll be using the ES6 spread operator to create the copies but in codebases out in the wild I'm sure it’s not uncommon to see copies being made with one of the following, older methods instead:

I'll be focusing on the different shapes of state data and the code that's responsible for setting the state but I’ll be omitting some of the other component code that would ordinarily be necessary to make things fully functional. There will be some code inside functions where you can assume the functions are being called and passed the parameters shown, and there are others where you can assume that you're operating on values that are being held in state or being passed in as props. It's all really interchangeable and just depends on how you structure your components and if you do inline functions or declare the functions on the component.

As always in programming, there are many different ways to accomplish the same things that I'll be showing you, particularly when working with state in objects and arrays. The examples I'll be using will mostly use more modern syntax and more concise code patterns.

With that out of the way, let's start out working with basic primitive values.

There are a number of different primitive value types in JavaScript, but for this article, we’ll just be focusing on strings, numbers, and booleans since these are the primary primitive types used. Primitive values are typically easiest to work with because they’re naturally immutable, which means that you can’t change a primitive value once it’s been assigned to a variable (although you can typically can reassign a variable to a new value). For our examples, let’s assume we’ve initialized the following string, number, and boolean type state variables:

 state variable is defined as an empty string because we’re using that state value as the input field’s value (what React calls a Controlled Component) so it needs to be a string in the browser, however, you’ll often need to convert input numbers from strings to numbers, particularly if you want to be able to use the number in calculations or when saving the number to a database. Common exceptions to this are phone numbers and unique IDs, which you’ll typically want as strings.

At the end of the day, whenever you want to set state, you just need to call the corresponding state-setting function with the value you want to set the state to, so for our basic primitives it's as easy as doing something like this:

If you have some additional logic that you need to perform before setting the new state value you might prefer to make your state-setting call inside of a separate function, but in many situations, like when you’re just setting state directly from user input without any client-side validation, it might be perfectly fine to just set the state from inline-functions defined directly on the element that is firing the related event. For instance:

If you wanted to handle all the logic and setting of these pieces of state from separate functions then you could do this for the event handlers instead:

In JavaScript any time you have a function that is handling an event, whether it’s an inline function or a reference to a function that exists elsewhere, the function will automatically be passed an event object that contains all the information about the type of event and where it occurred. In the inline functions above, you can see I’m referencing the event object as 

, but even in this second set of examples where we’re just referencing the functions defined elsewhere, we’re not explicitly passing the functions anything but those functions will still automatically be passed the event object. If you need to pass the function a piece of data (e.g. an ID so you know what to target and update) then you’ll probably want to use an arrow function or a pre-ES6 anonymous function:

In situations where you don't need the event object you can omit it. For instance, if you just wanted to pass in the examples above you would just delete 

While you ultimately just need to pass your state-setting function the value that you want to update a state variable to, note that you can also put JavaScript 

inside of your state-setting functions so that you can handle logic and calculate the new state directly inside of that function, which helps keep your code self-contained and concise. Here are some examples:

Note that the examples above use a callback function, often referred to as the “updater function”, which is a function the React API gives you access to inside of the state-setting function. The argument React passes to this updater function is the previous state value for the corresponding state variable so that you can use that value to ensure that your state is getting updated correctly when the new state is calculated based on the prior state. Instead of 

 you could technically name the variables anything you want and that variable will represent the previous state value before the current state-setting call updates it. You can use the updater function anywhere you’re setting state, and you’re not required to use it when using inline state-setting functions; it’s just a best practice for components like counters and togglers where you need to rely on the state being accurate before making updates. Without the updater function, you could write something like the examples below and it will often still work just fine, but due to the asynchronous nature of how React batches state-setting calls, 

you’re susceptible to getting bugs that cause inaccurate state values when the new state value is dependent on the prior state value being accurate.

 refer directly to the variables that you defined in the 

 calls as opposed to arguments passed in by React that reflect the guaranteed updated state.

If you have more logic and calculation that needs to occur before you set state you can also add curly brackets and break the inline function onto multiple lines like below, but you’ll probably want to be cautious when doing this because it can muddy up your JSX code quickly, making your code difficult to read and less reusable:

Back before we had React Hooks, each class component had one  

 object that would hold all the necessary state properties for that component and its related components. With React Hooks 

it’s generally recommended that you separate each state property out into its own dedicated variabl

e, but if you want to you can still store multiple state properties in one object in a similar fashion to class components. For example, let’s make a User component that stores a 

Update Existing Primitive Object Value / Add New Primitive Value

Unlike when working with state in class components, when you’re updating a state object in functional components you need to manually merge updates. In addition to preserving immutability, this is why I use the spread operator in the object above; it copies over all of the existing properties of the state object and adds/overrides the additional properties that are passed to the function. When you’re setting state in class components you only need to specify the properties that are being updated.

Here’s a more reusable function that is similar to the functions above, but it allows you to dynamically make updates based on values passed into the function:

Add something to an array nested one-level down in object

You can also do something similar to the pattern above with nested objects.

When working with arrays outside of React most JavaScript developers are comfortable using built-in array methods such as 

, but the problem with using methods like these in React is that they mutate (i.e. change) the original array. so now that we’ve moved on to working with arrays and objects, which are referenced

, it’s necessary for us to ensure that we keep our state data immutable by making copies of the data before making updates to it. To achieve this we’ll be using the spread operator and array methods like 

 that create a new array instead of mutating the original. For our examples let’s work with an array of users:

All of the patterns above can be used on either arrays of primitive values or arrays of objects (arrays of pretty much anything, really, but primitives and objects are probably most common), but for the examples below we'll just work with arrays of objects. Let's assume these objects store state properties of 

. Since working with arrays of objects adds some code and complexity I’ll have each of the examples in a dedicated function with all of the associated logic:

That’s all I wanted to discuss about React state for now, but I hope, dear reader, that you gleaned something useful from this pair of posts. Thanks for reading and may your powers of React proliferate in 2021 and beyond!

Interior glass facade of the Harpa Concert Hall in Iceland. 

States of React State (Part 2)

React Hooks have been around for about a year now and they’re a fantastic addition to the library. For those of you new to hooks, they allow you to hold state and do things like key into lifecycle methods from within lighter-weight functional components instead of having to use class components. If you had to choose one type of component to invest your time into learning it’s probably safe to say that it’s functional components with hooks, but class components are still very relevant today since there are sure to be many apps written in classes that work perfectly well and don’t need to change, and others that will probably continue to make transitions to hooks for years to come (hooks can be incrementally adopted so it's not like you have to only use classes or hooks), so at least for the time-being, React developers should be comfortable working with both types of components. This can of course be a little burdensome for newer React developers who have to simultaneously learn the two different formats, so in this pair of blog posts I wanted to briefly go over state in React, highlight some of the differences between working with functional and class components, and also show you some of the common patterns used when setting state in React. These posts will primarily be aimed toward newer React and JavaScript developers, but they should also serve as a handy reference for anybody trying to remember how state works in each type of component and how to set state in its various forms. Note that I won’t be discussing more advanced forms of state management like React Context or Redux-like patterns, nor will I discuss component lifecycle in very much detail, but keep in mind that these are also important topics to learn when considering how to best manage React state so you should learn about them as well.

State, in programming, can refer to a number of different things, but it generally refers to the current condition, shape, or order of part of a program. In React, state is where you keep your variables and the values they hold, which React then uses to determine how to render the user interface and interact with the rest of your app. React state has an initial, default value that will typically later be updated any number of times as the user interacts with the page. Once state is updated (i.e. “set”), other components and parts of the site will react to those changes, whether that includes something like rendering new content to the page, fetching new data from an API, or updating a record being stored in a database. Before hooks were released, React state had to be stored in ES6 class components, which are great but they can often be bulky with a lot going on. Now that we have the 

 hook we can manage state in more simplified functional components and generally keep our front-end components easier to use, reuse, reason about, and test.

The syntax you use for working with state in classes and functional components is different, but many of the general principles are the same, so once you learn one it’s pretty easy to apply those principles to the other. The types of code patterns you use for setting state will apply to either form, which is nice, but to further add confusion for newer React developers, there are many different ways to set state depending on if you’re using newer ES6 syntax like the 

 or more traditional methods. The good news is that these patterns are really interchangeable between the two types of components as long as you have a tool like 

 (apps created with Create React app use Babel by default) that converts the more modern JavaScript syntax into a form that older browsers can understand.

When working with state in React it’s usually recommended that you adhere to keeping your state immutable, which means that you shouldn’t directly update state objects once they’ve been created. Immutability has a host of potential benefits but one of the primary reasons React places emphasis on it is because it helps React efficiently determine when it needs to re-render components. Primitive JavaScript values like strings, numbers, and booleans, are already immutable, but when you’re working with state that’s stored in a referenced data-structure like objects and arrays (arrays are just a type of object) you should try to ensure that you first make a copy of the data, then make modifications to that copy, and then set the new state with the modified copy. The way you go about immutably updating state often requires more care than you ordinarily would use if you were just modifying an object or array directly. All of the code examples in these blog posts will have immutable state updates, and in the next post in this series I’ll be focusing more on showing you some of the patterns you tend to see when setting state across different shapes of data that state is commonly held in. For now, I’d like to go over class and functional components and highlight some of the differences.

The following is an example of a simple class component:

 from the React library by name, but you can also just use it without explicitly importing it by adding the 

 property onto the main React import like 

In this example I have one state value called 

 and when the user types text into the input field the 

 function handles taking that value and updating the 

 state. Note that I’ve defined the state inside of the class constructor, which is a commonly used way of writing a class component, but it should be noted that you’d really only use a constructor when you need to bind class methods but you don’t want to use auto-binding ES6 arrow functions (I am using traditional binding in the example). The constructor is often used to initialize state (

) but you technically don’t need the constructor to do this as long as Babel is set up to handle compilation and add the constructor “behind-the-scenes”. This next example shows how the component above would look without a constructor:

Notice that the only things that have changed now that the constructor is gone are the state, which is now a property directly on the class (this “class property” syntax is currently in the final stages of refinement before it will formally be added to JavaScript but you can use it now because of tools like Babel), the 

 function in the constructor we use an arrow function to bind it.

When it comes to setting state in a class component you’ll typically be calling React’s 

setState(stateUpdater, [optionalCallback])

. I’ll go over the different forms of using the API shortly, but the most common way to use it is to pass it the 

 argument an object with the properties you want to update. In the following example, we’re passing it 

 state value will be updated to hold the result of what the user typed into the input field:

A common mistake to be aware of in React is that if you attempt to set state directly without using the 

 function (e.g. in a class component doing something like 

), it will still technically update the state, but since you didn’t use 

 React won’t know that anything was updated so your components won’t rerender to show updated state values and you’ll violate the principles of immutability that I mentioned earlier. The only time it’s OK to not use 

 is when initializing state with a value when the component first loads:

Another thing to be mindful of when setting state in React is that 

, so the state isn’t always guaranteed to be updated before you attempt to do something else in your code where you’re relying on the state being updated, particularly when you’re making multiple 

 calls in close succession. For instance, if you make two back-to-back calls, React might batch the first call with the second so that once the second runs, the first state call may not have updated state yet. 

More often than not you'll start out just using the first form of 

 where you pass it an object with the updated state value, but for best practices, there are a couple of different ways you can take advantage of the API to help ensure that your state has been updated before you act on it. The first way is that you can pass in a function as the first argument to 

 represents in the syntax above). React will then pass this 

Working with State in Class Components vs. Functional Components

Filter by Tags:

Posts:

JavaScript Event Propagation

Learn Enough Styled Components to be Dangerously Fabulous

States of React State (Part 2)

States of React State (Part 1)

The Three Trees of Git (Part 2)

The Three Trees of Git (Part 1)

The Elegance of the Modulo Operator