DEV Community: Brad Westfall

The useEffect cleanup and the two circumstances it's called.

Brad Westfall — Thu, 23 Mar 2023 16:57:38 +0000

(Originally posted at ReactTraining.com)

The cleanup function is a function returned from within the effect function. It gets called when the component unmounts but you probably already knew that.

In my workshops I ask developers when the function gets called and I regularly get this one answer. But in the 100s of workshops I've taught over the years, I think I've only ever heard the full correct answer from one person (hats off to that person).

useEffect(() => {
  getUser(userId).then((user) => {
    setUser(user)
  })

  // Cleanup Function: Called when we unmount
  return () => {}
}, [userId])

You're probably skimming this article and want to jump strait to the second circumstance it gets called:

The cleanup also gets called when the dependency array changes and the effect needs to run again. But it's the previous effect's cleanup that runs before the next effect function runs. You might need the full article to really understand...

Why Cleanup

To better understand both of the circumstances it's called, we need to do some examples of why you would want to do a cleanup in the first place.

In the code above, the most well-known reason is unfortunately the most misguided one so we'll start there. People think we need to cleanup because if we don't, we might "set state on an unmounted component".

We have another post where we do a deep dive into why you shouldn't care about fixing this particular problem, but it is a great starting point because we need this same fix for other reasons we'll show later.

Preventing our component from setting state when it's unmounted can look like this:

useEffect(() => {
  // 1. After the component renders, the useEffect function is called
  // and we're guaranteed to be mounted at this point so set this flag
  let isMounted = true
  getUser(userId).then((user) => {
    if (mounted) {
      setUser(user)
    }
  })

  // 2. We do the actual side effect (getUser) and now we need to return
  // a way of "cleaning up" any problems that might occur because of it.
  return () => {
    isMounted = false
  }
}, [userId])

The major takeaway so far is that we're returning the cleanup but not calling it, and when we return this cleanup, the promise is still pending.

Now, the race condition begins. Is the component going to unmount first (maybe we navigated to another page) before the promise resolves? Or is the promise going to resolve first?

If the component unmounts first before the promise resolves, this code will prevent us from setting state on an unmounted component -- if that's what you wanted to do. I'm saying that doesn't matter

To be clear, I do want the cleanup solution we wrote but only because it fixes a different problem, a race condition.

Race conditions

Let's go back to before we had our isMounted code:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null)

  useEffect(() => {
    getUser(userId).then((user) => {
      setUser(user)
    })
    return () => {}
  }, [userId])

  return <div>...</div>
}

In this UserProfile component, let's imagine we can click on friends of this user. Perhaps we're looking at users/1 now but we could quickly click and go to users/2, then users/3, then users/4, and finally users/5. All these clicks would cause our component to re-render with a new userId prop.

We make these several clicks very fast and ultimately users/5 should be the one we end up seeing since it was the last one clicked. Here's what happens though...

Each time we click, the re-render and new userId means we re-run the effect function based on that new userId. We now have a race-condition where the network requests could return in a different order than we sent them. The network request that resolves last wins. We want to be looking at users/5 but perhaps the network request for users/4 was a lot slower than the rest and it resolves last. You're now incorrectly looking at User 4.

The other circumstance the cleanup gets called...

The cleanup function will get called when we "switch" effects. In other words when the dependency array changes and we're about to run the useEffect() function again. React will run the previous effect's cleanup just before we run a new effect. We can illustrate this with a timeline.

Timeline...

Conceptually, this is what it's like when React calls our functional component, let's think of the effect that runs as being the "current effect":

UserProfile() // useEffect runs based on user 1: this is the current effect

Lets say we get some re-renders that have nothing to do with the userId changing. React calls our component again but the current effect still belongs to that first render when it ran:

UserProfile() // <-- current effect
UserProfile() // re-render
UserProfile() // re-render

So you can see that we might have a "recent render", but the "current effect" was from a previous render.

Then the userId changes and we get a re-render again. This re-render needs to run the useEffect() again. But wait, before we do that we need to "cleanup" the old "current effect" first.

UserProfile() // 1. cleanup this effect first
UserProfile()
UserProfile()
UserProfile() // 2. run this effect after the previous cleanup runs (now current)

If we do a cleanup like this, we can fix our race condition:

useEffect(() => {
  let isCurrent = true
  getUser(userId).then((user) => {
    if (isCurrent) {
      setUser(user)
    }
  })
  return () => {
    isCurrent = false
  }
}, [userId])

Hey look, it's the exact same solution as the one we used to not set state on an unmounted component only the variable is more appropriately named because we now understand that the function isn't only called when we unmount.

With this cleanup, every time the userId changes, we cleanup the previous effect first which prevents it from setting state when it resolves. Then we run the effect for the next user we want to see and it now becomes the current effect.

When this happens really fast and we change the current effect while we still have pending promises, the net result is we avoid the race condition by "canceling" the previous effects ability to set state. We want to only see users/5 when it resolves and all previous effects will not be able to set state regardless of when they resolve.

It's interesting though that this solution also prevents us from setting state on an unmounted component -- not that we care about that, but it's interesting.

In a way, you could conceptualize these two circumstances as being combined into one rule:

We cleanup when an effect is no longer relevant. It's not relevant when we unmount and when we need to ditch an old effect to start a new one. However you think of it, as long as you understand it I'm okay with that.

Happy coding.

React: Setting State On An Unmounted Component is probably not a problem

Brad Westfall — Thu, 23 Mar 2023 16:53:44 +0000

(Originally posted at ReactTraining.com)

Did you ever get this warning in React?

Warning: Can't perform a React state update on an unmounted component. This is a no-op, but it indicates a memory leak in your application.

Did you know you can probably ignore it if you do get it? 🤔

This warning has caused lots of bad habits and unnecessary fixes in React among developers who don't fully understand it. That's probably why React got rid of the message in React 18, because we usually do not have a memory leak when we get this message so there's nothing to be fixed.

For years, React devs (including myself) were jumping through hoops to get this message to go away. React must have some secret insights to whether we have memory leaks right? And if I can only get this warning to disappear, I must have fixed the problem? Right?

Let's start by showing you when you would have received this error prior to React 18.

First, we need to create some sort of delay for setting state so it runs after the component has unmounted. A common use-case where developers would see this warning is when we set state from an async operation like data fetching in useEffect():

function UserProfile({ userId }) {
  const [user, setUser] = useState(null)
  const [error, setError] = useState(null)

  useEffect(() => {
    // Effect runs and promise starts
    getUser(userId)
      .then((user) => {
        // The promise resolves later and there's no guarantee
        // the component is still mounted, yet we're setting state
        setUser(user)
      })
      .catch((err) => {
        setError(err)
      })
  }, [userId])

  return <div>...</div>
}

If you never saw the warning in React 17, it might be because you were developing locally and your network latency was near 0 to your local environment. This is the kind of thing you can miss in local development but makes its way into production with real network latency.

Remember, promises are called promises for a reason. They will resolve or reject. That's the promise they make. It doesn't matter to JavaScript that your component is considered "not mounted".

So what happens when we try to set state on an unmounted component?

Nothing.

React considers this a no operation and they just ignore it. There is absolutely no memory leak in this code.

So why the dramatic warning?

From React's perspective they have no idea what you're doing in your useEffect. They call this function and expect that you might return a cleanup to fix any of your issues that they don't know about:

useEffect(() => {
  // 🙈 React can't see any of this
}, [])

There's no way they could know if you did create a memory leak. They just know that setting state on an unmounted component has a very small chance of being a leak so they're just letting you know. Promises like the one we were doing don't generally cause memory leaks. But again, React didn't even know we did a promise.

Don't worry, I'll show you how to identify a memory leak further down.

Cleanup Function

As many of you already know, useEffect has a cleanup function that can generally be used to cleanup any problems you may have created with your side effect. For these next sections, it's very important that you understand the two circumstances that it's called.

I notice a lot of React devs are aware that the cleanup gets called when the component unmounts. But it's critical to understand it also gets called when we switch effects. Please understand exactly how that works from my other article before continuing.

If you understand cleanups, then you understand this code fixes a few problems. Aside from preventing us from setting state on the unmounted component, it also fixes a race condition when the userId changes fast:

function UserProfile({ userId }) {
  const [user, setUser] = useState(null)

  useEffect(() => {
    let isCurrent = true
    getUser(userId).then((user) => {
      if (isCurrent) {
        setUser(user)
      }
    })
    return () => (isCurrent = false)
  }, [userId])

  return <div>...</div>
}

To be very clear:

We don't have a memory leak so I don't care about the fact that this cleanup prevents us from setting state on an unmounted component.
I do care about the other race conditions this fixes so this is the real reason for needing to cleanup in this case.

As I stated before, promises don't generally create memory leaks.

What will create a memory leak?

Subscriptions that we don't unsubscribe from.

Let's do a stock quote component and imagine we're subscribing to a socket on the server that's pushing realtime data to us:

function StockQuote({ ticker }) {
  const [price, setPrice] = useState(null)

  useEffect(() => {
    subscribeToTicker(ticker, (newPrice) => {
      setPrice(newPrice)
    })
  }, [ticker])

  return <div>...</div>
}

This component subscribes but it never unsubscribes. If we're looking at the Google stock price and we navigate away and therefore unmount, we create a memory leak by the fact that we're going to be setting state forever on a component that's no longer mounted. We might go back to this component and it doesn't matter if we go back to Google ticker again, we will now have two subscriptions that stick around forever.

See what I mean about promises now? Promises only resolve or reject once so they don't create the ongoing problems that subscriptions are prone to.

Aside from unmounting, there's another memory leak that will probably occur. If we switch from Google to Apple and get a re-render, the ticker change will run the effect again and now now we're subscribed to Apple and Google at the same time. Memory leak created.

Let's do a cleanup to unsubscribe and fix the leaks:

useEffect(() => {
  subscribeToTicker(ticker, (newPrice) => {
    setPrice(newPrice)
  })
  return () => unsubscribe(ticker)
}, [ticker])

You'll notice a pattern where the isCurrent strategy we did works for promises because again they just resolve or reject once, but subscriptions need to be "unsubscribed".

This also fixes both of those memory leak scenarios because remember the cleanup gets called in two circumstances:

When we unmount we unsubscribe. Memory leak fixed
When we switch from Google to Apple, this cleanup will unsubscribe from Google before it subscribes to Apple. Memory leak fixed.

What are common subscriptions?

This is not a comprehensive list, but here are a few things that would be side effect subscriptions that need to be unsubscribed from in the cleanup:

Sockets with the server.
setInterval(). This is a subscription to the clock which needs to be cleaned up with clearInterval().
DOM Event listeners. Sometimes you might need to do window.addEventListener() from a useEffect().

Event Based Side Effects

Side effects are generally either:

Event Based Side Effect - A side effect that runs because a DOM event occurred, like a button click to update a user.
Render Phase Based Side Effect - A side effect that runs after render phases. These are the ones that use useEffect(), like data-fetching when the component mounts.

Some people (including me) used to think that we should run all side effects out of a useEffect function and avoid running them inside your events. This was a common opinion for a while but let's debunk it.

function UserList() {
  const [message, setMessage] = useState('')

  // Event
  onRemoveUser(userId) {
    removeUser(userId).then(() => {
      setMessage(`User ${userId} was removed`)
    })
  }

  return <div>...</div>
}

The thought was, if we run our side effect strait out of the function, then how are we going to clean it up?

The real question is, why do we need to clean it up? Are we trying to fix the "setting state on unmounted components" problem? I'll say it again, that was never a problem it was just a warning that you might have a memory leak and we don't have one here with this promise.

And yet, people would jump through hoops to get the message to go away like we might set state from the event function so we could respond to the re-render and new state with a useEffect() just so we could have a cleanup just so we could fix a non-existent problem.

Fine, but what if the user rapidly clicked to remove users like our race condition example from this article? Can we create a race condition problem where we need a cleanup and therefore need to jump through hoops to get a useEffect() to run instead of running out of the event?

I don't think so. The problematic race condition we did in that article was more about loading and showing the right data to the user. It was a real problem. Here, the only problem that would happen if the user clicks to remove a bunch of users quickly is we'd see the "success message" change frequently. That's a user-experience issue that we can fix by doing success messages differently, it's not a race condition bug like we had talked about.

Summary

The big takeaway is that we only need to worry about actual memory leaks and that setting state on an unmounted component simply tells React that there's a slight possibility we have a problem. I say slight because it's just my opinion that of all the ways to delay the setting of state, you're probably doing promises more than subscriptions.

I feel like removing the warning was the best decision, but here's what's going to happen next:

You'll have a memory leak you are unaware of. Just be keen on understanding that subscriptions are prone to them and you'll probably be okay.
Some devs will interpret the words from that GitHub pull request as meaning we don't need to cleanup. Their only notion of cleaning up a promise-based side effect was to do isMounted to prevent the setting of state on the unmounted component. They might think they can remove that logic now because there is no memory leak and no warning. But as we saw already in the other article I wrote, the logic fixes other problems.

React: isMounted tricks are code-smell

Brad Westfall — Thu, 23 Mar 2023 16:46:35 +0000

(Originally posted at ReactTraining.com)

There's a variety of tricks that you see out there for determining if the component is mounted. These are usually code-smell because you're thinking in terms of "time". We thought in terms of time with class components but we don't want to with functional components and Hooks.

Instead you should think in terms of snapshots with functional components. In other words, based on this state here is a snapshot of my UI without regards to how long the component has lived on the screen.

Snapshots are "moments" in time sure, but we're not thinking in terms of "this is the early life of my component" or "late life". We're not thinking in terms of the component being mounted still.

When I see this custom Hook, I usually see bugs soon after:

const isMounted = useIsMounted()

I guess the motivation is to reduce this kind of boilerplate:

useEffect(() => {
  let isCurrent = true
  getUser(userId).then((user) => {
    if (isCurrent) {
      setUser(user)
    }
  })
  return () => (isCurrent = false)
}, [userId])

I suppose the intention is to do something like this now instead of the approach above?

const isMounted = useIsMounted()

useEffect(() => {
  getUser(userId).then((user) => {
    if (isMounted) {
      setUser(user)
    }
  })
}, [userId])

At first it seems like we're trying to prevent ourselves from setting state on an unmounted component? But did you know that first code with the cleanup fixes other bugs and the second one without the cleanup has bugs?

Also, avoiding setting state on an unmounted component is not something you need to be concerned with.

In a pull request where the React team discusses removing the warning for setting state on an unmounted component, Dan Abramov discusses this an isMountedRef trick as being one of the canonical approaches to certain problems and says it's a "pretty clumsy" solution that will give you false positives in React goes in a certain future direction.

In the future, we'd like to offer a feature that lets you preserve DOM and state even when the component is not visible, but disconnect its effects. With this feature, the code above doesn't work well. You'll "miss" the setPending(false) call because isMountedRef.current is false while the component is in a hidden tab

To be clear, I'm talking about some component-wide general use variable like isMounted.

Doing proper cleanups like this is not what I'm referring to:

useEffect(() => {
  let isMounted = true
  getUser(userId).then((user) => {
    if (isMounted) {
      setUser(user)
    }
  })
  return () => (isMounted = false)
}, [userId])

The above code is good because we're properly cleaning up this effect. I don't like the variable name isMounted because the developer who writes it is probably confused about when the cleanup gets called, but the variable name doesn't matter in terms of how this code fixes a variety of issues.

These are the anti-pattern "component-wide" variables that either create bugs (because they encourage you to not use specific cleanups) or just add extra unneeded logic like preventing us from setting state on an unmounted component in situations that are not actually problematic to do so:

const isMounted = useIsMounted()

useEffect(() => {
  getUser(userId).then((user) => {
    if (isMounted) {
      setUser(user)
    }
  })
}, [userId])

function someEvent() {
  if (isMounted) {
    // do stuff
  }
}

As I'm writing this I did a quick search on Google to see if there were similar articles and this was the first thing that came up from the old React docs 😆

https://legacy.reactjs.org/blog/2015/12/16/ismounted-antipattern.html

This was from the era of class-based components, but still it's always been an anti-pattern folks!

Thanks for reading.

New to Web Development? Let's show you three ways to setup a Local Server

Brad Westfall — Mon, 06 Sep 2021 19:54:30 +0000

Photo by Philipp Katzenberger on Unsplash

This is a preview from my CSSBootcamp.com course.

If you're newer to web development, I understand it can feel a bit chaotic when you want to just start by building something simple. This video shows you how to setup a local server in three different ways so you can run your website on your machine "locally".

#1. VSCode Extensions

If you're using VSCode, you can probably setup a local server for static HTML, CSS, and JavaScript websites with an extension called "Live Server". Just go to the extensions section in VSCode and search for "Live Server"

Install it and then click the "Go Live" link in the footer of VSCode. Make sure you have a project folder open so the extension knows what folder to use as your server. See the video above for an example.

#2. Starting a server from CLI

These next two options require just a little bit of CLI knowledge. Even if you don't much CLI, you'll need to learn it anyways as a web developer so take every chance you get to learn something new in CLI.

We're going to use a Python command to run a server on a Mac. Python comes installed by default on Macs so we don't need to do much. Even if you're not doing Python development, this is a very easy way to run a server when you need one.

Make sure you cd (change directory) to the one you want to use as your server's root path. Checkout the video if you need more help with that. Then do:

python -m SimpleHTTPServer 8000

Now go your browser put this in the URL.

127.0.0.1:8000

Do Control+C to quit the server when you're finished. Since it's a python server you may need to do Control+C twice.

#3. Node and NPM with BrowserSync

If you already have Node installed (do node -v to see if you do), then you can use BrowserSync after you install it with

npm install -g browser-sync

Now you can just do from any folder and get a server

browser-sync

If you don't have Node/NPM installed, the video walks you through those steps as well.

Old React Syntax? Let's talk about old stuff and why we don't need it anymore.

Brad Westfall — Fri, 06 Aug 2021 18:26:57 +0000

This is not a comprehensive list, just a few things I was thinking about and wanted to write down for newcomers.

If you're interested in doing deep-dive workshops that take you from beginner to fairly advanced material, checkout our public workshops at https://reacttraining.com/public-workshops/

React has been around for almost 8 years which is getting up there as far as JS libraries and frameworks that stay popular. It might seem like there's a bunch of "churn" in React but most of it has been community based and not the library itself. In other words, it was super popular to use [some state manager] library with React and now maybe that library is less popular because there are other (perhaps better) choices. Maybe someone likes Sass or CSS modules and someone does CSS-in-JS libraries. Again, these are things that fall into community churn but not React itself.

Let's start with the version numbers of React before we dig into other stuff. At the time of this writing, React 18 is on the horizon. But does that mean there have been 18 major version numbers of React? Not so much.

When I got started in React around 2015 it was on version 0.12 and they hadn't released their first major version. The community was already calling that version 12 though probably because React had been out for a few years and all they had were minor versions. Similarly, React 0.14 was dubbed "React 14" by the community. When the React team was ready for their first major release, they thought it might be confusing if they called it v1 because many people who were new thought it was already on 14. In hindsight I wish they called it v1 and just dealt with that small confusion. But instead they decided to call the first major version of React v15 to try and alleviate the confusion. I guess now newcomers think there have been 18 versions of React so the confusion is there no matter what.

In reality, React has done a great job of not changing too much over its first three major versions (15, 16, and 17). The most notable changes were probably the refactor of class lifecycle methods when they renamed some of them and then the classes to hooks change. But even the classes to hooks was just a minor change (16.8) and not a major breaking change. One could have a class-based project on 16.0 and update to 16.8 without any breaking changes and then slowly migrate to hooks if they want to. We can even make the argument that this is unnecessary to refactor since some would consider their legacy projects good enough with classes and maybe they'll explore hooks in future projects.

Let's get into the main topic, the things that are old practices or syntax that aren't prevalent or necessary anymore.

`.js` or `.jsx` files

You don't need to do .jsx files anymore. It used to be that code editors weren't caught up with syntax-highlighting for JSX and needed a separate extension to get the syntax-highlighting to work. I can't speak for every code editor, but syntax-highlighting for JSX in VSCode works just fine with .js files (and has for a number of years)

PropTypes

This one depends on whether you're using TypeScript or similar tools like Flow. Without those tools, you'd create a propTypes property on your component. Here is one for a functional component:

function MyComp = () => {
}

MyComp.propTypes = {/* types here */}

Then you would use the PropTypes object to describe your props. The PropTypes object used to be apart of the core React library but they took it out and now you have to npm install it separately.

Default Props

Similar to Prop Types, you can do this:

function MyComp = ({ number }) => {
  // number will be 0 if the owner component didn't pass a number prop in.
}

MyComp.defaultProps = { number: 0 }

This isn't necessary anymore because you can do a default value for your prop in the destructure itself:

function MyComp = ({ number = 0 }) => {
  // number will be 0 if the owner component didn't pass a number prop in.
}

The React team has even told developers that defaultProps will be deprecated someday.

Memoized and Pure Components

If you want a component to not re-render when its owner (parent) component gets a re-render, you can convert to one of two things with a class-based component:

class MyComp extends React.Component {
  /* conditionally return true or false if you want the render method to be called*/
  shouldComponentUpdate(nextProps) {}
}

class MyComp extends React.PureComponent {
}

You can either use shouldComponentUpdate to individually decide on a prop-by-prop basis if there are no changes and you want to skip re-rendering. Or you can extend PureComponent which basically does the same as shouldComponentUpdate but automatically for you for all props. In general we don't use classes much anymore if we're embracing hooks though so I consider both of these to be kind of old. I just wanted to bring them up to show the equivalent way for a function component:

const MyComp = React.memo(() => {
  // This function passed into React.memo will now be "memoized"
})

This is the same as doing a class-based PureComponent

Setting State

In class-based components, the way state was batched could lead to you having some application bugs if you had some circumstances along with "setting state from state":

this.setState({ count: this.state.count + 1 })

So it was encouraged to do the other state setting API which was to pass a function into setState when you set state from state:

this.setState((state) => state.count + 1)

If you're using hooks today, maybe you did or didn't know that the state setting functions also have two API's -- one for passing your new state as the argument and one that resembles the older setState(fn) API.

setCount(count + 1)
setCount(count => count + 1)

Just know that the "setting state from state" batching issue of classes doesn't really exist anymore with function components and hooks so there's much fewer reasons to use the setCount(fn) API. The reasons I've used it are fairly advanced so we won't go over them here, but chances are you won't need it often.

So may ways to make a component!

At any given point in time in React's history, there have been only two ways to make a component. The first API back in 2013 was React.createClass and that was the only way to make a component. You'll never ever need that today unless you app is legacy from 2015. After that syntax the React team came out with real JS classes (because they were only just created for JavaScript in 2015). Then the React team came out with the functional component so starting around 2017 (I think it was) and up until today, you could do either one of these: a class or a function and those are the only two ways:

class MyComp extends React.Component {} // or
function MyComp() {}

I think some people might get more confused about the fact that JavaScript lets you make functions a few different ways so technically that functional component can be written as any of these:

function MyComp() {}
const MyComp = function() {}
const MyComp = () => {}

This isn't really "different ways" to make a component, they're all just valid functions and that's what React needs so sometimes it comes down to developer preference. There's technically a difference between these as far as JS is concerned, but those differences don't present themselves too often when we write React so it usually doesn't matter.

For a while, the community was calling the functional components "Stateless Functional Components" but we stopped doing that when they started to have state with things like hooks.

So we still just have two ways of making components

class MyComp extends React.Component {} // or
function MyComp() {} // with alternative function syntax

Some have said that there's other ways to make components like memoized components and higher order components. That's not exactly true.

A memoized component (which we showed earlier in this post) is when we simply pass a function component into the React.memo() API and they will wrap your component in another component to "memoize" it and prevent re-renders on your component when props haven't changed. It's not exactly a "another way" to make components as much as it's just a feature of them. The same is true for class-based and PureComponent.

Higher Order Components (HoC) are a pattern where you pass a component into a function that helps you to make an abstraction for your component. It was an awkward community-driven pattern that many React developers would even say is an anti-pattern at this point. "HoC" is not apart of the React API, it's just a pattern for class-based components that we don't need anymore because of hooks. So this isn't a "type of" component and you probably don't need to learn the pattern at all unless you're doing class-based components.

But the documentation...

The React documentation still has a lot of their docs written for class-based components because over the last two years most companies have been transitioning to hooks and it didn't make sense to get rid of the old docs as soon as hooks came out. Right now the React team is re-writing the documentation to be more about hooks and less about classes (which are still technically supported but the community considers to be legacy). Because of the older importance of HoC's with classes, there's still a documentation page for them. But again this is old and is also not "a type of component".

Hopefully this clears some things up. I might add to this as I think of things. Feel free to ask any syntax questions in the comments.

As stated before, if you're interested in doing deep-dive workshops that take you from beginner to fairly advanced material, checkout our public workshops at https://reacttraining.com/public-workshops/

Why React? Because it's pretty cool actually. Misunderstood at times, but cool 👍

Brad Westfall — Wed, 04 Aug 2021 20:19:56 +0000

A hopefully well received and educational response to "why react sucks" - https://dev.to/jfbrennan/really-why-react-5958

JSX templates

JSX is not a "templating language", it's actually considered to be the antithesis of one. Templating languages suffer from becoming a DSL (domain specific language) whereby the "language" must recreate things like conditional logic and iterations with some proprietary "template language syntax" that will never be able to do as many things as it's host language.

JSX was added as a way to avoid using React's own createElement API.

Not at all, React.createElement is the underlying API for React to which JSX was created specifically to compile to. It's not like JSX was created long after React to "avoid something". Instead, the main idea is that any programmatic way of building DOM nodes is messy when it comes to nesting. For example it's horrific in jQuery or vanilla JS. So instead of nesting function calls like this to make DOM nodes:

React.createElement(
  "div",
  null,
  React.createElement("h1", null, "Hi, welcome to JSX"),
  React.createElement(
    "p",
    null,
    "It's a function call, not a tempesting language"
  )
);

🎉 You can write this which is also nested function calls:

<div>
  <h1>Hi, welcome to JSX</h1>
  <p>It's a function call, not a tempesting language</p>
</div>

To use JSX is to call a function:

const message = 'I teach workshops at reacttraining.com'
<div>{message && message.substr(0, 7)}</div>

// compiles to
React.createElement(div, null, message && message.substr(0, 7))

And because it is essentially a function call we can think of props as arguments. We can avoid doing DSL nonsense and have the full power of the host language (JavaScript) by way of JS expressions.

So why only expressions? 🤔

Because again, it's a function call. You can't do statements in JSX because you can't do them as arguments to functions:

// Nope, not allowed
<div>{if (condition) {}}</div>

// Because it would compile to this:
React.createElement(div, null, if (condition) {})

JSX is designed to be nested function calls that look familiar to us like XML or HTML so our eyes don't burn when look at actual nested function calls but also with the easy and power of a full programming language.

This is why you also can't do this and return two JSX nodes -- because they're function calls:

function App() {
  return <div></div><div></div>
}

// Compiles to 
function App() {
  return React.createElement('div') React.createElement('div')
}

And you can't just call two functions back to back

If you ever see {' '} in JSX, that's because in HTML (which JSX is not) white space is treated a certain way. More than one whitespace character is reduced down to a single whitespace. Because JSX is a function call, it kinda sucks I'll admit, but you have to do {' '} in a few scenarios to create whitespace. On a really big project I might have to do that like 4 times, not a big deal.

Because of all this specialness you can't easily port JSX. That rubs me the wrong way. Template code should be easy to port because HTML is a standard.

Again, it's not meant to be HTML

For example, in JSX you do:

<div className=""></div>
<label htmlFor="" />

A lot of people who are critics of JSX will say "why does it have to be different from HTML...?"

Did you know "The class is an HTML Attribute, while the className is a DOM Property." - MDN

https://developer.mozilla.org/en-US/docs/Web/API/Element/className

Turns out there's always been a difference between HTML and JS in terms of what an HTML attribute is and the corresponding way to modify that thing in JS. The same is true for <label>. Some who don't know might complain that in JSX we do <label htmlFor=""> instead of HTML's <label for="">. But again this is how it's done in plain JavaScript. Checkout the MDN docs for yourself 😉

https://developer.mozilla.org/en-US/docs/Web/API/HTMLLabelElement/htmlFor

For example, the perfectly valid <label for=""> will not work because for gets parsed as JavaScript. You have to use a funny JSX attribute: <label htmlFor="">.

I think we covered that one.

Also, you have to do a funny comment syntax because HTML comment syntax is not allowed.

It's not HTML 👆🏻 The reason for the "different" not "funny" comments is because Babel would confuse these comments for being content -- like if you were documenting how HTML comments work:

<div>
  <!-- HTML comment -->
</div>

And don't forget to slash your self-closing tags, e.g. <img />, even though HTML5 dropped that syntax more than 10 years ago.

Actually not really true. XHTML was going to be a thing in the 2000's so browsers started to implement some of it. The W3C eventually ditched the idea and did HTML5 but not before things like trailing forward slashes were already implemented by most browsers. Today, we can still do "XHTML" style self-closing tags on <img /> <-- that's valid HTML, it's not "dropped" it's just left over baggage from an old W3C idea that the browsers kept.

By the way, JSX stands for "JavaScript and XML" -- because it's a JavaScript function call (have I said that already) with XML (not HTML) syntax. In XML you do have to close your self closing tags with a forward slash.

Another one I still don't understand and don't want to understand is: Error: The style prop expects a mapping from style properties to values, not a string.

It's easier to programmatically make inline styles if we express them as an object. And again, since this is a function call™, we can do that. This feature has also played a big role in developing things like CSS-in-JS which you can decide you don't like or you just don't like that it's an object. But it's not a "ridiculous speed bump".

[React is an] "unmanageable mess" [because of] Functional or Class-based, controlled or uncontrolled, forwardRef, mixins, HOC, Hooks, etc.

That's not the point they were making. Because React lost a primitive (mixins) for sharing re-usable business logic when they switched from their original API to classes, the community (not the React library) came up with some patterns to share code, one of those patterns was HoC which has a way of double or triple wrapping your components in other components in order to solve the problem of sharing re-usable code. This meant that when you "look at a typical React application in React DevTools" there's extra wrappers in the component viewer (not the actual DOM). The React team realized for many reasons that not having a primitive way to share code was causing React developers to do things that were a little more messy, so they created hooks to give us a primitive API for sharing code.

In no way were they trying to say that React is messy because of that list. This whole section was kind of reaching for things that aren't really there to fit into a narrative.

The fact that there are so many options and types of components confuses me.

Clearly 😕

There are only two ways to make components -- functions and classes. The vast majority of the React community is embracing functions because of hooks. There are three ways to make functions though in JavaScript so maybe that was confusing? But that's not React's fault.

Those other things (controlled or uncontrolled, forwardRef, mixins, HOC, Hooks) are not components, they are "features" to which components can have and some of them are alternatives to each other so it's not like all of those are used at the same time. Some are even from different time periods (mixins the first API, Hoc's the abstraction for classes we dont' use because hooks exist now. etc). So it's not like we're sitting around going "Should I use a mixin today or an HoC or a hook".

When a tool can be used in so many ways it creates doubt in its user. That's why, as the React team admits, "even between experienced React developers [there's disagreement]"

Again, there's basically one way to make components since not many are using classes anymore. React is a "library" not a framework. It's not Angular, or Knockout, or Ember (by the way how are those doing) that does the "batteries included" monolithic approach. In React, the reason why two React developers might have a disagreement is because one might want to use Redux and one might want to use context. Let's not be dramatic and act like all the other web communities are 100% on the same page with every single thing. React just lets us choose the tooling that goes on top of React for different architectures. That's a good thing. And by the way, the "disagreements" mean that there's discussion and the best ideas rise to the top. This has not been the case for the monolithic frameworks.

I stopped reading about there because like I said in the comments, practically every paragraph had wrong or misleading information.

We all have different tools like we like. That's cool 👍 You don't have to like React, I don't mind that. But there were many falsy or misleading things and beginners who don't know any better read this kind of stuff.

JavaScript, the "React Parts"

Brad Westfall — Wed, 04 Aug 2021 16:01:51 +0000

React became really popular around the same time that ES2015 (ES6) came into existence (those are just the technical version names for JavaScript). For this reason, some beginners learning React are also trying to tackle more modern JavaScript syntax at the same time. If you're new to both, it can be confusing as to "what is JavaScript and what is React". This document should serve as a primer to help you get up-to-speed on JavaScript syntax that we feel matters the most for learning React.

Semicolons
Variables: var, let, and const
Template Literals
Expressions vs Statements and Declarations
Functions
- Arrow Functions are Special
ES2015 Syntax Sugar
- Shorthand for Object Methods
- Object Destructuring
- Array Destructuring
- Property Shorthand
- ...Spread Syntax
- ...Rest Syntax
- ES Modules
Arrays
- Array.isArray()
- .map()
- .reduce()
- .filter()
- .find()
Short Circuiting with &&
Optional Chaining with ?.

Semicolons

Perhaps you've heard or seen that semicolons aren't exactly required in JavaScript. There has been a ton of debate on whether or not devs should use them anyways, but the main points usually boil down to:

Point: You should use them because there are some edge cases where not having them can be a problem
Counterpoint: True, but if we use Babel to "transpile" our code, Babel is going to take the code we wrote without semicolons and it's going to add them back in for us anyways, so why does it matter?
Counterpoint: Yes, but... and it goes on and on

Whether you like or don't like them is totally up to you. One piece of tooling that seems to normalize the conversation a bit is prettier.io, a formatting tool which rewrites the code as you type, or as you save, or as you push -- whichever you prefer. With tools like prettier, many of the "what is your preference" conversations are going away because tooling helps to normalize the code.

Variables: `var`, `let`, and `const`

JavaScript has always had var, which creates function-scope (or global scope). This can be a little confusing sometimes and is not often what we need.

"Block Scope" can be easier to understand and manage which is why JavaScript got let, and const in ES2015. Here's a quick rundown of how all three work:

// `var` is not block scope, it has global-scope in this
// case. Here, `name` always refers to the same thing
// because of that global scope.
var name = 'Michael'
if (true) {
  var name = 'Bruce'
  name // 'Bruce'
}
name // 'Bruce'

// `let` is block scope. This means if we declare name with
// `let` in the block of the if-statement, that `name` will
// be "Bruce" inside that block, and the outer `name` will
// still be "Michael"
let name = 'Michael'
if (true) {
  let name = 'Bruce'
  name // 'Bruce'
}
name // 'Michael'

// `const` is also block scope like let
const name = 'Michael'
if (true) {
  const name = 'Bruce'
  name // 'Bruce'
}
name // 'Michael'

// The difference is that `let` can be reassigned
let isOpen = true
isOpen = false
isOpen // false

// `const` cannot be reassigned
const isOpen = true
isOpen = false // throws error

// `const` in JavaScript does not mean it's a super
// global constant for the whole application like how
// other languages might have. In JS, it just means
// it's block scope and cannot be re-assigned for that 
// block.

// Although const cannot be reassigned, if the value
// is an array or an object, it's inner parts can be
// changed, as long as the array or object itself isn't
// reassigned
const list = []

// The `list` will always be this array, we can't change
// that, but we can modify the parts:
list.push('Michael')

// But this is not allowed, we cannot change (reassign)
// list to be something other than the array it started
// off to be
list = 'turn list into a string'

We find block scope to make more sense to people and is generally more useful. Personally, I never use var anymore simply because it doesn't do anything I need. 99% of the time I use const since I don't need re-assignment, and if I do re-assignment, I use let.

Template Literal

Strings in JavaScript can made with single or double quotes. But when you make strings this way, you can't have multiline unless you manually add new lines. Template literals (sometimes referred to as Template strings) allow us to do multiline in a much cleaner way. Template literals use the back-tick instead of a single or double quote.

// Manual hard returns with \\n isn't fun
const str = 'multiline\\nwith\\nmanual\\nhard returns'

// This is much nicer.
const str = `
  multiline
  without
  the
  mess
`

Another benefit is string interpolation (making strings from variables)

const something = 'ugly stuff'
const str = 'instead of ' + something + ' like this'

const something = 'lovely stuff'
const str = `you can do ${something} like this`

In the first example, the str is being built with a variable. Notice we have to use + concatenation to do so. In the second example, the str is a Template literal which can use ${} to interpolate variables into the string.

When strings are made, the end result is no different if we use back-ticks, single quotes, or double quotes. So the fact that something was made with single-quotes doesn't mean anything when it comes to using it as an interpolated variable into the template literal.

JavaScript would even coerce numbers if needed:

const version = 16
const str = `At the time of this writing, React is on version ${version}`

Read more about template literals

Expressions vs Statements and Declarations

Most code in JavaScript is said to be either an Expression (Operator) or Declaration/Statement. It's not so important to memorize every last detail about these, but it is important to know some things about expressions for React since only expressions are allowed in JSX and not statements or declarations.

The brief definition is: Expressions resolve to a single value.

// If we're thinking in terms of statements, we might
// write code like this, with an If-Statement:
let result = null
if (someCondition) {
  result = 'Michael'
} else {
  result = 'Bruce'
}

// Here's how we might the same logic using a
// ternary operator, which is a type of expression
// because the line of code resolves to a single
// value for result
const result = someCondition ? 'Michael' : 'Bruce'

In this example, we have four separate expressions:

const name = 'michael jackson'
const parts = name.split(' ') // parts: ['michael', 'jackson']
let first = parts[0] // first: 'michael'
first = first.toUpperCase() // first: 'MICHAEL'

Even though these are all expressions, JavaScript lets us combine and chain expressions together. In effect, all the expressions above can be rewritten into one expression:

const name = 'michael jackson'
const first = name.split(' ')[0].toUpperCase()

// We could have even done this:
const first = 'michael jackson'.split(' ')[0].toUpperCase()

Chaining expressions looks funny at first if you're coming from a language that doesn't do this sort of thing, but if you read it left to right, each part is resolving to a value and then making itself available to the next part. When we do name.split(' '), this resolves to an array, which means the next part can pick off the 0 index with [0]. That resolves to a string value of 'michael' which can then have a string method added to it like .toUpperCase(). Whatever the far right side of the expression resolves to gets returned to the left-hand side of the equal sign, in our case a variable called first.

Functions

Functions in JavaScript can be created in several ways, each with different tradeoffs. Here are three ways to be aware of:

// Function Declaration
function getName() {
  return 'Michael'
}

// Function Expression
const getName = function() {
  return 'Michael'
}

// Arrow Function (Which is also an expression)
const getName = () => {
  return 'Michael'
}

Based on the previous section on Declarations and Expressions, it's probably more clear as to why the first two get their names. The Function Expression is an "expression" because the function is being assigned to a value. Technically arrow functions are also expressions but conversationally we usually just refer to them as "arrow functions" and not "arrow function expressions".

The tradeoffs between function declarations and expressions is that declarations can be "hoisted" and expressions cannot. However, many times hoisting doesn't matter so most developers choose one or the other simply based on personal syntax preference.

Arrow Functions are Special

Arrow functions are function expressions with a slightly different syntax. In the example above, you can see that the arrow function looks just like function expression example but without the word function and then with a => fat arrow between the parens and the opening curly-brace.

You may have heard that functions create their own scope in JavaScript. This means JavaScript functions create their own context for this which can be problematic if we want a function but without having its own context for this. One of the characteristics of an arrow function is that they don't create context so this inside the arrow function is the same as the this on the outside.

Arrow functions can also be really compact. Look at these two examples that do the exact same thing:

const getName = () => {
  return 'Michael'
}

// Same as above but more compact
const getName = () => 'Michael'

When arrow functions omit their curly-braces, it means we want the thing on the right-hand side of the fat arrow to be the return (without saying return). This is called an implicit return.

There are some more subtle details to know about arrow functions like how to return an object literal and how to omit the parenthesis for a single parameter.

Read more about arrow functions

ES2015+ Syntax Sugar

ES2015-ES2018 has brought a lot of new syntax to JavaScript that lets us do things we could always do before, but now with nicer syntax. Here are some notable examples:

Shortand for Object Methods

You can drop off the : and the word function for methods when defining them:

const obj = {
  insteadOfThis: function() {
    // do stuff
  },

  youCanDoThis() {
    // do stuff
  }
}

Note that the above is not an arrow function, just a shorter syntax for object methods.

Read more about method definitions

Object Destructuring

Object destructuring is a way to take an object and to pull out its internal properties into variables outside of the object:

const obj = { x: 1, y: 2 }

// instead of:
const x = obj.x
const y = obj.y

// We can "destructure" the values into ordinary
// variables:
const { x, y } = obj
x // 1
y // 2

// you can use this all over the place, like function
// parameters. Notice how we're passing just one thing
// (an object) into the add function. If the function
// is expecting an argument, it can destructure the
// values right in the parameter list.
function add({ x, y }) {
  return x + y
}
add({ x: 3, y: 4 }) // 7

It can be a little confusing at first because now curly-braces are used to make objects and to destructure them depending on context. So how can you tell?

// If the curlies are on the right-hand sign of the
// expression (equal sign) then we're making an object
const obj = { x: 1, y: 2 }

// If they're on the left-hand side (or the receiving
// side as with parameters), then it's destructuring:
const { x } = obj
x // 1

Read more about object destructuring

Array Destructuring

Array destructuring works almost the same as Object Destructuring but with square-brackets instead of curly-braces:

const arr = ['michael', 'jackson']
const [first, last] = arr
first // michael
last // jackson

The other difference between them is that objects have property names so those have to be used in the destructuring part. Since array values are numerically ordered and without names, the order that we destructure is tied to what value we get -- in other words, first is the first variable in the destructure so it gets the first value of the array.

Read more about array destructuring

Property Shorthand

Property Shorthand lets you type less if a property name matches the variable name in an object:

// Instead of having to type name twice like this
const name = 'Michael'
const person = { name: name }

// If the property and the variable are the same you can just
// type it like this and omit the colon and the double word
const person = { name }

Read more about property shorthand syntax

...Spread Syntax

When creating objects or arrays, there is a new way to create properties from the properties of an existing object or array. This is much easier shown in code than explained:

// Let's say you have this array
const person = ['Michael', 'Jackson']

// If you were to add the above array to a new one like this:
const profile = [person, 'developer']

// The end result would be an array in an array like this:
profile // [['Michael', 'Jackson'], 'developer']

profile[0] // this is an array
profile[1] // this is the string 'developer'

// However, if we had made profile like this with ...
const profile = [...person, 'developer']

// Then the end result would be this:
profile // ['Michael', 'Jackson', 'developer']

// The same concept works with objects
const person = { first: 'Michael', last: 'Jackson' }
const profile = { ...person, occupation: 'developer' }
profile // { first: 'Michael', last: 'Jackson', occupation: 'developer' }

Read more about spread syntax

...Rest Syntax

This might look similar to "spread" but the difference is that ... rest is not used to build objects or arrays, it's used to break then down into pieces. Here's an example of rest while destructuring:

const profile = { first: 'Michael', last: 'Jackson', occupation: 'developer' }
const { occupation, ...rest } = profile
occupation // developer
rest // { first: 'Michael', last: 'Jackson' }

Remember, destructuring is a way to break an object or an array apart into pieces. The above code makes an ordinary string variable called occupation through destructuring. The three dots ... followed by a variable name means we want all the rest of the properties into this rest object. Note that ... can be used while destructuring arrays as well. Also, the variable name doesn't have to be "rest". We could have done ...whatever.

The next form of rest comes in the form of function parameters:

function myFunction(first, last, ...rest) {
  return rest
}

console.log(myFunction('Michael', 'Jackson', 'Developer', 'California'))
// output: ['Developer', 'California']

The function parameters is suggesting that it wants a first and last name as its first two arguments, but anything you pass in after that will all be added to rest as an array.

ES Modules

Organizing and breaking your app into different re-usable files is key for a React application. Each JavaScript file is called a "module". In order to let modules work together, they need to be able to import and export code between them. While ES Modules aren't natively supported in browsers (yet), we use Webpack (or Rollup) and Babel to re-write our code that has modules into something the browser does understand.

In NodeJS, the "pattern" developed for this is "CommonJS" or (cjs). Here's what it looks like:

const SomeModule = require('some-module)
SomeModule.someMethod()

// more code here...

module.exports = SomethingToExport

"ES Modules" is an alternative pattern that is mostly compatible with CommonJS but has a different syntax:

import SomeModule from 'some-module'
SomeModule.someMethod()

// more code here...

export default SomethingToExport

Or we can do a destructuring-like syntax on the import:

import { someMethod } from 'some-module'
someMethod()

// more code here...

export default SomethingToExport

Read more about ES modules

Arrays

Here are some common array methods and functions to be familiar with:

`Array.isArray()`

// Check to see if a value is an array
const myArray = ['hello']
console.log(Array.isArray(myArray)) // true

`.map()`

Map takes an array, iterates over it with a function and whatever the function returns will be the replacement value for the item we're currently on:

const myArray = [1, 2, 3, 4]
const result = myArray.map(function(item) {
  return item + 5
})
console.log(result) // [6, 7, 8, 9]

// The above could have also been written like this with
// an arrow function:
const result = myArray.map(item => item + 5)

`.reduce()`

Reduce is similar to .map in that it iterates over an array but the end result is just one value instead of replacing all the values in the array:

// Let's add up all the values to get one value of 10
const myArray = [1, 2, 3, 4]
const total = myArray.reduce(function(tally, current) {
  return tally + current
}, 0)
console.log(total) // 10

The callback function will give us two important arguments. The first is a running tally of what we've made so far. The second is the current item we're iterating over (in our case the numbers). So, you can see that we're just taking what we have so far and adding each number to it. The only problem is we need tally to start off as 0 otherwise the first iteration won't know how to add things. That's where the second argument for reduce() comes in -- the first being the function and the second being a starting value for the "accumulator" which we're calling tally

The above could have also been written as an arrow function:

const total = myArray.reduce((tally, current) => tally + current, 0)

`.filter`

Filter gives us a new array with the same values, but only if the iterator function returns true:

const myArray = [1, 2, 3, 4]
const result = myArray.filter(function(item) {
  const isBiggerThanTwo = item > 2
  return isBiggerThanTwo
})
console.log(result) // [3, 4]

// An an arrow function
const result = myArray.filter(item => item > 2)
console.log(result) // [3, 4]

The first example clearly shows that we need to return a boolean based on if the input number is bigger than two. This can be simplified into an arrow function with an implicit return.

`.find`

Find is similar to Filter but instead of returning an array, only the first item to get true returned from the iterator function is returned from Find:

const people = [{ id: 3, name: 'Michael'}, {id: 5 name: 'Bruce' }]
const person = people.find(item => item.id === 3)
console.log(person) // { id: 3, name: 'Michael'}

Short-Circuiting with `&&`

You already know how && works in If-Statements, but perhaps you didn't know they are used to do what is called "short circuiting". Here's how it works:

function one() {
  console.log('one was called')
  return false
}
function two() {
  console.log('two was called')
  return false
}

if (one() && two()) {
  console.log('Here we go!')
}

// The only output of this code is "one was called" because of
// short circuiting

The only output from this code is "one was called". The output for "Here we go!" is not going to happen because the two function calls return false. But why is the function two() not called at all? We know it wasn't called because we never get "two was called". The reason is that most programming languages short-circuit, which means when the thing before && is false, then there's no point in checking the rest of the expression because one thing being false means the end result has to be false. Maybe you know most of that but never thought of it that way.

We can take advantage of && and short-circuiting in other place besides if-statements:

// This will cause an error if `users` is not an array
function findById(users, id) {
  return users.find(item => item.id === id)
}

// Now we are returning the person if `users` is an array
// If `users` is not an array, we the value whatever is before
// && which is `false` in that case
function findById(users, id) {
  return Array.isArray(users) && users.find(item => item.id === id)
}

Optional Chaining with `?.`

This one is used in similar cases to the && short-circuiting operator. It's actually the normal . accessor operator with an additional feature. Let's say you wanted to access users.length but users is either an array or might be null or undefined. If you tried to do users.length, you might get:

Uncaught TypeError: Cannot read property 'length' of null

So developers will do users && users.length to ensure it's not falsy (null or undefined). Of course, this doesn't ensure the value is an array to get the length, but we'll address that coming up.

Instead of doing the more verbose users && users.length, you could users?.length which does this:

Evaluate users to see if it's truthy. If it isn't, return undefined from the expression without doing .length to it.
If it is truthy, then continue with the rest of the .length expression.

Therefore, it will return undefined or the length depending on whether user is truthy. So you can see that it's very similar to && short-circuiting except that ?. will return undefined if the variable is "falsy" - not the actual "falsy" value of the variable like && would.

In a previous short-circuit example, we checked to see if users was an array before trying to do .find on it. This will be typical in JavaScript because there would be no other way of knowing that you do in-fact have an array. But in TypeScript, this check would be redundant since with types we know that users is an array already:

function findById(users: User[] | null, id: number): User | undefined {
  return users?.find(item => item.id === id)
}

For this reason, I find myself using optional-chaining more often in TypeScript since I know the types and therefore don't need the additional check that would embrace &&.

Interested in a React Workshop?

This post is from our blog at ReactTraining.com. We send it to everyone who's about to take our workshops. We always have public workshops on the schedule so check 'em out 👋

New to programming? Let's setup VSCode

Brad Westfall — Wed, 04 Aug 2021 14:37:09 +0000

This is a preview from my CSSBootcamp.com course.

We'll cover the general setup with also Snippets, Emmet, and Shortcuts.

General Setup

There's lots of professional code editor options out there. In my time doing development, it seems like there's a new "best code editor" that's even better than all the previous ones every 3-6 years. Don't be surprised if you start your career using one editor and then switch to a newer better one later.

Today, VSCode is the most popular editor to use. I'm not a fan of using something simply because it's popular, but VSCode happens to be popular because it's very good.

If you want, you can use Sublime Text or Atom which were the very popular ones before VSCode. Some of you might be coming to this course with previous experience coding and you already have your preferred code editor. That's totally fine too, but since I use VSCode and it does have the market share right now, all the setup and editor advice that I give for these courses will be for VSCode.

Download VSCode

If you're using Linux or Windows, you might need to check your system settings to see which download option is most appropriate for you.

Once it's installed, you'll be greeted by a "Getting Started" screen. You don't really need to do their whole introduction thing unless you want to. Notice they have this "Getting Started" content as a tab. You can just close that tab to exit.

Once you have it setup, you're ready to start using it like a professional. The next step is to learn how to customize settings and use all the cool keyboard shortcuts:

Snippets, Emmet, and Shortcuts

Snippets are a way for you to write a little piece of code and then you hit the Tab key and it will trigger a bigger chuck of code. The whole idea is to make writing some repetitive code faster so you don't have to type as much. Emmet is a big library of snippets that's already built into VSCode. If you're using other code editors, you might need to install Emmet separately.

Snippets are great, but sometimes you just need to be a good keyboard user with the wide array of available shortcuts you have on your computer. Shortcuts generally come in two types:

Operating System Based
Application Based

In the video above, we show you some common OS based shortcuts that we think you should learn. We also showed some VSCode based (Application Based) shortcuts. Here are the official "cheat sheets" for VSCode's shortcuts. Don't try to learn all of these, it's too much. But if you focus on just a few at a time it can make a big difference.

VSCode Settings

Here are the settings we showed you in the video above.

{
  "explorer.confirmDelete": false,
  "editor.tabSize": 2,
  // Use "Subtle Match Brackets" instead of the boxy
  // ones built-in
  "editor.matchBrackets": "none",
  "editor.renderIndentGuides": false,
  "editor.renderLineHighlight": "gutter",
  "editor.minimap.enabled": false,
  "editor.formatOnPaste": true,
  "workbench.startupEditor": "newUntitledFile",
  "workbench.colorTheme": "One Monokai",
  "workbench.iconTheme": null,
  "files.restoreUndoStack": false,
  // This prevents the "quick suggestions" menu from
  // popping up all the time which is something I don't
  // like to see, but that menu also makes Emmet behave
  // oddly. 
  "editor.quickSuggestions": {
    "other": false,
    "comments": false,
    "strings": false
  },
  // With turning off quickSuggestions, now we need to 
  // tell Emmet how we want to start our snippet triggers
  "emmet.triggerExpansionOnTab": true,
}

It's worth noting that comments aren't technically allowed in JSON files but for VSCode and their settings, they let you do it without errors so I do it 😎

Extensions

The extension we installed for our setting to use "Subtle Match Brackets" was https://marketplace.visualstudio.com/items?itemName=rafamel.subtle-brackets

This is a preview from my CSSBootcamp.com course.

DEV Community: Brad Westfall

The useEffect cleanup and the two circumstances it's called.

Why Cleanup

Race conditions

React: Setting State On An Unmounted Component is probably not a problem

Cleanup Function

What will create a memory leak?

What are common subscriptions?

Event Based Side Effects

Summary

React: isMounted tricks are code-smell

New to Web Development? Let's show you three ways to setup a Local Server

#1. VSCode Extensions

#2. Starting a server from CLI

#3. Node and NPM with BrowserSync

Old React Syntax? Let's talk about old stuff and why we don't need it anymore.

.js or .jsx files

PropTypes

Default Props

Memoized and Pure Components

Setting State

So may ways to make a component!

Why React? Because it's pretty cool actually. Misunderstood at times, but cool 👍

JavaScript, the "React Parts"

Contents

Semicolons

Variables: var, let, and const

Template Literal

Expressions vs Statements and Declarations

Functions

Arrow Functions are Special

ES2015+ Syntax Sugar

Shortand for Object Methods

Object Destructuring

Array Destructuring

Property Shorthand

...Spread Syntax

...Rest Syntax

ES Modules

Arrays

Array.isArray()

.map()

.reduce()

.filter

.find

Short-Circuiting with &&

Optional Chaining with ?.

Interested in a React Workshop?

New to programming? Let's setup VSCode

General Setup

Snippets, Emmet, and Shortcuts

Mac

Windows

Linux

VSCode Settings

Extensions

`.js` or `.jsx` files

Variables: `var`, `let`, and `const`

`Array.isArray()`

`.map()`

`.reduce()`

`.filter`

`.find`

Short-Circuiting with `&&`

Optional Chaining with `?.`