Stay up to date with the latest news on React.
View this email in your browser

The React Newsletter

Hi <<First Name>>,
Should I useState or useReducer?

Whenever there are two things to do the same thing, people inevitably ask: "When do I use one over the other?" There are two possible reasons for having multiple ways of doing the same thing:

  1. One is the "old way" and the other is the "new (and improved) way". Typically the old way is kept around for backward compatibility reasons and the new way is the path forward for new code. For example: class components (old way) vs function components (new way).
  2. They come with different trade-offs that should be considered and therefore should be applied in situations that suit them better (sometimes meaning you'll use more than one in a given application). For example: useEffect vs useLayoutEffect or Static vs Unit vs Integration vs E2E tests or "Control Props" vs "State Reducers"

useState and useReducer fall into the second category here. So let's talk about the trade-offs.

(and no, it's not a trick question 😂).

Read more
React Form Validation With Formik And Yup
Forms are an integral part of how users interact with our websites and web applications. Validating the data the user passes through the form is a critical aspect of our jobs as web developers. However, it doesn’t have to be a pain-staking process. In this article, we’ll learn how Formik handles the state of the form data, validates the data, and handles form submission.

Read more
How to Import Browser Only Libraries Into Your Next.js Application Using next/dynamic
In this video we'll learn how to import browser only libraries into your Next.js apps. React has traditionally been a SPA framework that runs entirely in the browser so many wrappers for JavaScript libraries that are built around React rely on the browser. Next.js on the other hand treats your app as a server-side app and this can cause issues when importing certain browser or client-only libraries. Luckily, the Next.js team has a great solution for how to get around this with the next/dynamic package.

Watch video
Building a truly accessible clickable div

When developing features at Wealthfront, it is somewhat common to receive a design mock where an entire card is clickable. One example is the account card on a client’s dashboard.

The link itself is highlighted by our purple primary text, and clicking it takes you to the corresponding Wealthfront account page. In fact, clicking anywhere on the account card takes you to this page as well.

Read more
Generating TypeScript React components from SVG icons using SVGR
SVGR is a tool that converts SVG files into React components. It supports TypeScript generation. However, it only supports default exports. To generate components with named exports we need to use a custom template.

Read more
Why we decided against GraphQL for local state management

Here at OkCupid, we're pretty big fans of using GraphQL. When it comes to fetching data on any of our client platforms, the abstraction that the query language provides grants the flexibility for us to fetch precisely the data that we need in each situation.

At the end of the day, GraphQL really is just that: an abstraction. The mutation, query, and subscription types abstractly model the fundamental ways in which we interact with any data. The schema serves as a contract between some source of data and its destination, and it defines what data can be queried and how it ought to be queried. The data that an incoming query outlines would be resolved by our GraphQL server instance in most cases, but the destination of that data (in our case, let's say it's a mobile app or web app acting as a client), doesn't really need to know about the source or resolution strategy of the data in question.

This is really nice, because it means that the data can come from anywhere that the GraphQL server has access to. Maybe we want to resolve our data using something in the filesystem, or maybe a local database, or maybe a remote one. Perhaps we can call some other server exposed to us, via RPC or REST or any protocol, really. Maybe our data is currently in memory somewhere and that's technically fine as well! That indifference of our datasource(s) is what allows this model, and the architecture of a data graph to be so scalable (Mandi Wise has a great video that demonstrates this while covering the concept of a federated graph).

Regardless of the source of the data, the client implementation doesn't really need to change at all, and that's crucially important to understanding the notion of using GraphQL for local state management. Imagine your application's local state: it really is just another source of data, after all, isn't it? So, then the question is, what is stopping us from leveraging the abstraction provided to us by this query language paradigm to manage this data as well?

Read more
React video courses
Because I need to pay my bills 😉
Copyright © 2020 ABL - The Problem Solver, All rights reserved.

unsubscribe from this list    update subscription preferences 

Email Marketing Powered by Mailchimp