This podcast episode was a great introduction to React server components. A balanced take—whether you're drinking frontend koolaid or push to backend all the things.

(Mostly Technical has been great lately, Justin Jackson compiled a hilarious Mostly Technical x Seinfeld supercut.)

Frontend frameworks often use the mental modal that a component (or entire UI) is the result of running state through a pure function. Dan Abromov shares his thoughts on the current state of React with server components.

UI = f(data)(state)

Here's how I interpret it: in the mental model we're used to, a component is a pure function that returns UI based on its props. In this case, a Greeter is rendered on the client.

function Greeter(props) {
  return <p>Hello, {props.name}!</p>;
}

Say we have a server component that know who needs to be greeted before the code hits the client. In that case, the name will come from data available on the server.

function Greeter(data) {
  return function () {
    return <p>Hello, {data.name}!</p>;
  }
}

The outer function is executed on the server, the inner on the client.

The true power lies in mixing and matching the paradigms. Say you want to read a translation string on the server, and greet a name on the client.

function Greeter(data) {
  return function (props) {
    return <p>{data.translations.hello}, {props.name}!</p>;
  }
}

How to set up React in Vite with Laravel.

Read more

Dan Abramov shared a short post on some key principles the React team sticks to. Some solid general advice here, it's not explicitly related to React.

Absorb the Complexity

Making React internals simple is not a goal. We are willing to make React internals complex if that complexity lets product developers keep their code easier to understand and modify.

Hacks, Then Idioms

We need to allow hacks using escape hatches, and observe which hacks people put in practice. Our job is to eventually provide an idiomatic solution for hacks that exist in the name of better user experience. Sometimes, a solution might take years. We prefer a flexible hack to entrenching a poor idiom.

These two stood out because they're the opposite of how I generally need to think when building applications (although they make perfect sense in the context of something like a lower level framework). Either way, lots of food for thought in here.

Read all principles on overreacted.io.

I built a small React component that uses the Google Places API to autocomplete an address in a project I'm working on, and extracted the prediction fetching to a custom useAddressPredictions hook. It's a nice example of a custom React hook composed of different primisite hooks, so I decided to pen write my thought process while building it.

Read more

React follows semantic versioning, but with a twist. From their versioning policy:

When releasing critical bug fixes, we make a patch release by changing the z number (ex: 15.6.2 to 15.6.3).

When releasing new features or non-critical fixes, we make a minor release by changing the y number (ex: 15.6.2 to 15.7.0).

When releasing breaking changes, we make a major release by changing the x number (ex: 15.6.2 to 16.0.0).

The twist is subtle: non-critical bugfixes are released as minor releases.

I've often wondered whether three digits really is necessary for versioning. As a package maintainer, deciding between minor and patch is often a gray area.

Two digits would suffice: breaking changes and non-breaking changes. Feature or bugfix doesn't really matter from a technical point of view: upgrading can either break things, or can't.

React reserves the patch number for critical bugfixes, which I believe is a necessary escape hatch in a two digit system. But I like I how they default to simply bumping minor versions.

React components have always relied on lifecycle methods for side effects. While lifecycle methods get the job done, they're often overly verbose and have large margins for error.

It's easy to forget to "clean up" a side effect when a component unmounts, or update the side effect when props change. As Dan Abramov preaches: Don't stop the data flow.

React recently introduced a new way to deal with side effects: the useEffect hook. Translating lifecycle methods to useEffect calls can be confusing at first. It's confusing because we shouldn't be translating imperative lifecycle methods to declarative useEffect calls in the first place.

Read more

For the past three years, I've been using both React and Vue in different projects, ranging from smaller websites to large scale apps.

Last month I wrote a post about why I prefer React over Vue. Shortly after I joined Adam Wathan on Full Stack Radio to talk about React from a Vue developer's perspective.

We covered a lot of ground on the podcast, but most things we talked about could benefit from some code snippets to illustrate their similaraties and differences.

This post is a succinct rundown of most Vue features, and how I would write them with React in 2019 with hooks.

Read more

I had the honor to be a guest on Full Stack Radio with Adam Wathan.

We talked about why I prefer React over Vue — which I wrote about two weeks ago — and how to implement some patterns that Vue provides out of the box but aren't explicitly available in React. Examples include computed properties, events and slots.

Adam's quote:

In this episode, Adam talks to Sebastian De Deyne about learning React from the perspective of a Vue developer, and how to translate all of the Vue features you're already comfortable with to React code.

Tune in on fullstackradio.com or on your favorite podcatcher!

Shawn Wang (@swyx) wrote about how React hooks work internally. The article is a deep dive into JavaScript closures, and builds up to a 28-line React clone with support for the useEffect and useState hooks.

In this article, we reintroduce closures by building a tiny clone of React Hooks. This will serve two purposes – to demonstrate the effective use of closures, and to show how you can build a Hooks clone in just 29 lines of readable JS. Finally, we arrive at how Custom Hooks naturally arise.

Understanding how React deals with hooks internally isn't a required to use them, but it's interesting material nonetheless!

You can read the full article on the Netlify blog.

Vue is the default JavaScript framework for Laravel apps. Being part of the Laravel community, I often get the question why I prefer React, so I've decided to write down a few standout reasons.

Read more