DEV Community: João Vitor

Web Frameworks: The Future

João Vitor — Tue, 21 Jan 2025 23:00:33 +0000

I was watching Ryan Carniato's stream the other day when he said something like "When I imagine building a website in 10 years, React will not be the thing I'll be using...", and that got me thinking "How would the next framework look like?".

So I started playing around with some ideas and decided to write them down.

Syntax

Let's start with a hot one: the syntax.

If you have experience writing HTML, making a real website by sending HTML through the server, playing around CodePen, or tweaking your Tumblr page with some fancy cursor styles (that's how I got into coding), here's how you would write code:

<!DOCTYPE html>
<html>
  <!-- ... -->
    <body>
      <h1>Counter</h1>
      <p>Count is 0</p>
      <button onclick="increment()">Increment</button>

      <style>
        /* Inside the style tag is where you make everything look pretty */
        h1 {
          color: red;
          font-family: 'Comic Sans MS', cursive;
        }
      </style>

      <script>
        // And here is where you make things work
        const p = document.querySelector('p');
        let count = 0;

        function increment() {
          count++;
          p.textContent = `Count is ${count}`;
        }
      </script>
   </body>
</html>

HTML based

I like the idea behind Svelte to enhance HTML and if you compare it to the HTML code you'll see that things look pretty similar:

<!-- Component.svelte -->
<script>
  let count = $state(0);

  function increment() {
    count++;
  }
</script>

<h1>Counter</h1>
<p>Count is {count}</p>
<button onclick={increment}>Increment</button>

<style>
  h1 {
    color: red;
    font-family: 'Comic Sans MS', cursive;
  }
</style>

Everything stays where it's supposed to be, markup in the HTML, CSS in the <style> tag, and JavaScript in the <script> tag.

Writing it feels like writing modern HTML with components.

But if you're trying to build a website you'll need more than that. We need servers!

JSX

When you navigate to any website, the browser makes a request to the computer that's hosting your website and expects it to respond with assets (HTML, CSS, and JavaScript) to render the page for you.

The server is where developers connect with databases to fetch or mutate data, check the user’s authentication, permissions, etc., and then return things to the browser.

This is how a web server might look like in reality:

app.get('/', async (req, res) => {
  const user = await db.getUser(req.body);

  if (!user.isAuthenticated) return res.status(401);

  return res.html`
    <html lang="en">
      <head><title>My website</title></head>
      <body>
        <h1>Hello ${user.name}</h1>
      </body>
    </html>
  `;
});

When I see it like that, it makes more sense in my head to write pages with JSX.

It looks a lot like a React component!

But now we are at the other side of the fence, where everything is on the server. We still want JavaScript on the client for all sorts of good stuff, like optimistic updates, client-side routing, etc.

I choose both

Let's take a closer look at the API endpoint above and identify which code runs where:

app.get('/', async (req, res) => {
  // Up here we are on the server
  // We can connect to the database, authenticate the user, etc.

  return res.html`
    <html>
      <!-- Down here, we're on the client -->
      <!-- We can send HTML, CSS, and JavaScript for it to render the page -->
      <style />
      <div />
      <script />
    </html>
  `;
});

As you can see, we can use the <script> tag to send JavaScript code to the client. And the structure of the returned HTML string looks like the code we wrote for the Svelte component!

Here's what I'm thinking:

export async function ProfilePage() {
  // Code here only runs on the server
  const user = await getSession();

  if (!user) throw redirect('/login');

  return `
    <>
      <div>
        <img src="${user.profileUrl}" alt="${user.name}" />
        <h1>Hi ${user.name}</h1>
      </div>
      <style>
        h1 {
          font-family: 'Comic Sans MS', cursive;
        }
      </style>
    </>
  `;
}

Think of it as if React was rendering a Svelte component.

But of course, we don't want to write in template strings anymore, so we'll use JSX!

export async function ProfilePage() {
  // Code here only runs on the server
  const user = await getSession();

  if (!user) throw redirect('/login');

  return (
    <>
      <div>
        <img src={user.profileUrl} alt={user.name} />
        <h1>Hi {user.name}</h1>
      </div>
      <style>
        h1 {
          font-family: 'Comic Sans MS', cursive;
        }
      </style>
    </>
  );
}

Reactivity

Since we are talking about a framework for the next decade, I imagine that a lightweight and fast reactivity system will be a must-have.

Signals to the rescue

Today, the only implementation that meets those requirements is Signals.

Svelte runes are my favorite implementation so far, so to illustrate where things would go:

export function Counter() {
  // Code up here runs on the server

  return (
    // Code down here runs on the browser
    <>
      <script>
        let count = $state(0);

        $effect(() => console.log(count));

        function increment() {
          count++;
        }
      </script>
      <div>
        <h1>Count is {count}</h1>
        <button onclick={increment}>Increment</button>
      </div>
      <style>
        h1 {
          font-family: 'Comic Sans MS', cursive;
        }
      </style>
    </>
  )
}

Our code is looking awesome in my opinion, but there are a couple more pieces to this puzzle!

Data fetching

For the past few years, I've been experimenting with different React frameworks and the one I enjoyed the most was Remix v2.

Although it didn't have the same features as Next.js, such as caching and middleware, their implementation was closer to how the browser works and easier to understand.

Loaders and Actions

// routes/_index.tsx
export const loader = async () => {
  return await db.getCount();
};

export const action = async (req) => {
  let data = await req.formData();
  await db.updateCount(+data.get('count'));
  return null;
};

export default function Root() {
  let initialValue = useLoaderData();
  let [count, setCount] = useState(initialValue);

  function update(event) {
    setCount(event.target.value);
  }

  return (
    <form method="POST">
      <p>Count is {count}</p>
      <input type="range" name="count" value={count} onChange={update} />
      <button>Save</button>
    </form>
  );
}

When the browser makes a request for the route /, Remix will run the loader function to get the initial data and send back the rendered JSX to the browser.

React then hydrates that component, binding event listeners with JavaScript to add interactivity, such as the onChange and the update function.

When the user submits the form, the browser makes a “POST” request to that same route / which Remix will run the action function assigned to that module, invalidating loaders and keeping everything up-to-date.

It behaves similarly to how the browser works with progressive enhancement, AND you can mix and match server and client code on the same file!

React Server Components

Another approach that came into life was React Server Components.

It uses JavaScript directives to tell frameworks which code will execute on the server and which will run on the client.

The main difference is that it sends less JavaScript to the client when compared to loaders and actions.

// page.jsx
import { revalidatePath } from 'next';

async function updateCount(formData) {
  'use server';
  await db.updateCount(+formData.get('count'));
  revalidatePath('/');
}

export default async function Page() {
  let count = await db.getCount();

  return <Counter initialValue={count} updateAction={updateCount} />;
}

// counter.jsx
'use client';

export function Counter({ initialValue, updateAction }) {
  let [count, setCount] = useState(initialValue);

  function update(event) {
    setCount(event.target.value);
  }

  return (
    <form action={updateCount}>
      <p>Count is {count}</p>
      <input type="range" name="count" value={count} onChange={update} />
      <button>Save</button>
    </form>
  );
}

Notice that with RSCs, I had to move the client-side logic to another file marked as "use client" and mark the updateCount() function with "use server" directive.

Functions marked with "use server" are called Server Functions. They are exposed to the network as a Remote Procedure Call (RPC).

I pick none

For my personal preference, I like the ergonomics that RSC allows, but I wish we didn't have to write directives or even separate client and server code on different files.

What would it look like to fetch and mutate data from our example of React + Svelte code?

Well, we already know where we can run code on the server!

export async function FullStack() {
  // Fetch data up here
  let initialValue = await db.getCount();

  async function updateCount(formData: FormData) {
    let count = +formData.get('count');
    await db.updateCount(count);
  }

  return (
    <>
      <script>
        let count = $state(initialValue);

        $effect(() => console.log(count));

        function update(e) {
          count = e.target.value;
        }
      </script>

      <form action={updateCount}>
        <p>Count is {count}</p>
        <input type="range" name="count" value={count} oninput={update} />
        <button>Save</button>
      </form>

      <style>
        p {
          font-family: 'Comic Sans MS', cursive;
        }
      </style>
    </>
  )
}

Now you're probably wondering if this guy is insane or if he's up to something.

How would the framework know that updateCount needs to be transformed into an RPC call, like the Server Function?

I thought that looking at the <form action={} /> would've been enough but maybe not, and that's where the last piece comes in place.

The language

When thinking about how to make the updateCount function special without using directives, I remembered something about React, the static type checker for JavaScript used by Meta, Flow, and it gave me some ideas.

In 2024, Flow introduced a Component syntax feature to help developers write simpler React code. They added two keywords to the language component and hook to create components and hooks with some pre-configured behavior.

If we mark an async function with an action keyword we would know that it needs to be transformed into an RPC call:

export async component Counter() {
  let initialValue = await db.getCount();

  async action updateCount(formData: FormData) {
    let count = +formData.get('count');
    await db.updateCount(count);
  }

  return (
    <>
      <script>
        let count = $state(initialValue);

        function update(e) {
          count = e.target.value;
        }
      </script>

      <form action={updateCount}>
        <p>Count is {count}</p>
        <input type="range" name="count" value={count} oninput={update} />
        <button>Save</button>
      </form>

      <style>
        p {
          font-family: 'Comic Sans MS', cursive;
        }
      </style>
    </>
  )
}

🤯 Wow!! Now I think we've done it! We just envisioned the future of the web 🥳

We're combining all the benefits of Svelte and React libraries. For example:

When compared to React

Faster and lightweight reactivity with Signals
Smaller JS footprint on the client with compilers
Scoped CSS and no CSS-in-JS syntax needed

When compared to Svelte

Named exports export function MyComponent() {}
Better TypeScript support with no type generation
Better template syntax with Array.map() in favor of {#each}{/each} and others (arguably)

Conclusion

Please don't take this post seriously, I was playing around with my thoughts 😅

But it's always best to take a step back, consider everything, and ask questions like "How would I like to write this code?"

What about you? Have you considered what frameworks would look like in ten years? Please write it down!

*Cover image by Yolanda Suen on Unsplash.

Learning PHP in 2024

João Vitor — Wed, 20 Mar 2024 17:28:31 +0000

A quick introduction to PHP development in 2024, with useful links and resources.

Intro

I was recently asked to do an interview code challenge using pure PHP, but the content I found online was outdated and didn't talk about modern PHP development.

In this post, I'll try to share what I've learned about PHP so far.

Before we begin

Coming from a React and Next.js background I never really had the chance to understand how things work in web browsers.

It was not until I started working with Remix, that I realized how great your code can be when you build on top of web standards.

Using PHP is closer to Remix than React SPA, without the JS benefits.

But I'm not here to talk about Remix (although if you're into React, you should try it!).

Here are some of the things I found when coding this challenge.

Outdated resources

Since PHP has been around for decades, most of the information I've found online was not up-to-date with its recent versions and modern developer tools, so it took me a while to find good resources.

I'll link most of them at the end of this post, but I want to shout out to Laracasts and Jeffrey Way for their amazing PHP for Beginners series on YouTube.

Getting started

If you have Homebrew installed, install php with

brew install php

Use the built-in server

PHP now comes with a built-in server that you can use to serve your application. No need for Nginx or Apache for local development.

For example:

php -S localhost:8888

This will serve your current directory on http://localhost:8888

No local database

Use Docker as an alternative to installing a database locally.

Check my docker compose file here for a good starting point. It will start a MySQL container on port 3306.

Notice the initdb.sql file. Copying it over to the docker-entrypoint-initdb.d/ folder will run the SQL file once you run docker-compose up -d.

This is useful for creating tables and seeding the database.

The connection string will look mostly like this:

"mysql:host=127.0.0.1;port=3306;dbname=myapp;user=root;password=my-secret-pw;charset=utf8mb4"

Use host 127.0.0.1 instead of localhost, to connect with TCP instead of UNIX socket, otherwise it will throw a PDOException [2002].

Using PDO

PDO (PHP Data Objects) is a consistent interface for accessing databases in PHP.

It makes it possible to swap MySQL for any other available driver, without changing how you interact with your database.
It is not an ORM nor a Query Builder.

Folder structure

The php-pds/skeleton repository is a great document to learn how to structure your code in PHP, but it doesn't show how to organize your code inside the src/ folder.

I recommend starting a basic Laravel project to see how they structure Routes, HTTP Handlers, Authentication, etc.

Types

PHP is by default a dynamically typed language, but you can ensure strict types per file with the following:

<?php

define(strict_types=1);

Strict type support was introduced in PHP 7, making it easier for developers to catch bugs in code that pass the wrong types of values to strict functions.

Composer

Composer is a dependency manager for PHP, much like Node's npm.
You can install dependencies with composer require and run scripts with composer <script>.

It installs dependencies to a vendor/ folder, which you should include in your .gitingore file.

Templating

PHP is a templating language but doesn't have the best ergonomics.
Take this loop for example:

<ul>
  <?php foreach($users as $user): ?>
    <!-- `echo` prints the variable to HTML -->
    <!-- `htmlspecialchars` secures against XSS attacks -->
    <li><?php echo htmlspecialchars($user['name']) ?></li>
  <?php endforeach; ?>
</ul>

That's where templating libraries come to the rescue.

Templating libraries

There are two types of templating libs to choose from:

Native (Plates, Aura.View)
Compiled (Twig, Latte, Smarty)

Native libraries are easier to learn because they use PHP syntax and run on .php files, so your code gets syntax highlighting.

Compiled libraries have somewhat different syntax, but less code to write, and automatic HTML escaping.

If you use Laravel, the default templating library is Blade but there are options to run React, Vue, and Svelte code too!

Check the Laravel frontend docs to learn all the available options.

Laravel

If you don't need to use pure PHP like I had to, I highly recommend you try Laravel.

Laravel is an amazing web framework with everything you need to build an enterprise-ready application.

VSCode integration

The PHP Intelephense extension has many features to ease the developer experience in PHP.

It also has a code formatter, but if you want more customization, check out Laravel Pint.

composer require laravel/pint --dev

Debugging

The PHP Debug extension adds support for debugging with Xdebug on VSCode.

Follow its instructions to install Xdebug and create the .vscode/launch.json file.

It's also useful to install the "Xdebug Helper" browser extension.

Resources

These are a MUST if you're learning PHP in 2024:

State Management with React

João Vitor — Wed, 07 Sep 2022 14:42:31 +0000

TL;DR

This guide is a compilation of many YouTube videos and articles I watched and read about State management with ReactJS.

State management is very important in React applications because our projects are built around our choices on how to handle them.

Application State can be divided into UI State and Server State (cache). Those are very different from each other; therefore, we shouldn't use the same tools and techniques to handle each one.

Using a Server State management library to handle queries and mutations like React Query or SWR will eliminate most of the complexity in your code, leaving just a few UI states, like open and close modals, to manage with the built-in hooks from React and other techniques.

State Management with React

There are various categories of state, but every type of state can fall into one of two buckets:

Server Cache - State that's actually stored on the server and stored in the client for quick access (like user data).

UI State - State that's only useful in the UI for controlling the interactive parts of our app (like modal isOpen state).

We make a mistake when we combine the two. Server cache has inherently different problems from the UI state and needs to be managed differently. If you embrace that what you have is not actually a state but is instead a cache of states, then you can start managing it correctly.
Kent C. Dodds, application state management with React.

UI State Management

React is a UI State Management library, and the best approach to handle UI state is using the built-in hook useState.

1. useState (recommended)

Here's a Counter example to demonstrate some options for handling UI state using React.

function Counter() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)

  return <button onClick={increment}>{count}</button>
}

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

Shareability

This is a common issue developers face when building React applications. Sharing the state between components is not always easy because components are often too complex.

But let's say your Product Manager wants you to display the current counter value to the user.

function CountDisplay() {
  // Where do I get the {count} value?
  return <p>The current counter value is {count}</p>
}

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

There's no need for any state management library at this point, we can just share the state between the components via props by lifting the state to a common parent of Counter and CountDisplay (in our case, it's the App component).

Lifting state

This might seem a little too basic but in the real world is hard to identify these opportunities because our components aren't always as simple as this one.

Here we're moving the state up from the Counter component to the App component and sharing it via props.

function CountDisplay({ count }) {
  return <p>The current counter count is **{count}**</p>
}

function Counter({ count, onIncrement }) {
  return <button onClick={onIncrement}>**{count}**</button>
}

function App() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)

  return (
    <div>
      <CountDisplay />
      <Counter count={count} onIncrement={increment} />
    </div>
  )
}

If you want to know more about where to colocate your state, "Thinking in React" is a good place to start.

Prop Drilling

Lifting state is a nice technique to share state with components but when you have to share something from a very high component in the component tree, using that technique will introduce something called Prop Drilling.

For example, imagine that our CountDisplay component got too complex for whatever reason, and we decided to move the count message to a child component CountMessage.

function CountMessage({ count }) {
  return <p>The current counter count is {count}</p>
}

function CountDisplay({ count }) {
  // ...very complex logic
  return <div><CountMessage count={count} /></div>
}

function App() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)

  return (
    <div>
      <CountDisplay />
      <Counter count={count} onIncrement={increment} />
    </div>
  )
}

Prop drilling isn't necessarily bad, but using the Context API to solve this is not recommended.

Instead, we can leverage component compositions to avoid this issue.

Component Composition

Here's an example that demonstrates how we can avoid prop drilling by using composition:

function CountMessage({ count }) {
  return <p>The current counter count is {count}</p>
}

function CountDisplay({ message }) {
  // ...very complex logic
  return <div>{message}</div>
}

function App() {
  const [count, setCount] = React.useState(0)
  const increment = () => setCount(c => c + 1)

  return (
    <div>
      <CountDisplay message={<CountMessage count={count} />} />
      <Counter count={count} onIncrement={increment} />
    </div>
  )
}

Passing the CountMessage component as property allows us to share the count state just one level down the component tree and remove prop drilling.

Michael Jackson, the co-founder of remix_run, has a wonderful youtube video about Using Composition in React to Avoid "Prop Drilling".

@mjackson:
Unpopular opinion: All that junk you're putting in React context should just be props. Legit context uses are rare, mostly for library code, not your app.

https://twitter.com/mjackson/status/1195431511417208834

2. useContext (not so much recommended)

Before You Use Context

Context is primarily used when some data needs to be accessible by many components at different nesting levels. Apply it sparingly because it makes component reuse more difficult.

If you only want to avoid passing some props through many levels, the component composition is often a simpler solution than context.

https://reactjs.org/docs/context.html#before-you-use-context

Why is the Context API not so good?

The Context API is very powerful, but sometimes we use it for the wrong use cases.

When using it, we need to keep in mind a few things:

Consumers are bound to their providers. This means you can't reuse consumers (Components that access the Context value) where the provider is unavailable.
When the provider's value changes, all its consumers will re-render. That can lead to unintended performance issues.
Use it when your provider value doesn't change too often, and you don't mind your consumers re-rendering when they do.

3. Other solutions to UI state management

If the React useState hook is not enough to handle the UI state in your application, we need to know why it wasn't enough and then start looking at different solutions to deal with that use case.

Jotai and Zustand are good options nowadays, but they solve different problems.

When to use which:

If you need a replacement for useState+useContext, Jotai fits well.

If you want to update the state outside React, Zustand works better.

If code splitting is important, Jotai should perform well.

If you prefer Redux dev tools, Zustand is good to go.

If you want to make use of Suspense, Jotai is the one.

https://github.com/pmndrs/jotai/issues/13

Recoil is an alternative to Jotai.

If you want to know more, listen to Theo talk about the difference between Jotai and Zustand and how those alternatives differ from Redux.

Server State Management

Some libraries handle Server states very well and provide you with loading states, query and mutation helpers, optimistic updates with rollbacks and so much more:

React Query;
SWR;
Apollo Client, only for those using GraphQL;

I haven't used those three enough to tell you which one is better, but here are my considerations about React Query and SWR:

React Query

Library with awesome utilities for data fetching, mutation, optimistic updates, and more.
Built-in developer tools
Needs a Cache Provider
More people using it, which means more examples on StackOverflow

Basic Example

const queryClient = new QueryClient()

function Component() {
  const query = useQuery(['todos'], getTodos);

  return (
    // needs a Cache Provider
    <QueryClientProvider client={queryClient}>
      <TodoList posts={query.data} />
    </QueryClientProvider>
  )
}

function AddTodo() {
  const mutation = useMutation(newTodo => axios.post('/todos', newTodo), {
    onSuccess: () => {
      // needs explicit invalidation
      queryClient.invalidateQueries(['todos']);
    }
  });

  return (
    <button
      onClick={() => {
        mutation.mutate({ id: new Date(), title: 'Do Laundry' })
      }}
    >
      Create Todo
    </button>
  );
}

SWR

Lightweight library (9.9kB minified over 43.1kB minified from react-query) with awesome utilities for data fetching, mutation, optimistic updates, and more.
Developer tools with external library
It doesn't need a Cache Provider
IMO it has a more straightforward implementation

Basic Example

function Component() {
  const query = useSWR('todos', getTodos);

  return (
    // no Cache Provider or query client
    <TodoList posts={query.data} />
  )
}

function AddTodo() {
  const { mutate } = useSWRConfig();
  // Automatically invalidates queries by key
  const addTodo = (newTodo) => mutate('todos', () => {
    axios.post('/todos', newTodo);
  });

  return (
    <button
      onClick={() => {
        addTodo({ id: new Date(), title: 'Do Laundry' })
      }}
    >
      Create Todo
    </button>
  );
}

Conclusion

If we combine a Server State management library with the techniques mentioned in this article to manage UI State, we can elimate the need to handle server loading states ourselves, when fetching and mutating. Our React projects will become easier to maintain, implement new features, and test them.

How to actually use ESLint + Prettier

João Vitor — Mon, 01 Aug 2022 14:38:00 +0000

In this article, you'll learn how to set up an excellent linting solution with ESLint and Prettier in your project.

Issue

Using Prettier as an ESLint rule has its downsides:

You end up with many red squiggly lines in your editor, which gets annoying. Prettier is supposed to make you forget about formatting — and not be in your face about it!

https://stackoverflow.com/questions/63419399/red-squiggly-lines-in-vs-code

They are slower than running Prettier directly.

They're yet one layer of indirection where things may break.

https://prettier.io/docs/en/integrating-with-linters.html#notes

Prettier takes care of your styling for you.

How should I use it then?

Setting up ESLint

First, install ESLint

npm install eslint --save-dev

Then run the configuration script:

npm init @eslint/config

Now let's configure it:

How would you like to use ESLint?
> To check syntax and find problems

What type of modules does your project use?
> Choose what is best for you (i.e. `esm`)

Which framework does your project use?
> Choose your framework (i.e. `react`)

Does your project use TypeScript?
> If it does not, you probably should.

Where does your code run?
> Choose `Browser` if you are using Client-Side, `Node` for Server-Side, or both if you are using something like Next.js or Remix

What format do you want your config file to be in?
> Choose what is best for you. I prefer JSON as it gives you IntelliSense.

Would you like to install them now?
> Yes

Which package manager do you want to use?
> Choose your package manager (i.e. `yarn`)

Setting up Prettier

First, install Prettier

npm install --save-dev --save-exact prettier

Then, create your Prettier configuration file

echo {}> .prettierrc.json

You can configure it however you like using the available options here.

Integrating Prettier with ESLint

To integrate Prettier with ESLint, we need to install the eslint-config-prettier dependency:

npm install --save-dev eslint-config-prettier

Then you need to add "prettier" to your .eslintrc.* file.

{
  "extends": [
    "eslint:recommended",
+   "prettier"
  ]
}

Editor Integration

I'm just going to cover the VSCode integration, but you can find more about editor integrations for both tools

Visual Studio Code extensions

React Integration with ESLint

If you followed the ESLint configuration script and chose React as your framework, this is already set up.

But, if you are using the new JSX transform from React 17, this is very useful:

{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
+   "plugin:react/jsx-runtime",
    "prettier"
  ]
}

Nice-to-have ESLint plugins

eslint-plugin-react-hooks

Installation,

npm install eslint-plugin-react-hooks --save-dev

Configuration,

{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:react/jsx-runtime",
+   "plugin:react-hooks/recommended"
    "prettier"
  ]
}

eslint-plugin-jsx-a11y

Installation,

npm install eslint-plugin-jsx-a11y --save-dev

Configuration,

{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended",
    "plugin:react/jsx-runtime",
+   "plugin:jsx-a11y/recommended"
    "prettier"
  ]
}

Conclusion

And there you have it. An excellent and clean ESLint + Prettier integration!

Cover image by [James Harrison](https://unsplash.com/photos/vpOeXr5wmR4)