UI as an afterthought

In 2020, what is "frontend" 🤨

How React Query gives you almost everything you thought you needed GraphQL for

Wormhole state management

Todo el software está roto

What is the Value of Browser Diversity?

Margins and Composability in CSS

Nailing Your First (Info-Product) Launch

Defining Component APIs in React

The Modern Front-End Design System Stack

---
tags: draft
---
# Specialities for Frontend Developers

- Infrastructure: setup webpack, Babel, Jest and other tools
- UI: html and css 
- Engineer: Logic
- Animators
- A11Y


Infrastructure: setup webpack, Babel, Jest and other tools
UI: html and css 
Engi...

Specialities for Frontend Developers

---
tags: ui, frontend
---
# The States of the UI

Let's say you are in charge of building the UI of Twitter, how many states do you think that UI could be in? One? Two? Five? Ten?

Usually, we identify at least one state, the **Ideal State**, this is what most users see most of the time, in Twitter it's when you have a list of tweets with their authors and the avatar of each one, and the media included in the tweets (images, links, video, audios, etc.).

Most commonly the next state we tend to identify is the **Loading State**, this is when our application is loading the data or the code (when using code splitting).

If you are lucky enough you have also identified the **Loading Error State** which mean our app can handle a case when something failed to load, this could happen if the user is offline or the server returned an error (4xx or 5xx).

The vast majority of the products stop designing states at this point, then you start the development and realize you need another state, because what happens if the user had no tweets? You need an **Empty Data State** too to show something nice when there are no content, maybe to invite the user to create content.

If our Twitter app has a way to search for a tweet we may found a case where there are no results, this means another state, what we need more is an **Empty Results State** to represent how should the UI look like when there is no content because we couldn't find anything.

Let's continue developing the product, while you are on it you realize you need another state again, because what happens if part of the data has already loaded? Are you going to wait until everything is ready or are you going to start rendering part of the UI? Implementing a **Partially Loaded State** is the best user experience, because why not show the data you already have while you continue fetching more data? As an example once you have a Tweet you can render it while you continue fetching the replies of that tweet (Twitter does this).

Then you continue building your product again, just to ask yourself what happens if the user tweet a short message? Or a long one? Or another with only of emojis? And what about non ASCII characters like Kanji's or accent marks? You need to start thinking in a **Weird Data State**, think all the possible edge cases and design for it, as an example Spanish sentences requiere higher line heights due the accents.

Ok, let's go back to building the product, we are building the form to submit a tweet, then your API returns an error, or the user forgot the write the message, or is offline, what should happen in that case? You need yet another state, I call this the **User Error State**, this is how to show validation error, network errors or API errors, basically error generated after the action of a user, which are usually different than Loading Error State because are limited to an small area and not the whole UI.

The form is working. The user can create the tweet and we show something if an error happens, but the API is not immediate, it will take at least a few milliseconds to confirm the tweet was sent, what should we do meanwhile? You have two options, the ideal one is to implement an Optimistic UI where the UI it updated before the API process the request and it rollback the changes when an error occurs, the other option is to show a **User Action Loading State**, this usually is done showing a spinner or another loading indicator and disable the form until the API returns a response (to avoid duplicated request if it takes too long).

If we go for the optimistic UI we could also have a **Pending Optimistic UI State**, this is something apps like Slack do, they show your message immediately in the chat but with a disabled color (gray-ish) so you know the message has not been sent yet, once the API confirms the success the message change to the normal state.

Ok, we have almost everything, the user load the data, can tweet, can see errors and loading states, let say the user leave the app open for a while without being really using it, what should happen when our app recovers the focus? Because a lot of time has passed we may want to revalidate our Server-State with the API to get the latest tweets, but we should show somehow that we are doing that so the user can expect it, this means yet another UI state! We now need a **Revalidating State**, we could make as iOS and show a little spinner somewhere along the old data to while we finish the revalidation, Twitter load it in background and let you know there is more data, GitHub Mobile use the iOS way and show the spinner and replace the data after it loads.

And with all of this we are finally ready to ship our product, we end up with up to 11 different states our UI can be in, a great designer think about all of them since the beginning, most designers will probably think and 4~5 of them and let the developer figure out the rest or manually ask the designer to create them, a great developer will remember the designers they need to think all of this states.

The final list of states is:

- Ideal State
- Loading State
- Loading Error State
- Empty Data State
- Empty Results State
- Partially Loaded State
- Weird Data State
- User Error State
- User Action Loading State
- Pending Optimistic UI State
- Revalidating State

Let's say you are in charge of building the UI of Twitter, how many states do you think that UI ...

The States of the UI

---
title: What I Use
path: uses
tags: setup, ama, uses
lang: en
---

# What I Use

This is my current development setup.

### Tech Stack

- [TypeScript](https://www.typescriptlang.org/) as my main programming language.
- [React.js](https://reactjs.org) for UI creation.
- [Tailwind](https://tailwindcss.com/) for styling.
- [SWR](https://swr.now.sh/) for remote data-fetching.
- [Next.js](https://nextjs.org/) as my framework.
- [Jest](https://jestjs.io/) for unit testing.
- [React Testing Library](https://testing-library.com/react) for React testing.
- [Cypress](https://www.cypress.io/) for integration and E2E testing.
- [Vercel](https://vercel.com/) as my deployment platform.
- [GitHub Action](https://github.com/features/actions) for continuous integration, delivery and deployment pipelines.

### Tools

- [Safari](https://www.apple.com/safari/) as my main browser.
- [Sizzy](https://sizzy.co) as my development browser.
- [Hyper](https://hyper.is/) as my terminal, outside VSCode.
- [GitHub](https://github.com) for my code repositories.
- [GitHub Desktop](https://desktop.github.com) to use Git with a GUI instead of via CLI.
- [GitHub Mobile](https://github.com/mobile) to check GitHub on my phone.

### Editor

I use [VSCode](https://code.visualstudio.com) as my only IDE/code editor.

#### Theme

I use [GitHub Theme](https://marketplace.visualstudio.com/items?itemName=GitHub.github-vscode-theme), I enabled VSCode to switch between light and dark versions of this theme together with the system preferences

#### Plugins

- [Atom Keymap](https://marketplace.visualstudio.com/items?itemName=ms-vscode.atom-keybindings), this change the key bindings (shortcuts) to be the same as the Atom editor, I used this editor in the past which has the same shortcuts as Sublime Text and I prefer their shortcuts.
- [Auto Close Tag](https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-close-tag), this automatically add the matching close tag of an HTML/XML/JSX tag.
- [Auto Rename Tag](https://marketplace.visualstudio.com/items?itemName=formulahendry.auto-rename-tag), this let me change the name of an HTML/XML/JSX tag and it will change the closing tag automatically for me.
- [Code Spell Checker](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker), a basic spellchecker with English and [Spanish](https://marketplace.visualstudio.com/items?itemName=streetsidesoftware.code-spell-checker-spanish) support.
- [CODEOWNERS](https://marketplace.visualstudio.com/items?itemName=jasonnutter.vscode-codeowners), syntax highlight for [GitHub CODEOWNERS files](https://docs.github.com/en/github/creating-cloning-and-archiving-repositories/about-code-owners).
- [CSS-in-JS](https://marketplace.visualstudio.com/items?itemName=paulmolluzzo.convert-css-in-js), autocomplete for CSS in JS code.
- [Docker](https://marketplace.visualstudio.com/items?itemName=ms-azuretools.vscode-docker), autocomplete for `Dockerfile` files and a UI to control my Docker images.
- [DotENV](https://marketplace.visualstudio.com/items?itemName=mikestead.dotenv), syntax highlight for `.env` files.
- [ESLint](https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint), run ESLint directly in VSCode.
- [Git Blame](https://marketplace.visualstudio.com/items?itemName=waderyan.gitblame), show latest person who touched (blame) the line of code I’m currently selecting.
- [Git Project Manager](https://marketplace.visualstudio.com/items?itemName=felipecaputo.git-project-manager), let me use my Git repos inside the configured folders as projects and switch between them with a simple shortcut.
- [GitHub Actions](https://marketplace.visualstudio.com/items?itemName=formulahendry.github-actions), syntax highlight for GitHub Actions files.
- [gitignore](https://marketplace.visualstudio.com/items?itemName=codezombiech.gitignore), syntax highlight for `gitignore` files and some other functions which I don’t really use.
- [GraphQL for VSCode](https://marketplace.visualstudio.com/items?itemName=kumar-harsh.graphql-for-vscode), syntax highlight for GraphQL code (inside `.gql` or `.graphql` files or tagged with a `gql` string literal tag.
- [Import Cost](https://marketplace.visualstudio.com/items?itemName=wix.vscode-import-cost), shows the size of the imported/required modules.
- [indent-rainbow](https://marketplace.visualstudio.com/items?itemName=oderwat.indent-rainbow), show in different colors the indentation levels before a line of code.
- [Jest Snapshot Language Support](https://marketplace.visualstudio.com/items?itemName=tlent.jest-snapshot-language-support), syntax highlight for Jest Snapshot files.
- [JSDoc Markdown highlighting](https://marketplace.visualstudio.com/items?itemName=bierner.jsdoc-markdown-highlighting), syntax highlight for Markdown inside JSDoc comments.
- [Live Share](https://marketplace.visualstudio.com/items?itemName=MS-vsliveshare.vsliveshare), allow others to connect to my VSCode or allow me to connect to other people VSCode, I use it mostly for Pair Programming.
- [MDX](https://marketplace.visualstudio.com/items?itemName=silvenon.mdx), syntax highlight for MDX code.
- [npm](https://marketplace.visualstudio.com/items?itemName=eg2.vscode-npm-script), autocomplete for common `package.json` keys.
- [npm Intellisense](https://marketplace.visualstudio.com/items?itemName=christian-kohler.npm-intellisense), autocomplete import statements for modules installed with npm/yarn.
- [PostCSS Language Support](https://marketplace.visualstudio.com/items?itemName=csstools.postcss), better CSS syntax highlight with support for custom syntax used with PostCSS.
- [Prettier - Code formatter](https://marketplace.visualstudio.com/items?itemName=esbenp.prettier-vscode), run Prettier directly in VSCode.
- [Ruby](https://marketplace.visualstudio.com/items?itemName=rebornix.Ruby), syntax highlight for Ruby code and other features.
- [SVG](https://marketplace.visualstudio.com/items?itemName=jock.svg), nice tools to work with SVG code.
- [Tailwind CSS IntelliSense](https://marketplace.visualstudio.com/items?itemName=bradlc.vscode-tailwindcss), autocomplete and other features for working with [Tailwind CSS](https://tailwindcss.com).
- [VSCode Ruby](https://marketplace.visualstudio.com/items?itemName=wingrunr21.vscode-ruby), improvement for Ruby language support in VSCode.
- [vscode-styled-components](https://marketplace.visualstudio.com/items?itemName=jpoissonnier.vscode-styled-components), syntax highlight and autocomplete for [styled-components](https://github.com/styled-components/styled-components).
- [vscode-styled-jsx](https://marketplace.visualstudio.com/items?itemName=blanu.vscode-styled-jsx), syntax highlight and autocomplete for [styled-jsx](https://github.com/vercel/styled-jsx).

### Prettier

For Prettier I don't like to customize it. The point of Prettier is to stop paying bikeshedding about code style.

### ESLint

I use a few plugins, with their recommended configuration, I don't like to spend too much time thinking about this and I don't like too strict rules, most of the rules I enable are to follow best practices or avoid common mistakes.

- [eslint-plugin-react-hooks](https://github.com/facebook/react/tree/master/packages/eslint-plugin-react-hooks), to enforce the [Rules of Hooks](https://reactjs.org/docs/hooks-rules.html), I use it extending `react-hooks/recommended` to have their recommended config.
- [eslint-plugin-prettier](https://github.com/prettier/eslint-plugin-prettier), to let ESLint uses the same code style rules as Prettier, I use it extending `plugin:prettier/recommended` to have their recommended config.
- [eslint-plugin-unicorn](https://github.com/sindresorhus/eslint-plugin-unicorn), lots of rules to help avoid some errors, I use it extending `plugin:unicorn/recommended` to have their recommended config.
- [eslint-plugin-testing-library](https://github.com/testing-library/eslint-plugin-testing-library), some helpful rules to follow best practices of Testing Library, I use it extending ``plugin:testing-library/react` to have their recommended config for React.
- [eslint-plugin-cypress](https://github.com/cypress-io/eslint-plugin-cypress), some helpful ruls to avoid common errors when using Cypress, I use it extending `plugin:cypress/recommended` to have their recommended config.
- [@typescript-eslint/parser](https://github.com/typescript-eslint/typescript-eslint/tree/master/packages/eslint-plugin), some rules to write better TS code, I use it extending `plugin:@typescript-eslint/recommended ` to have their recommended config.
- [eslint-plugin-import](https://github.com/benmosher/eslint-plugin-import), some rules related to imports, I use rules below:
  - `import/no-unresolved`: avoid importing modules that can't be resolved.
  - `import/no-anonymous-default-export`, avoid using export default with anonymous functions, classes and values.
  - `import/resolver`: configure how to resolve imports (required to support absolute paths)

I also use the next rules from ESLint (no plugins required)

- `yoda`, avoid conditions like `"red" === color` and instead force `color === "red"`.
- `func-style`, force a certain way to define functions (except inline functions), I use with to force `declaration` style, this forbids arrow functions for anything except inline functions.


This is my current development setup.
Tech Stack


TypeSc...

What I Use

---
path: historia
tags: career, spanish, webdev
---
# Como me inicié en el desarrollo web

Corría el año 2002, tenía unos 10 años, un día me pregunté cómo funcionan las páginas web, que se necesita para hacer una, una conocida estudiaba ingeniería en sistemas y aproveché para enviarle un mail (sí, un mail, era el 2002) y preguntarle que como se hacía, a lo que me comentó que con algo llamado HTML y me pasó unos links con más información.

De inmediato, me puse a leer estos para intentar entender, pero el HTML que hacía no se veía muy bien en el navegador, le pregunté que como se hacía para poner una columna a la izquierda con los links y el contenido a la derecha, me dijo que se hacía con la etiqueta `<style>`, y pensé "ahh entonces pongo esta etiqueta, el contenido dentro y listo", pero no, los primitivos de la web apestan, y dentro de esta etiqueta tenía que poner CSS para manualmente mover una etiqueta de mi HTML y acomodarlo en la pantalla, obvio que Flexbox o Grid no existían todo es mucho más fácil ahora.

Continuando, en su momento no entendí nada de CSS así que me puse a investigar más y aprendí que Word (sí, Microsoft Word) tenía una opción de edición HTML donde podías armar la página web de forma visual con la opción de ver el HTML, era lo máximo, usando Word aprendí que con una tabla podía sacar los bordes y armar el diseño a dos columnas sin que se vea la tabla, solo tenía que mover la línea que las separa para cambiar el ancho y listo.

Use esto para armar mi primera página web, un sitio simple con muchos gifs, un fondo horrible con una textura de Word y muchas tablas y contenido a mano. Subí mi sitio al primer hosting que use en mi vida, Yahoo! Geocities, para subirlo se usaba la UI, podías subir hasta 5 archivos a la vez nada más, con esto ya estaba online, y con el tiempo aprendí más cosas de cómo hacer webs, como que usando iframes podía reusar el HTML de mi columna de navegación entre varias páginas, y encontré servicios como Miarroba (que a día de hoy me manda mails automáticos por mi cumpleaños) que te daban contadores de visitas, libros de visitas, chats, etc. que podías poner con un pequeño código HTML y JS.

Pasaron los años, cambie de Word a FrontPage, de ahí a Dreamweaver y con este me quede, me dejo de interesar un poco aprender como funcionaban las páginas, solo hacía todo visualmente y listo, aprendí a usar sistemas de foros como phpBB o vBulletin, me buscaba plantillas ya hechas y listo capaz cambiaba algo del HTML, pero no mucho, nunca me aprendí demasiado las etiquetas.

Más o menos en 2007, unos cinco años después, ya en secundaria un amigo mayor que yo que sabía muchísimo de programación me dijo que aprenda bien HTML y CSS, está era la primera vez que escuchaba CSS, antes era solo esa cosa rara de las etiquetas style, y que aprenda a hacer temas de WordPress que para ese momento estaba en su boom.

La cosa es que decidí hacerle caso, aprendí a usar bien HTML con un [libro online gratis de un sitio llamado WikiLibros](https://es.wikibooks.org/wiki/Lenguaje_HTML), después aprendí CSS, para entonces usaba Dreamweaver que me daba autocompletado de las propiedades y sus valores lo cual me ayudo mucho a aprenderlos de a poco. Después aprendí WordPress y empecé a hacer plantillas propias, en el camino empecé a ver un poco, muy muy poco, de PHP, apenas lo suficiente para usar las funciones de WordPress.

El tiempo pasó, deje otra vez un poco de lado el desarrollo web, pero no del todo, esta vez seguí viendo de a poco comunidades de desarrollo web, entre estas las más importantes eran Cristalab (mi favorita) y Maestros del Web, sus creadores empezaron un programa en vivo llamado Mejorando la Web donde hablaban de tecnología, y lanzaron sus propios cursos de desarrollo web, para mi último año de secundaria fueron a Buenos Aires a hacer uno de HTML5, quería ir pero no tenía un peso para pagarlo y era algo caro, ese mismo año termine mi secundaria.

Dos años en el futuro, es el año 2013, estaba de vago (yo lo llamaba sabático) y los de Mejorando la Web (ahora solo Mejorando.la) lanzaron cursos online, para mitad de año convencí a mi mamá de que me preste su tarjeta de crédito para pagar un curso, con la promesa de trabajar una vez terminado y devolverle la plata (spoiler alert, nunca le devolví la plata, sean buenos hijos y no hagan lo que yo hice), tomé el curso de dos semanas, mi computadora murió a la mitad del curso y tuve que terminarlo en la de mi mamá, en este curso aprendí un poco más de HTML y CSS que para entonces ya era bastante bueno, y aprendí a programar en JavaScript, al fin aprendía este lenguaje, de hecho antes lo odiaba, me había dejado llevar por esta idea de que programar era solo Backend y JS era un lenguaje feo y mal hecho. 😰

Termine el curso, decidí seguir practicando JS y jQuery, hice mi primer proyecto Open Source, [Elecalc](https://github.com/sergiodxa/Elecalc) una calculadora de cálculos eléctricos, primero la hice en JS vanilla y luego use jQuery para trabajar con el DOM, eventualmente la pasa a Angular y React incluso. Para septiembre estaba ya cómodo haciendo JS y arme un sitio falso de eCommerce (solo el HTML) y un intento de juego, con estos tres proyectos me mande a buscar trabajo.

El proceso de búsqueda fue bastante sencillo y poco ortodoxo, fui a Google Maps y busqué "diseño web", con esto me salieron varias empresas que hacen diseño web en Buenos Aires, busque las que tenían página web (sorprendentemente algunas no tenían), cuáles de estas tenían una sección de empleos y seleccioné las que me llamaban más la atención. Otro criterio importante era que pudiese ir caminando (pocas cuadras) o en [Subte](https://www.buenosaires.gob.ar/subte) en sentido contrario a la hora pico (para ir cómodo 😏).

Encontré varias, postule a una, al final del día me contactaron para ver cuando podía ir a una entrevista, ahí les conté que sabía HTML, CSS, JS, jQuery, Jade (ahora Pug), Stylus y LESS , hable con el CEO y con el jefe de Maquetadores (para quién no conoce el término, son Frontend que solo hacen HTML y CSS y algunas animaciones o transiciones con jQuery).

Al final me pidieron volver otra vez para una prueba de trabajo de un día, fui temprano, me hicieron hacer una landing para un sitio de un cliente, para el final del día tenia el trabajo (consejo: no hagan esto, esta mal, si no me contrataban había trabajado un día gratis).

Algo importante que seguro afecto a que me elijan es que en el sueldo pretendido puse 3.000 pesos argentinos, el mínimo legal era 5.000 en ese momento, y supe luego que el resto cobraban más de 10.000, era muy barato, pero ya con mi primer sueldo me pude empezar a armar una computadora que es algo que quería hacer hacía tiempo.

Ya trabajando en esta empresa seguí tomando cursos en Mejorando.la y más que nada estudiaba por mi cuenta, aprendí Backbone, Angular.js, Node.js, MongoDB, MySQL, PHP y CodeIgniter al año siguiente (2014), ese año fui a [JSConfAR](https://www.jsconfar.com) y para antes de fin de año renuncié para intentar hacer una empresa con el que era el jefe de programadores de la empresa y uno de los ejecutivos de cuenta (los que hablan con los clientes), la cosa no funciono y a los meses me separé de ellos, en ese tiempo aprendí Polymer, ya que Web Components eran el futuro, intente hacer un proyecto con este y Angular y aprendí que Web Components no eran el futuro.

Para cuando deje este intento de hacer una empresa Google anuncio Angular 2 y dijo que iba a ser algo completamente diferente a la versión 1, decidí abandonar Angular y aprender React (best decision ever), había visto React más o menos al mismo tiempo que Polymer, pero la idea de poner HTML dentro de JS me parecía rara (que iluso que fui), con más motivación leí mas su documentación y entendí el por qué. A todo esto era el 2015 y ese año tenía Mejorando.la (ahora [Platzi](https://platzi.com)) gratis por un año, tome los curso de Node donde no aprendí nada y el de React donde luego me enteré que estaba compitiendo con Leonidas por tener las estrellas en el chat (el gano, pero es porque era más famoso, trabajaba el Platzi, así cualquiera 😝).

Para mitad de año me contactaron de Platzi para irme a trabajar con ellos a Colombia, acepte de una, saque el pasaporte, cuando tenía todo listo y los pasajes comprados le avisé a mi mamá que me iba (otra vez, no sean como yo, no hagan eso).

Ya en Colombia conocí a muchos devs que ahora sin mis amigos, a mi pareja, aprendí Redux, React Native, algo de Python y Django, y muchas cosas más de las que fui escribiendo en esos años. Dos años después me fui de Platzi para trabajar en [Vercel](https://vercel.com) (en ese momento ZEIT) y poco después salí de Vercel y entré a [Able](https://able.co) donde laburo actualmente desde hace casi dos años.

Ahora (año 2020), tengo casi 28 años, pasaron 18 años desde la primera vez que vi algo de HTML, y tuvieron que pasar 11 años para que aprenda a programar y consiguiera mi primer empleo, en los siguientes siete años aprendi probablemente más que en toda mi vida, muchas tecnologías, como resolver diferentes problemas, me mude de país dos veces, de ciudad 3, tuve un hijo, di [clases de Frontend en un bootcamp](https://www.codeable.la), y ahora trabajo como Frontend Lead en Able liderando (duh) la arquitectura del frontend de una de nuestras aplicaciones internas que esperamos pronto lanzar al público.

Y esa es mi historia, si llegaste hasta acá 👏 👏 👏 leíste un montón. Te leo en [Twitter](https://twitter.com/sergiodxa)!

Corría el año 2002, tenía unos 10 años, un día me pregu...

Como me inicié en el desarrollo web

---
tags: thoughts, api, rpc, rest, graphql
---

# Why build a non-RESTful API

One of the most common architectural styles to build an HTTP API is RESTful, or just REST, it works great for generic and open API that will be used used by many different clients, another common one is GraphQL, created by Facebook.

When building an open API following one of those, or both as like GitHub, is the best idea, both are standard which will help other to intuit how your API works.

However, when building an internal API for a product, you don't need to support many clients, you only need to support a few, and you control them.

Actually, building a generic API could make you slower and force you to do more work Client-side, imagine you are building a new route for your application, in this route you will show three different resources, most of the time you will need to trigger three different requests to get all the data, instead, in you don't strictly follow REST you will be build a custom endpoint for that view, this endpoint will directly read from the DB at the same time, all the data you need, this is way faster than doing three individual requests, at the end you request only one endpoint and can get all the resources you need.

The same could happen when performing a mutation, you could expose custom endpoint for the different actions an user may perform against the data (e.g. `/api/me/upload-avatar`) and be more specific, this could let you optimize them more than creating a generic `PATCH /api/users/:id` endpoint.

If you think this looks like RPC, or even GraphQL, yes that's exactly the idea, with GQL you can easily run a single query to get all the data a route will need, additional data could be later fetched when needed of course, but the idea is to reduce the number of requests you do and receive only the data you will need. For mutations, both use specific names instead of a generic endpoint used to any mutation.

One of the most common architectural styles to build an HTTP API is...

Why build a non-RESTful API

---
tags: react, assets, rails, ama
lang: en
---
# How I work with static assets in React apps

Most people when working with tools like webpack tend to add loaders like image-loader combined with optimizers to store the raw high quality assets in their repo and let the bundles optimize them at build time.

However once your app starts to grow this becomes way slower, and ask you this, why optimize your assets on every build/deploy when you can do it once and forget about it?

This is why, what I usually do is to optimize them only one time.

If I have an SVG instead of using a Babel loader to convert it to a React component on build-time I use [transform.tools](https://transform.tools) to do it once and store it as a React component.

If I have an image I pass it through [TinyPNG](https://tinypng.com) and get it with a huge size reduction, I also try to don't user images bigger than needed or I use `srcset` to load the specific size I need based on the user screen.

Then, after I have everything ready I let Rails serve the assets using their asset pipeline, Rails will automatically add a hash to make the URL unique and help improve the cache.

## Send hashed URLs to React

Since Rails hash the URLs automatically for me I can’t just use `/assets/logo.png` because that is not the real URLs.

What I do to be able to reference the correct URL client-side is to pass them from Rails to React. The key here is that static assets are exactly that, static, you can always know which assets you will need because they don’t change dynamically as assets whose URL you store in a DB.

To pass them from Rails to React I create script tag with the type `application/json` and and ID (usually `initial-props`), similar to this one:

```erb
<script type="application/json" id="initial-props">
  {
    "assets": {
      "logo": "<%= asset_path("images/logo.png") %>"
    }
  }
</script>
```

Then, before rendering the React application I read this JSON, store in an AssetContext I create and when I need a URL I use a custom Hook `useAsset` to ask for the asset name (e.g. `useAsset("logo”)`) and this returns me the asset URL.

Most people when working with tools like webpack te...

How I work with static assets in React apps

---
description: Learn how to create nested shallow resource routes in Rails
tags: rails, routes, til
lang: en
---
# How shallow: true works in Rails

If you have nested resources in your routes of Rails, you can use `shallow: true` this way

```ruby
resources :articles, shallow: true do
  resources :comments
end
```

This will create the following URLs:

```
GET     /articles
POST    /articles
GET     /articles/:id
PUT     /articles/:id
DELETE  /articles/:id
GET     /articles/:article_id/comments
POST    /articles/:article_id/comments
GET     /comments/:id
PUT     /comments/:id
DELETE  /comments/:id
```

This way, list and create comments are nested inside the parent resource `article` so you don't need to pass the `article_id` manually because it's in the URLs, but you can still get an individual comment, update it or delete it directly with `/comments/:id`.

How shallow: true works in Rai...

How shallow: true works in Rails

---
title: Build an Optimistic UI in React using SWR with useMutation
description: >-
  Use the useMutation hook together with SWR to implement optimistic updates in
  your React components
date: 2020-07-23T08:17:26.188Z
published: true
lang: en
tags: 'swr, useMutation, react, hooks'
path: swr/use-mutation
---
# Build an Optimistic UI in React using SWR with useMutation

One commont UX improvement when building User Interfaces is to add optimistic updates to the application.

Let's see how to do it easily with the [SWR](/swr/intro) Hook and the [useMutation](https://github.com/sergiodxa/use-mutation) hook.

---

We need to create a function where we will perform our mutation, let's say we are creating a new comment in an article.

```ts
async function createComment({
  authorId,
  articleId,
  body,
}: {
  authorId: number;
  articleId: number;
  body: string;
}) {
  const response = await fetch("/api/comments", {
    method: "POST",
    headers: {
      "Content-Type": "application/json",
    },
    body: JSON.stringify({ authorId, articleId, body }),
  });

  if (!response.ok) throw new Error(response.statusText);

  return await response.json();
}
```

With this, we can create a `useCreateComment` hook, this will let use re-use our mutation together with the optimistic update.

Here we will use the `cache` object and `mutate` function from SWR to optimistically update the data cachd by SWR.

```ts
import { cache, mutate } from "swr";
import useMutation from "use-mutation";

export function useCreateComment() {
  return useMutation<{ authorId: number; articleId: number; body: string }>(
    createComment,
    {
      onMutate(input) {
        // first we keep the current data in a const
        const currentData = cache.get(["article", input.articleId]);

        mutate((cachedData) => {
          // here we are adding the input data (the new comment) to the list of
          // comments of the article
          return { ...cachedData, comments: cachedData.comments.concat(input) };
        }, false);
        
        // this function is our rollback function, we will use it in case the
        // mutation failed
        return () => mutate(["article", input.articleId], currentData, false);
      },

      onSuccess(data) {
        // if the mutation was a success, we update the cache of SWR to replace
        // the comment to optimistically added and add the final one returned
        // by the API
        mutate(["article", data.articleId], cachedData => {
          return {...cachedData, comments: cachedData.comments.map(comment => {
            if (comment.id) return comment;
            return data;
          })}
        });
      }

      onFailure(error, rollback) {
        console.error(error);
        // here we are calling the rallback fn returned by onMutate
        rollback();
      },
    }
  );
}
```

And lately, we can use it in a React component

```tsx
import * as React from "react";
import { useCreateComment } from "mutations/use-create-comment";

function CommentForm({ articleId, userId }) {
  const [mutate, { status }] = useCreateComment();
  const [body, setBody] = React.useState("");

  const handleSubmit = React.useCallback<React.FormEventHandler>(
    function handleSubmit(event) {
      event.preventDefault();
      mutate({ articleId, userId, body });
    },
    [body]
  );

  return (
    <form onSubmit={handleSubmit}>
      <textarea
        value={body}
        onChange={(event) => setBody(event.target.value)}
      />
      <button>Create comment</button>
    </form>
  );
}
```

With this, once the user submit the form, it will first add the new commet at the bottom of the list, and then, it will try to create it, and if for some reason the request failed it will automatically rollback to use th previous data.


title: 
description: &gt;-
  Use the useMutation hook together with SWR to implement opt...

Build an Optimistic UI in React using SWR with useMutation

---
title: Como organizo mis aplicaciones de React
description: >-
  Hay muchas formas de organizar aplicaciones de React, con los años esta es la
  que más me ha convencido
date: 2020-07-16T05:56:01.823Z
published: true
lang: es
tags: 'react, typescript, Hooks, architecture'
translated_from:
  lang: en
  title: How I Organize React Applications
  path: /articles/react/file-structure/
path: react/estructura-archivos
---
# Como organizo mis aplicaciones de React

Una de las preguntas más comunes cuando se usa React es como organizar los archivos de nuestra aplicación. Con los años usé varias formas, tener carpetas por features, carpetas por componente, un componente por archivo, etc. Después de probar todas estas formas llegué a una suficientemente simple y escalable para proyectos grandes.

```
src/components/
  {name}.tsx
  {name}.test.tsx
src/hooks/
  {name}.ts
  {name}.test.tsx
src/mutations/
  {name}.ts
  {name}.test.tsx
src/queries/
  {name}.ts
  {name}.test.tsx
src/routes/
  {name}.tsx
  {name}.test.tsx
src/utils/
  {name}.ts
  {name}.test.ts
src/index.tsx               # El entry point
```

## 🧱 Componentes

La primera carpeta es la de componentes, acá coloco los componentes de la aplicación. Una cosa que hago diferente de muchos desarrolladores es que no creo un nuevo archivo por cada componente de React, sino que en un archivo normalmente escribo varios componentes, algo como esto:

```tsx
import * as React from "react";
// Otros imports que pueda necesitar

function ListItem(props) { ... }

function List(props) { ... }

function Group(props) { ... }

function Button(props) { ... }

export default function MyComponent() { ... }
```

De esta forma todos los componentes están en el mismo archivo, esto hace mucho más fácil modificarlos, sin embargo, no quiere decir que solo tengo un archivo con todos mis components, creo un nuevo archivo en estos casos:

- Quiero importarlos de forma async, en ese caso necesito un nuevo archivo
- El componente se usa en varios archivos
- El componente es usado por dos o más rutas
- El componente es lo suficientemente complejo para que tenga sentido que tenga pruebas propias
- El componente representa un feature entero (normalmente relaciondo al punto anterior)

Y creo un nuevo componente en el mismo archivo si:

- Necesito reusarlo dentro del mismo archivo
- Voy a usarlo dentro de una lista y tengo que usar Hooks
- Quiero usar Hooks solo cierta parte del componente principal
- Quiero poder controlar como el componente se suspende, ya que [uso Suspense para data fetching](/articles/swr/suspense/), pero sin suspende al componente padre
- El componente se volvió muy grande y tiene sentido dividirlo para que sea más legible

Para el caso de las pruebas, creo un único archivo por componente y junto todas las pruebas ahí, para escribirlas uso React Testing Library y sigo todas las prácticas que recominendan.

## ⚓️ Hooks

Creo Hooks custom cada vez que necesito compartir comportamiento entre componentes.

Un ejemplo de un Hook que normalmento creo es [`useAssets` combinado con un ContextProvider para compartir las URLs de los assets](#🖼️-apéndice-assets) o `useBoundingClientRect` para compartir comportamiento genérico.

Y hablando de contexto, lo uso, pero solo para valores mayormente estático (e.g. feature flags o assets), esto me evita problamas de que al modificar el valor en contexto se vuelva a renderizar casi toda mi aplicación.

Como con los componentes, hago pruebas de mis Hooks, para esto creo un componente Tester dentro de los tests donde uso el hook y testeo ese componente directamente.

## 🧬 Mutaciones

Una mutación es un tipo especial de Hook, las mutaciones representan una única unidad de cambio que el usuario puede realizar en la aplicación al realizar alguna acción, son wrappers de [useMutation](https://github.com/sergiodxa/use-mutation), un Hook pequeño que cree basado en el Hook del mismo nombre de [React Query](https://react-query.tanstack.com).

Como ejemplo, normalmente tiendo a tener mutaciones como `useUploadAvatar` o `useCreateTodo`, una mutación puede representar un cambio pequeño o complejo, la idea es que el usuario lo haga como una única acción.

Es importante destacar que no tienen que igualar los método HTTP POST/PUT/PATCH/DELETE, las mutaciones no son simples wrappers de un CRUD (por ejemplo `useCreateTodo`, `useUpdateTodo` y `useDeleteTodo`), aunque algunas veces creo mutaciones con esos nombres, más tiendo a tener nombres como `useCompleteTodo`, que si bien hace una operación PATCH sobre el endpoint de Todos, solo se encarga de un cambio de este recurso, no puede modificar otra cosa.

Ejemplo de que no hago:

```ts
import useUpdateTodo from "mutations/use-update-todo";

function Todo() {
  const [updateTodo] = useUpdateTodo();

  function handleCompleteClick() {
    updateTodo({ id: 1, completed: true });
  }

  // retorna alguna UI
}
```

Es demasiado genérico, podría usar la misma mutación para actualizar cualquier campo del recurso Todo, en vez de eso esto es lo que normalmente hago:

```ts
import useCompleteTodo from "mutations/use-complete-todo";

function Todo() {
  const [completeTodo] = useCompleteTodo();

  function handleCompleteClick() {
    completeTodo({ id: 1 });
  }

  // retorna alguna UI
}
```

Este es mucho más específico, la mutación solo va a ctualizar el campo `completed` del recuros Todo con el ID que especifique, y eso es todo.

Otra cosa que normalmente hago en estas mutaciones es agregar actualizaciones optimisticas a la información que tengo en el cliente, si es que es posible ya que algunas veses (ej. al crear un recurso) no lo es o es más difícil. También implemento un rollback para deshacer los cambios en caso de que la mutación falle junto a una revalidación en caso de éxito.

Este es el ejemplo final de como queda una mutación:

```ts
import { mutate, cache } from "swr";
import useMutation from "use-mutation";
import { Todo } from "types/schema";

type CompleteTodoInput = { id: number };
type CompleteTodoOutput = Todo;

async function completeTodo(
  input: CompleteTodoInput
): Promise<CompleteTodoOutput> {
  const res = fetch(`/api/todos/${id}`, {
    method: "POST",
    body: JSON.stringify({ completed: true }),
  });
  if (!res.ok) throw new Error(res.statusText);
  return (await res.json()) as CompleteTodoOutput;
}

export function useCompleteTodo() {
  return useMutation(completeTodo, {
    onMutate({ input }) {
      const key = ["todos", input.id];
      const old = cache.get(key);

      // actualizo la cache de forma optimista
      mutate(
        key,
        (todo) => {
          return { ...todo, completed: true };
        },
        false
      );

      // función para deshacer los cambios
      return () => mutate(key, old);
    },

    onSuccess({ input }) {
      // revalido
      mutate(["todos", input.id]);
    },

    onFailure({ rollback }) {
      // deshago los cambios en caso de error
      if (rollback) rollback();
    },
  });
}
```

## 🔍 Queries

Una query es otro tipo especial de Hook, en este caso su único propósito es hacer envolver a SWR y pasarle la key y la función fetcher. Usualmente un Hook dentro de esta carpeta se ve algo así:

```ts
import useSWR, { ConfigInterface } from "swr";

// fetcher
async function getCurrentUser() {
  const res = await fetch("/api/me");
  return await res.json();
}

export function useCurrentUser(config = {}: ConfigInterface) {
  return useSWR("current-user", getCurrentUser, { suspense: true, ...config });
}
```

Como se puede ver, el código es bastante pequeño, algunos a destacar son:

- El fetcher se llama `getX` y el Hook `useX`, donde `X` es la data que estoy pidiendo del API. 
- La `key` no es la URL del endpoint, en vez de eso tiene un nombre con significado, esto hace más fácil que luego llamemos a `mutate("current-user")` para revalidad o mutar esta data.
- El Hook recibe todas las opciones de configuración de SWR y se las pasa a useSWR, esto me deja cambiar la configuración en cada lugar que uso el Hook.
- A SWR los configuro por defecto para activar Suspense para Data-Fetching, esto es porque siempre lo uso de esta forma, pero permito desactivarlo pasando una configuración propia.

Una última cosa a destacar es que usualmente no agrego pruebas a mis queries, esto es porque la mayoría del código es un simple fetch que al hacerle pruebas terminaría mockeando haciendo inútil la prueba.

## 🗺️ Rutas

> Nota: Cuando uso Next.js esto es reemplazado por la carpeta `folders`.

Rutas es una carpeta de componentes especial, sigue las mismas reglas que uso para crear componentes en `src/components`, con la única diferencia de que cada componente dentro de rutas representa una ruta de mi aplicación.

Los archivos dentro de esta carpeta deben tener siempre un `export default`, esto es necesario para poder importar de forma asíncrona las rutas en el entry point, que es donde defino las rutas.

Estos componentes a veces no importan nada de la carpeta de components, esto pasa cuando la ruta tiene todo el código que necesita. Cuando necesito importar componentes externos normalmente intento hacerlo de forma asíncrona.

También escribo pruebas para mis rutas, en su caso tiendo a hacer pruebas de integración más que pruebas unitarias, esto es porque se incluyen varios features.

## 🔨 Utils

Creo funciones utilitarias todo el tiempo, me ayudan a nombrar piezas de lógica o simplement hacer más fácil de entender que está ocurriendo, especialmente cuando tiene múltiples condiciones, ya que puedo hacer algo como:

```ts
function getSomething() {
  if (condition) return value;
  if (anotherCondition) return anotherValue;
  return yetAnotherValue;
}
```

Sin embargo, no siempre las creo dentro de `src/utils`, primero las escribo dentro dentro del mismo archivo donde las necesito, que puede ser un hook, components, ruta o incluso otro util, una vez que un util es usado en tres o más archivo lo muevo a su propio archivo para evitar duplicados ([WET](https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33)).

También escribo pruebas para mis funciones utilitarias cuando estas son bastante largas o suficientemente complejas para necesitarlas, aunque cuando son solo wrappers de otra función o de una API de los navegadores evito agregarle pruebas.

## 🚪 Entry point

Finalmente, el entry point es donde importo de forma asíncrona todas mis rutas y donde importa los proveedores de context que puedas necesitas, acá defino todas las rutas y renderizo la aplicación.

Normalmente no creo un componente App ya que en la mayoría de casos con solo renderizar Router y las rutas es suficientemente para que la aplicación funcione.

Cuando uso Next.js, esto es reemplazado por `pages/_app.tsx`.

## 🖼️ Apéndice: Assets

Cuando uso assets evito importarlos directo en mi código, esto hace el build mucho más lento y el único beneficio, agregar hashes a los nombres de los assets, lo puedo lograr con otras herramientas especializadas. En mi caso trabajo con Rails como backend, así que dejo que este maneje mis assets y uso las vistas de Rails para pasar las URLs de esos assets a React agregando una etiqueta script de tipo `application/json` con un JSON con las URLs.

```html
<script type="application/json" id="initial-props">
{
  "assets": {
    "logo": <%= asset_path("images/logo.png") %>
  }
}
</script>
```



title: 
description: &gt;-
  Hay muchas formas de organizar aplicaciones de React, con los años esta es la
...

Como organizo mis aplicaciones de React

---
title: How I Organize React Applications
description: >-
  There are many ways to organize a React application, with the years this the
  the one I liked the most
date: 2020-07-16T04:37:52.438Z
published: true
lang: en
tags: 'react, typescript, hooks, architecture'
translated_to:
  - lang: es
    path: /articles/react/estructura-archivos/
path: react/file-structure
---
# How I Organize React Applications

When using React one of the most common question is how to organize the files inside it. In my years using it I have tried multiple options, including using feature folders, folders per components, one component per file and more, after trying them all, I finally found one that is simple and scale with big projects at the same time.

```
src/components/
  {name}.tsx
  {name}.test.tsx
src/hooks
  {name}.ts
  {name}.test.tsx
src/mutations/
  {name}.ts
  {name}.test.tsx
src/queries/
  {name}.ts
  {name}.test.tsx
src/routes/
  {name}.tsx
  {name}.test.tsx
src/utils
  {name}.ts
  {name}.test.ts
src/index.tsx               # The entry point
```

## 🧱 Components

The first folder is the components folder, this one contains the components of the application. One special thing I do that most React developers don't is that I don't create a new file per React component, this means in the same file I can have more than one React component, in a normal file inside components I wrote things like:

```tsx
import * as React from "react";
// Possible more imports here

function ListItem(props) { ... }

function List(props) { ... }

function Group(props) { ... }

function Button(props) { ... }

export default function MyComponent() { ... }
```

This way, all the component I create are in the same file, this make it easier to change them, this doesn't mean all the components are always in the same file, I move components to a new file in some cases

- I want to lazily import them, in that case I need a new file to import
- The component is used by another component in a different file
- The component is used by two or more routes
- The component is too complex and it makes sense to test it in isolation
- The component represents a whole feature (usualy this is related to the point above)

And I create a new component inside the same file if

- I need to re-use it inside the same file
- I need to use it inside a list and call hooks per each item
- I want to use hooks only related for that part of the main feature of the file
- I want to suspend the component, because [I use suspense for data fetching](/articles/swr/suspense/), without suspending the parent component
- The component its getting to big and it makes sense to split it to make it easy to read it

For the tests, I create a single test file per component and put all the tests I wrote there, to write them I use React Testing Library and I follow all the best practices they recommend.

## ⚓️ Hooks

I create custom hooks everytime I need to share behavior between components.

An example of a Hook I usually create are things like [`useAsset` combined a Context provider to share asset URLs](#🖼️-apendix-assets) or `useBoundingClientRect` to share a generic behavior.

And talking about Context, I still use it, but only when the value stored in the Context is mostly static, e.g. feature flags or assets), this way I don't have issues because the Context value changed and triggered a re-render in most of the application.

As with components, I test the hooks, to do it I create a simple Tester component using the hook in the test file and I test the component directly.

## 🧬 Mutations

A mutation is a special kind of Hook, a mutation represent a single unit of change the user can perform in an application in a single action, they are wrapper of [useMutation](https://github.com/sergiodxa/use-mutation), a tiny Hook I created based on the useMutation Hook of [React Query](https://react-query.tanstack.com).

As an example I tend to have mutations like `useUploadAvatar` or `useCreateTodo`, a mutation could represent a really simple change or a complex one, the idea is that the user perform it as an individual action.

Note that a mutation doesn't match the HTTP methods POST/PUT/PATCH/DELETE, they are not like a CRUD wrapper (e.g. `useCreateTodo`, `useUpdateTodo` and `useDeleteTodo`), while I can still create mutations with those names I also have mutations with names like `useCompleteTodo` which is calling a PATCH against the todos endpoints and only update a certain field.

Example of what I don't do:

```ts
import useUpdateTodo from "mutations/use-update-todo";

function Todo() {
  const [updateTodo] = useUpdateTodo();

  function handleCompleteClick() {
    updateTodo({ id: 1, completed: true });
  }

  // return some UI
}
```

That looks generic, I could use the same mutation to update any field of the Todo resource, instead I do it this way:

```ts
import useCompleteTodo from "mutations/use-complete-todo";

function Todo() {
  const [completeTodo] = useCompleteTodo();

  function handleCompleteClick() {
    completeTodo({ id: 1 });
  }

  // return some UI
}
```

This is more specific, the mutation will only update the completed field of the Todo resource with the ID I've specified, and that's all.

Another thing I do in these mutations is to add the optimistic update of the data client-side, if possible since somethings it's not, and implement a rollback in case it failed together with a revalidation after a success.

This is a final example of how I create my mutations

```ts
import { mutate, cache } from "swr";
import useMutation from "use-mutation";
import { Todo } from "types/schema";

type CompleteTodoInput = { id: number };
type CompleteTodoOutput = Todo;

async function completeTodo(
  input: CompleteTodoInput
): Promise<CompleteTodoOutput> {
  const res = fetch(`/api/todos/${id}`, {
    method: "POST",
    body: JSON.stringify({ completed: true }),
  });
  if (!res.ok) throw new Error(res.statusText);
  return (await res.json()) as CompleteTodoOutput;
}

export function useCompleteTodo() {
  return useMutation(completeTodo, {
    onMutate({ input }) {
      const key = ["todos", input.id];
      const old = cache.get(key);

      // optimistically update cached data
      mutate(
        key,
        (todo) => {
          return { ...todo, completed: true };
        },
        false
      );

      // rollback optimistic update
      return () => mutate(key, old);
    },

    onSuccess({ input }) {
      // revalidate
      mutate(["todos", input.id]);
    },

    onFailure({ rollback }) {
      // rollback in case of failure
      if (rollback) rollback();
    },
  });
}
```

## 🔍 Queries

A query is another special kind of Hook, in this case their only purpose is to wrap SWR and provide the required key and fetcher function. Usually a Hook inside this folder will looks like this:

```ts
import useSWR, { ConfigInterface } from "swr";

// fetcher
async function getCurrentUser() {
  const res = await fetch("/api/me");
  return await res.json();
}

export function useCurrentUser(config = {}: ConfigInterface) {
  return useSWR("current-user", getCurrentUser, { suspense: true, ...config });
}
```

As you can see, the code here is usually small, a few notable points:

- The fetcher is called as `getX` and the Hook is `useX` where `X` is the data I'm querying
- The `key` is not the URL of the endpoint, instead I use a meaningfull name, this makes it easier to later call `mutate("current-user")` to revalidate it or mutate it
- The Hook receives all the configuration options of SWR and pass it to useSWR, this let me control the configuration in a per-instance way.
- SWR is, by default, configured to enable Suspense for Data-Fetching, I always use it this way, but I can still disable it in some cases passing a custom config.

Another things to remark here is that I usually don't test queries, this is because most of the code is a simple fetch whose test will be mocked anyway making it useless the Hook is just a wrapper of SWR.

## 🗺️ Routes

> Note: When using Next.js this is replaced by the `pages` folder.

Routes is a special components folder, this follow the same rules I use for components inside `src/components`, the only difference is that they represent a single route of my application.

The files here must always have a single `export default`, this is required to be able to lazily import the routes in the entry point which is where I define my routes.

These components are sometimes not importing a single component from the components folder, because they implement the whole features the page needs, and when I import external components I try to do it lazily too.

Here I also add tests, but in this case I do more integration tests rather and unit tests, this is because I'm testing the whole page with all the features inside it.

## 🔨 Utils

I create utility functions all the time, it helps me name piece of logics or simple make it easier to understand what is happening, specially when there are multiple conditions because I can do things like:

```ts
function getSomething() {
  if (condition) return value;
  if (anotherCondition) return anotherValue;
  return yetAnotherValue;
}
```

However, I don't always create them in a file inside `src/utils`, I first write them inside the same file it needs them, this could be a hook, component, route, or even another utility, but if my utility function is used in three or more files then I move it to a file inside the utils folder to avoid duplicating it ([WET](https://dev.to/wuz/stop-trying-to-be-so-dry-instead-write-everything-twice-wet-5g33)).

I also write test for the utils I code only when they are large or complex enough to need it, and when they are not only wrappers of another function, specially if they wrap a browser API.

## 🚪 Entry Point

Finally, the entry point is where I lazily import all the routes, I import the context providers I may need, and I define all my routes and render the whole application.

I don't really create an App component because most of the time I can directly render the Router and Route components without wrapping them in an App.

When using Next.js, this is the `pages/_app.tsx` file.

## 🖼️ Appendix: Assets

When using assets, I don't like to import them in my code, this makes the build process way slower and the only benefit, have hashes in the assets name, I can gain it using other specialized tools. In my case I work with Rails as a backend, thus I let Rails handle static assets and I use the Rails view to pass the URLs of those assets to React adding a script of type `application/json` with a JSON containing the URLs.

```html
<script type="application/json" id="initial-props">
  {
    "assets": {
      "logo": <%= asset_path("images/logo.png") %>
    }
  }
</script>
```


@sergiodxa

Ask me Anything!

Latest Articles