Forem: Juliano Rafael

Don't snapshot your UI components, make assertions!

Juliano Rafael — Mon, 21 Oct 2019 07:08:42 +0000

Snapshots are a great tool for testing. It enables you to ensure that something always results exactly the same thing as before, which is absolutely useful if you're unit testing pure functions. UI Components are (or should be) pure functions, so, why does the title of this article state that we shouldn't use it for UI components? Allow me to explain.

The problem

Let's imagine the following situation. You developed a card component showing an image and the title of your blog post on your personal blog. You then decide to write unit tests for this component to make sure that it shows both the image and the title.

That's an easy one, just snapshot it, and you're good to go, right?

Let's write it down:

describe('Card', () => {
  it('should show image and title', () => {
    const { asFragment } = render(() =>
      <Card image={/*some url*/} title="Title of my Post" />)
    expect(asFragment()).toMatchSnapshot()
  })
})

Boom! Your snapshot now has the markup for the whole component. You're covered.

Now you want to add a button to the component so that your readers can actually go to the post and read it, cause you know, you actually want people to read your posts. You make the change, boot up the development server of your blog and it's there, working beautifully.

Then you run your tests and they fail...

You read the test description 'should show image and title', look at the development version of your blog and you clearly see that both the image and the title are being shown, plus the new shiny button.

I hear you saying: "Well, don't be stupid, just update your snapshot!"

Update snapshot

You're right, I forgot to update my snapshot. Now I have to look at the snapshot, compare the old and new markup, assess whether the changes are intended and update it.

I have one question for you: Who's making the assertion, is it you or your test?

It's easy to do it with one component, but what will it happen you have 50 different components using the changed component and all the snapshots tests break?

We write tests to assure that our components do what they need to, fulfill its contract. The moment you are the one making the assertion instead of your test, you're swapping roles. That's literally the same as doing a manual test.

Plus, this is such dangerous behavior. It put's you into a mindset of: "I made a markup change, just update the snapshot, no need to check". That's how you just slip in a buggy component.

Tests resilience

We can also talk about the resilience of our test. The test states that it shows both the image and the title. While the snapshot does show that both of them are there, it actually does way more than that. A snapshot makes sure that the output of your component is exactly the same and before. This makes your codebase resistant to refactoring, which is most certainly not a good thing.

Your tests shouldn't care about the implementation, they should care about the results and if it meets the specs. This way you can ensure that you don't have a false negative out of a test. This test should never fail if the image and the title are being shown on the final markup, regardless of how that's achieved.

The solution

I hope that by now you do understand my reasoning on why snapshotting UI is a bad idea.

The solution is simple: make assertions!

A couple of years ago that was annoying, I agree. But now we have @testing-library with super amazing queries like getByText, getByRole, and more. If you haven't heard of, take a look at it. It's really amazing.

Let's refactor using them:

describe('Card', () => {
  it('should show image and title', () => {
    const title = "Title of my post"
    const url = "some url for the image"
    const altText = "description of the image"
    const { getByText, getByAltText } = render(() =>
      <Card image={url} title={title} />)
    getByText(title)
    expect(getByAltText(altText)).toHaveAttribute('src', url)
  })
})

A few considerations:

Meaningful error messages. Snapshot delivers the job of finding out what's wrong with the component to you. You're the one making the comparison. You do get a nice diff, but that's it. With this refactor, now the error messages actually tell you what's wrong. Be it not finding a component, which means somehow you screwed up the rendering or you changed the API of the component and have not updated your tests to cover all the changes.
No false alerts. Now, if by any means, you change the markup, add or remove anything other then the image and the title, the test won't fail and you can safely iterate on this component and refactor it to make it better in the future.
You are consuming the component as the user will. The queries provided by dom-testing-library force you to use your components just like a user would (e.g. looking for the text on the screen or looking for the alt text of an image).

Conclusion

Writing snapshot tests for your UI components has more cons than pros. It enforces a codebase that resists change. Testing for its behavior and making specific assertions, on the other hand, leads to no false alerts and more meaningful error messages.

How do you feel about this? Add up to the topic in the comments below. Let's all discuss and learn.

Why GatsbyJS?

Juliano Rafael — Mon, 25 Mar 2019 01:37:52 +0000

If you have been following front end developers out there on twitter, you probably heard of GatsbyJS. Many developers have been switching from Wordpress or Medium, as a blogging platform, and started to boot up their own sites with Gatsby. Some might say it's a hype thing, because we as developers have been guilt many times for this. We love our new shiny tools and we're always refactoring code to the latest and greatest thing, only to do it again on the next wave.

To guard ourselves from this sort of behavior, we need to dig a bit deeper and try to understand the reasoning behind it. Let's explore the following questions: What is Gatsby? What does it offer for the developers? What are the strong use cases of it? What are the downsides?

What is Gatsby?

Not so long ago Gatsby used to be referred as a static site generator. While this is totally true, it's not everything. The best definition today for Gatsby is the one you get on it's home page at the time of this writing:

Gatsby is a free and open source framework based on React that helps developers build blazing fast websites and apps.

The key point here being the word framework. Gatsby is more than a static site generator. It truly is a PWA framework. The amount of features it's plugins offers pretty much out-of-the-box is really amazing.

What does it offers for developers?

Let's face it, building website is hard and we always underestimate the effort needed, specially when it counts to best practices and accessibility. Don't even get me started on images. There a lot of checkboxes you need to check before shipping your website and failing to do it is not and option. We as developers need to provide the best possible experience for everyone everywhere or we might be not reaching everyone that needs that app or information at that moment. It is our duty as developers to always do our best to reach as much people as possible, regardless of their devices, their network speed or anything else.

What does this has to do with Gatsby? Gatsby provides a lot of best practices and solid solutions right out-of-the-box. It is a core value of the Gatsby team that websites should be performant by default. Progressive image loading? Inlining of critical CSS? Painless PWA configuration? You name it, Gatsby got you. It is really impressive. Don't believe me? I encourage you to try it out.

The solution for images is so good, that is constantly referred as a strong point of Gatsby, even thought it actually is a plugin. All you gotta do is add a couple of plugins into your Gatsby config file and you're good to go. Your images will be available on the GraphQL API at build time and the image component will handle all the resize, picking the best file format and everything else. You even get a blur up effect to improve the user experience for free.

And we have yet to talk about the developer experience. It's just awesome. Check this out:

You have HMR, which let you have that instant feedback without the need to reload the page and lose the state.
Your application will be static, so you can go serverless, which makes the whole ops to have your app always available and ready to go simply not your problem. Zero worries about maintaining a server. The dream is real.
You have the sweetest asset pipeline where everything is done at build time.
You can also have previews of your PRs deployed making super easy to visualise the changes.

This is one of the best developer experiences ready for you out there. Hands down.

What are the strong use cases of Gatsby?

The most obvious use case is clearly the static website generation. But don't let that fool you, Gatsby can do more than that. I'd go as far to say that if you're building a web app with React that can afford to have a build process and don't need to instantly reflect database changes on it's routes, you're well served with Gatsby. I honestly don't see myself picking something else for websites anymore, at least for my own side projects.

The Gatsby showcase already has all sorts of websites and apps and I can safely assure you that this is going to grow. From documentation, to business, blogs, and even e-commerce apps.

What are the downsides?

I have a hard time trying to find downsides for Gatsby. As I mentioned above, for webpages that you can't afford the build time and have to instantly reflect the database changes, you probably want to go with Next.js.

Your opinion

Do you agree or disagree with me? Please, reach out in the comments, let me know and we'll all continuously learn from it.

Inspired by @thevuedev, I created @TheReactDev

Juliano Rafael — Wed, 06 Mar 2019 01:14:36 +0000

This weekend I stumbled upon this article:

A bot that tweets new DEV articles about Vue

Daniel Elkington ・ Mar 3 '19 ・ 6 min read

#vue #typescript #serverless

And I immediately thought: "Hey, this is an awesome idea. Let's make one about React as well, cause why not?"

So I did. I created a bot that checks dev.to/t/react/latest every minute and tweets any new article. Here it is: @TheReactDev

TypeScript? Nah.

I choose not to do TypeScript on this one. It is a super small function and I felt like JavaScript would get the job done faster.

Serverless

You have many options when you do serverless. You can go AWS, Azure, GCloud, etc. The article explains in detail how to setup the Azure function and because I had never used Azure before, I followed along. The integration of Azure with VSCode is pretty cool, can't deny it, but I might switch up later on for the serverless framework to be sort of platform agnostic. Not that it matters for a project like this though. 😄

UPDATE: I had some headaches with azure. Probably because I don't have much experience with. So after a couple of hours I switched to AWS with the serverless framework for the tooling.

Scraping

Because dev.to does not have an api yet, I had to scrape away the data from the url. I had used puppeteer before, but I absolutely loved the x-ray lib. The API is so clean. I'll definitely use more of it.

Problems I had

At first, when I fetched the recent tweets from the @TheReactDev, the twitter api didn't always returned the posted urls on the entities.

[
  //...
  [ { url: 'https://t.co/AA3sKrLsDZ',
      expanded_url:
       'https://dev.to/peterj/run-a-react-app-in-a-docker-container-kjn',
      display_url: 'dev.to/peterj/run-a-r…',
      indices: [Array] } ],
  [ { url: 'https://t.co/hptME9oAgf',
      expanded_url: 'https://twitter.com/i/web/status/1102686466436681731',
      display_url: 'twitter.com/i/web/status/1…',
      indices: [Array] } ],
  // ..
]

Because of this, I started checking for the article title and author on the tweet body. The problem is that the twitter API sometimes truncate the body. The solution to this was to use the tweet_mode: "extended" on the request for the tweets.

But, just as I was writing this post, I observed that this also solves the problem of the links. With this mode, the twitter API not only returns the full_text but also returns the full extended_url as well. 😅

Checking for the URL is way more reliable so I'm rewriting my function to use this as well.

I also added a telegram bot that sends a message to a channel in case things go wrong. I choose telegram because it'll probably be the fastest way that the notification reaches me.

The repo

frontendwizard / TheReactDev

The function that feeds @TheReactDev twitter.

TheReactDev

The function that feeds @TheReactDev twitter.

This project was inspired by this article.

This function depends on a few environment variables:

dev_tag: the dev.to tag to which the crawler will get the latest articles.
twitter_bot_screen_name: the name of the account that will tweet the articles.
Twitter keys
- twitter_consumer_key
- twitter_consumer_secret
- twitter_access_token
- twitter_access_token_secret
telegram_bot_token: the telegram bot who's going to log messages for maintenance/debug purposes
telegram_chat_id: the channel where the bot will send messages

You just need to create a env.yml file and put those values in, like this:

dev_tag: "react"
twitter_bot_screen_name: "NameOfTheTwitterAccount"
twitter_consumer_key: "..."
twitter_consumer_secret: "..."
twitter_access_token: "..."
twitter_access_token_secret: "..."
telegram_bot_token: "..."
telegram_chat_id: "..."

It's worth noting that I used telegram here because it was simple and it probably is the…

View on GitHub

Like it?

Well, it was super fun doing this. The feeling that you get when you see the function publishing new articles on twitter is amazing. 😄

If you like it, be sure to follow the @TheReactDev on twitter!

Thank you for your time and until the next one!

Starting out on React with hooks

Juliano Rafael — Sat, 02 Mar 2019 13:12:42 +0000

Hi there.

A couple of weeks ago React officially released this new API called Hooks and you, who's been looking at React curiously for the past few months or even got to code a few components, have been wondering if now it's the time to learn more about React...

Well, if there's one thing I can assure you, is that now, more than ever, is a really good time to start building you React skills. React has been around for the last 5 years and learnt a lot from it's surroundings and past experiences and it is a rock solid library to build apps pretty much anywhere. This new API makes it even more clean and easy to compose and use logic between components.

Let's make a brief introduction to the most primitive concepts, introduce the most basic hooks and then I'll point you to some awesome resources where you can learn everything about React.

What's React?

You probably know what's React at this point, but let's just get this out of the way. React is library that deals with finding the optimal way to render your application somewhere. It's built with JavaScript and we use it primarily to build web applications, but it can be used to render pretty much everywhere nowadays, like on Android and iOS, with React Native, on TVs, on the server, on the command-line, and on and on.

How is that possible? React built the logic to find the minimal effort needed to render separated from the actual rendering primitives. This way, to use React somewhere, all we need to do is to build the rendering layer. For the web this is the react-dom library.

To create a React element, all we need to do is to import React and ReactDOM into a html file and then open a third script tag, after the two previous ones, and start creating your components, right?

<!DOCTYPE html>
<html lang="en">

<head>
  <meta charset="UTF-8">
  <meta name="viewport" content="width=device-width, initial-scale=1.0">
  <meta http-equiv="X-UA-Compatible" content="ie=edge">
  <title>React Example</title>
</head>

<body>
  <div id="root"></div>
  <script src="https://unpkg.com/react@16.8.3/umd/react.development.js"></script>
  <script src="https://unpkg.com/react-dom@16.8.3/umd/react-dom.development.js"></script>
  <script>
    // Your code is going to go here
  </script>
</body>

</html>

Well, not quite there. We are adding our root div there, which will be the place where we render our components, but first we have to create our components and then we have to actually put them into the root div that we created.

To create and element we have to do the following inside the third tag:

const App = () => React.createElement(
    'div',
    {},
    React.createElement('h1', {}, 'My Element')
)

And to render it, after the App component we add:

ReactDOM.render(React.createElement(App), document.getElementById("root"))

And now we should see the h1 element, inside a div, with the "My Element" text inside.

I know, you're like: "Seriously? All of this to render some simple html?". Just hang on with me a bit more.

We should note that everything that React renders is a component. That's another big win for React. Your app gets split into small little pieces that work together and abstract away it's internals.

We used h1 and div here, but anything that you put there, will be the output, so you can work with web components too.

We can also nest components as we please, and this is when things start to get interesting.

Lets create a Person component.

const Person = () => React.createElement(
    'div',
    {},
    [
        React.createElement('h1', {}, 'Juliano Rafael'),
        React.createElement('h2', {}, '@frontendwizard'),
        React.createElement('h2', {}, 'Front End Developer'),
    ]
)

Now, in our app we can create as many instances of our Person component as we please:

const App = () => React.createElement(
    'div',
    {},
    [
        React.createElement(Person),
        React.createElement(Person),
        React.createElement(Person),
    ]
)

Bit boring, but interesting. You should see three Juliano's on your html. That's way too much Juliano's, no one would be happy with that 😄. Our values for the Person component is hardcoded into the component. Let's change that with the most basic component feature, the props. Have you noticed the empty object we keep passing in as the second argument to React.createElement? Those are the props. They keep all the properties passed to the object. Conveniently, they are also the first argument passed to a function component. Let's change the Person component to use that.

const Person = props => React.createElement(
    'div',
    {},
    [
        React.createElement('h1', {}, props.name),
        React.createElement('h2', {}, props.twitter),
        React.createElement('h2', {}, props.job),
    ]
)

Cool, now we can get rid of those Juliano's clones and give each instance it's own identity.

const App = () => React.createElement(
    'div',
    {},
    [
        React.createElement(Person, {
            name: "Juliano Rafael",
            twitter: "@frontendwizard",
            job: "Front End Developer"
        }),
        React.createElement(Person, {
            name: "Leonardo Elias",
            twitter: "@leonardoelias_",
            job: "Front End Developer"
        }),
        React.createElement(Person, {
            name: "Marcos Eptacio",
            twitter: "@eptaccio",
            job: "JavaScript Developer"
        }),
        React.createElement(Person, {
            name: "Wallace Batista",
            twitter: "@uselessdevelop",
            job: "Front End Developer"
        }),
    ]
)

Cool, right? Now we can conquer the world and build the most complex apps! Certainly not with this syntax. While it is great that we can already abstract away code into components, this syntax is way to cumbersome and hard to read. Time to build upon this.

JSX

There's a reason no one uses React without JSX and that is because JSX improves readability by a lot. JSX let you write a HTML-like syntax that gets transpiled down to exactly what we've been doing so far. The downside is that now we need to have this transpiling process in our workflow to use this. We can do this with @babel/standalone right in the browser, but that's no good for production since it transpile the code live, and this is one more step that has to happen before your code gets processed in the browser.

The number one build tool used today on React projects is webpack. Thanks to create-react-app, the whole setup is abstracted away in react-scripts. All you need to do is:

npx create-react-app my-app
cd my-app
npm start

This will boot up a brand new application on http://localhost:3000.

Now you say to me: "Hey, how did you went from the simple html file with scripts to this complex setup with webpack that feels like magic to me?"

I hear you. Trust me, you're going to love this. All you need to know at this point is that this setup gives you a solid workflow to develop, debug and ship your app, without the need to wiring up all the webpack configs, which can be super overwhelming. This setup will transpile your JSX code down to what we've done before, with a little bit more to allow us to use some nice features from ES2015+ that are not available in all browsers. At the end, trusting the react-scripts is a safe bet and will get you a nice peace of mind.

Enough with the setup, now we can refactor our Person component to use JSX:

const Person = props => (
    <div>
        <h1>{props.name}</h1>
        <h2>{props.twitter}</h2>
        <h2>{props.job}</h2>
    </div>
)

And App can be written like this:

const App = () => (
    <div>
        <Person
            name="Juliano Rafael"
            twitter="@frontendwizard"
            job="Front End Developer"
        />
        <Person
            name="Leonardo Elias"
            twitter="@leonardoelias_"
            job="Front End Developer"
        />
        <Person
            name="Marcos Eptacio"
            twitter="@eptaccio"
            job="JavaScript Developer"
        />
        <Person
            name="Wallace Batista"
            twitter="@uselessdevelop"
            job="Front End Developer"
        />
    </div>
)

I don't know about you, but this feels way much better to me. The more you nest components, the more you see the benefits of JSX.

There are some little gotchas of JSX though and you can read all of the details of JSX in the docs here. For now, all you need to know is:

your components, other than the ones specified in HTML, MUST BE capitalized, otherwise it'll try to have it as a web component instead of a React component.
if you're going to add a class to your component, you need to use the className property, instead of class because class is a reserved word on JavaScript.
all properties with hyphen need to be prefixed with data- otherwise React won't render them down on the DOM.

I can live with that.

Splitting your components into multiple files

You probably noticed that with create-react-app you get the components split into separate files by default and being imported and exported using the ES2015 syntax.

This is possible because of the webpack setup behind the scenes. With this, you can put every component into it's own file and export it from it by using:

export default MyComponent

On another file you can import the component by using the import statement:

import MyComponent from './relative-path-to-MyComponent'

Ok, so now we can write our components in a HTML like syntax, break it down into smaller components, abstract away it's implementation, but all of it is still static. That's because props can't change inside of a component, they are immutable. We need something that we can store some state in it and dynamically change it, while letting React update the interface in response.

Lets talk about state.

State

State is a dynamic property of your component. You can change it as you wish during the life of the component and React will take care of updating the rendered component to reflect the changes on your state. Every time you change the state, React will find the fastest way to update your rendered component and take care of updating it for you. That's beautiful.

To create some state, we're going to use a Hook. Hooks are a new addition to React 16.8 and they dramatically simplify the React API and allow for brand new ways to structure and compose your components and your functionalities. It's safe to assume that they are going to be the default way we create components from now on.

We can create a state by using the useState from React and passing in the initialValue as the first parameter. This hook will return an array where the first value is the current state and the second value is a function to update the state.

const Counter = () => {
    const [count, setCount] = React.useState(0)
    const handleClick = () => setCount(count + 1)
    return (
        <div>
            <p>You clicked {count} times</p>
            <button onClick={handleClick}>Click Me!</button>
        </div>
    )
}

And this is our first truly dynamic component 🎉 🎉 🎉. This is where the real strength of React lies. It's super simple to create dynamic components.

But things can get more interesting. Only with useState we can't actually do asynchronous stuff and let's be real, the major part of the web development is talking with APIs. So, how do we do that?

Effects

Sometimes you need to do to something in response to a change. That's what we call an effect. You can trigger effects for all kinds of events on a component life, such as mount, unmount and update.

To demonstrate this concept, let's do something a bit more real world like. Let's create a component that fetches a random cat image from this public api and renders it on a page.

For effects, we have another hook, the useEffect. This hook accepts two parameters: the first is a function that is executed at some point of the component lifecycle and the second is an optional array that lists what this function depends upon. Three things can happen with this second argument:

If nothing is passed to it, React assumes that whenever anything happens, this effect needs to be run again.
If you pass an empty array, React will assume that this function only needs to be run once, after the component's first render.
If you put some things inside this array, React will run the effect every time any of the elements inside the array changes.

And there we go:

const RandomCat = () => {
  const [ready, setReady] = React.useState(false)
  const [src, setSrc] = React.useState(null)
  const [error, setError] = React.useState(null)
  React.useEffect(() => {
    fetch("https://aws.random.cat/meow")
      .then(response => response.json())
      .then(data => {
        setReady(true)
        setSrc(data.file)
      })
      .catch(error => setError(error))
  }, [])
  if (!ready) return <p>Loading...</p>
  if (error) return <p>Oops, something went wrong!</p>
  return <img src={src} alt="random cat photo" />
}

And voilá, our component makes a request to a third party api, get the image address and render it with an image tag. We can make this better by refactoring this to a custom hook.

Custom Hooks

We don't need to restrain ourselves to use only the React given hooks. We can create our own hooks that abstract away the details and expose only what matters. Lets get our hands dirty:

const useRandomCatImg = () => {
  const [ready, setReady] = React.useState(false)
  const [src, setSrc] = React.useState(null)
  const [error, setError] = React.useState(null)
  React.useEffect(() => {
    fetch("https://aws.random.cat/meow")
      .then(response => response.json())
      .then(data => {
        setReady(true)
        setSrc(data.file)
      })
      .catch(error => setError(error))
  }, [])
  return { ready, error, src }
}

const RandomCat = () => {
  const { ready, error, src } = useRandomCatImg()
  if (error) return <p>Oops, something went wrong!</p>
  if (!ready) return <p>Loading...</p>
  return <img src={src} alt="random cat photo" />
}

And the instantaneous benefit from this is that now we can use the same useRandomCatImg anywhere else we see fit.

A couple of things should be noted here:

Hooks must be called inside a function component.
It's a convention that Hooks should always start with use. That's because React assumes that you follow this and will only warn you for violations when you're following this convention. So, do follow it!

Also, this whole managing state during a request is indeed a bit verbose and awkward, but hang on because this will soon get way better with React Suspense. I'm not going to cover this right now because we're not there yet, but you should know that this is going to get even better.

Class Components

Despite Hooks being awesome, they have only been officially introduced recently and before that, all of this power of React were already here, just in a different way. Even though we'll certainly move to Hooks as standard, class components exist and they aren't going anywhere. Plus, you're likely to find them everywhere that has existed before Hooks.

You create a class component by creating a class and extending React.Component. By doing this you now have access to the lifecycle methods from the components, like componentDidMount, componentDidUpdate, componentShouldUpdate, componentWillUnmount and others. You also get the power to instantiate a state and use this.setState to change it.

Everything you can do with classes components, you can do it with hooks and vice-versa, with the exception of the componentDidCatch lifecycle method, but this is coming for hooks too.

The same RandomCat component that we did with hooks before, looks like this with classes:

class RandomCat extends React.Component {
  constructor(props) {
    super(props)
    this.state = {}
    this.fetchRandomCatImg = this.fetchRandomCatImg.bind(this)
  }

  componentDidMount() {
    this.fetchRandomCatImg()
  }

  fetchRandomCatImg() {
    fetch("https://aws.random.cat/meow")
      .then(response => response.json())
      .then(data => {
        this.setState({
          error: null,
          ready: true,
          src: data.file
        })
      })
      .catch(error => this.setState({ error }))
  }

  render() {
    if (this.state.error) return <p>Oops, something went wrong!</p>
    if (!this.state.ready) return <p>Loading...</p>
    return <img src={this.state.src} alt="random cat photo" />
  }
}

Reasonably more verbose, but it does the same thing. It's also harder to reuse this logic because fetchRandomCatImg can't be shared to be used elsewhere due to it's use of this, which makes it dependent of the component instance. There are solutions to this problem, mainly the render props and high-order component patterns, but both of them also add it's own share of issues. Hooks are just a better way to achieve logic reusability on a React application.

As usual, Dan Abramov has an awesome article explaining why hooks are so good.

Conclusion

State and effects are the bread and butter of React. It's the 20% that do 80% of things on React. The next steps on your journey now should probably be:

If you haven't been there, go to the docs. React docs are just amazing and they are currently being translated to multiple languages. If the translation to your language is not ready yet, try to contribute to it. All the repos for each version of the docs can be found here.
Learn how to use a router. I do recommend you to look into Reach Router made by Ryan Florence due to it's focus on accessibility.
Learn how to deal with forms, specially controlled components. React does have a different way to deal with form inputs and that can feel a bit awkward at the beginning. Do yourself a favor and use formik.
Learn how to test React components. Kent C. Dodds has lots of high quality content on this topic and he's also the author of react-testing-library which is an amazing tool to test your components. I can't stress enough how much testing is important. There's also this article from him that introduces the library. Check it out.
Check it out a few state management solutions. Redux is the most commonly used but it can be quite overwhelming at first and it isn't the only one out there. MobX is known for being simple. A good rule for state management is only use it when really feel like you should. A lot of the times, Context is enough to share state between distant components on the tree. You absolutely don't need to worry about it in the beginning though.
Check it out the CSS tooling on the React ecosystem. I'm super fond of CSS-in-JS libraries because it gives you a lot more power when writing styles and it fits perfectly well into React, turning your styles into components. I'm super fond of styled-components, but emotion is a solid option as well. Max Stoiber's recent article, "Why I Write CSS in JavaScript" is a great reading if you're searching for a more compelling argument in favor of CSS-in-JS.

That's more than enough for now, certainly more than I intended for this article 😄. Don't feel discouraged by the amount of links I just threw up here. Go slow and try each topic on your own time. More importantly, reach out to people and make questions. The React community is super helpful and you can find help everywhere (reddit, developers on twitter, freeCodeCamp and many other places).

At last, if you're still here, reach out in the comments below and tell me your story on how has it been your road into learning React. I'd love to hear about it. Also, hit that follow button to be notified when my next post get's published.

That's it for today. ✌️

Cover image by Caspar Camille Rubin on Unsplash

Forem: Juliano Rafael

Don't snapshot your UI components, make assertions!

The problem

Update snapshot

Tests resilience

The solution

Conclusion

Why GatsbyJS?

What is Gatsby?

What does it offers for developers?

What are the strong use cases of Gatsby?

What are the downsides?

Your opinion

Inspired by @thevuedev, I created @TheReactDev

A bot that tweets new DEV articles about Vue

Daniel Elkington ・ Mar 3 '19 ・ 6 min read

TypeScript? Nah.

Serverless

Scraping

Problems I had

Telegram

The repo

frontendwizard / TheReactDev

The function that feeds @TheReactDev twitter.

TheReactDev

Like it?

Starting out on React with hooks

What's React?

JSX

Splitting your components into multiple files

State

Effects

Custom Hooks

Class Components

Conclusion