DEV Community: Felipe Freitag Vargas

Trying CSS art with Tailwind

Felipe Freitag Vargas — Wed, 22 Jan 2025 14:13:28 +0000

I'm fiddling with making art with Tailwind to improve some design and CSS skills.

Does it make sense? Isn't it harder than with pure CSS? I don't care, it's just for the sake of it 😁

It's loosely based on this post.

Run it here: https://play.tailwindcss.com/BInT1TVC7i?size=540x720

Code:

<div class="flex h-[100vh] w-full items-center justify-center bg-blue-300">
  <div class="relative h-[200px] w-[200px] rounded-full bg-orange-300 shadow-2xl">
    <div class="0 absolute left-1/2 top-1/3 h-[50px] w-[130px] -translate-x-1/2">
      <div class="flex items-center justify-between">
        <div class="relative h-[0px] w-[40px] rounded-t-full border-t-[20px] border-t-white">
          <div class="absolute -top-[10px] left-1/2 h-[10px] w-[10px] rounded-t-full bg-slate-600"></div>
        </div>
        <div class="relative h-[0px] w-[40px] rounded-t-full border-t-[20px] border-t-white">
          <div class="absolute -top-[10px] left-1/2 h-[10px] w-[10px] rounded-t-full bg-slate-600"></div>
        </div>
      </div>
    </div>
    <div class="absolute left-1/2 top-1/2 h-[80px] w-[150px] -translate-x-1/2 translate-y-3 overflow-hidden rounded-b-full bg-slate-600">
      <div class="absolute left-[10px] h-[20px] w-[100px] rounded-b-lg bg-white"></div>
      <div class="absolute right-[10px] h-[20px] w-[20px] rounded-b-md bg-white"></div>
      <div class="absolute left-1/2 top-3/4 h-[40px] w-[50px] -translate-x-1/2 rounded-3xl bg-red-500"></div>
    </div>
  </div>
</div>

Result:

How to disable a link in React Router 7 / Remix

Felipe Freitag Vargas — Thu, 09 Jan 2025 18:53:04 +0000

Today, I joined a discussion on the Remix Discord about how to block a Link component when a certain condition is true.

A simple solution is to use a ternary to render either the Link or a disabled button styled to look identical. You can abstract it into a reusable component. I've used this pattern at Seasoned many times 😁

{disabled ? (
  <button
    className="bt bt-blue" // add the disabled appearance as needed
    disabled={disabled}
  >
    <CheckIcon /> Go!
  </button>
) : (
  <Link
    to={`....`}
    className="bt bt-blue"
    preventScrollReset
  >
    <CheckIcon /> Go!
  </Link>
)
}

Enjoy!

Create admin panels for Postgres in 3 short steps

Felipe Freitag Vargas — Tue, 19 Nov 2024 20:19:00 +0000

With Flashboard, you can create admin panels for your Postgres Databases in an instant.

Modern look
Great UX
No need to build the UI
Light and dark mode (it follows your OS settings 😉)

Let's go from scratch:

1. Create an account

Enter your email and choose a strong password.

The password will encrypt your DB connection strings, so make sure you'll remember it!

Complete your (very short) profile

2. Connect a database

Choose "connect my real database"

If you want to look around first, go with "play with a demo".

Find your connection string and paste it.

If needed, check out this helpful guide to connection URLs.

Optional: select namespace.

Most of the times, it will be "public". If there's only one namespace, you'll go directly to the next step.

Choose a panel name and slug.

You need to confirm the same password you used to sign in. It will encrypt the connection URL. Only you have access to your DB data.

You're connected and ready to build!

3. Build your first tab

Let's create our tab. All your relations are already available, pick one from the selector.
For this example, let's go with "coupons".

Almost there. Let's choose some fields!

You can choose what fields to list, reorder the columns with drag-and-drop, pick a default column to order records by.

Looking good! We already have a read-only list of coupons, complete with search, filters and pagination.

Let's add some CRUD operations to it. Click on "Build" to see the options.

Table settings: what appears on the list. We already configured it when creating the tab, but you can change it when needed.
Detail settings: enable it if you want users to see the details of a row. Details can show data from columns and relations.
New item settings: enable it if users should be able to create new records. You can choose what fields to show on the form.
Edit item settings: enable it if users should be able to edit records. You can choose what fields to show on the form.
Allow deleting: toggle it if users should be able to delete records.

You don't need to configure everything at once. Each feature is disabled by default to prevent mistakes like "wooops, I forgot to disable XYZ".

From here on, you can use it as-is, create more tabs, or share panels with team members.

That's all you need to have an up-and-running Postgres admin panel.

Please let me know what you think!

Thinking about leaving IT?

Felipe Freitag Vargas — Thu, 14 Nov 2024 21:51:05 +0000

I’ve spoken with several people who aren’t sure how much longer they can handle working in IT.

Some of the most common experiences they mention:
• stress
• burnout
• the day-to-day chaos
• conflicts
• impostor syndrome
• isolation
• shame
• feeling like they’re the only one going through this

It’s hard to understand from the outside. The IT field as a whole still has opportunities that other industries don’t. That only makes it harder for those caught in this whirlwind, whether as a developer or a leader. I know of cases where the suffering is so silent that even the people they live with don’t know about it.

Thinking about all this breaks my heart.

But there’s also a sense of calm that comes to me. I’ve been through similar experiences. I had the opportunity, and luck, to learn something that changed my life.

I learned that suffering doesn’t come from outside circumstances. It comes from within, from the set of thoughts and feelings. I learned that a state of greater peace and clarity is always available. It surfaces when the volume of thoughts decreases.

We have an innate connection to a deeper feeling. It brings new ideas and an infinite capacity to see situations in new ways. We are born with it, but we forget about it.

As for staying or leaving… making decisions of this size from an agitated mind doesn’t seem like a good idea.

We gain much more clarity when the dust settles.

Believing that it’s possible to calm down may make some difference. Remembering this state that is more centered or peaceful is enough to feel some relief. Ideas always come from within when we pay attention.

If you can relate, know that you’re not alone. ❤️

I don’t have solutions or advice. The idea of what’s best for each person can only come from within.

If you’d like to learn together and share experiences, I’d be happy to listen. :)

Pensando se sai ou não da TI?

Felipe Freitag Vargas — Thu, 14 Nov 2024 21:50:14 +0000

Já falei com várias pessoas que não sabem quanto tempo mais aguentam trabalhar na área. Falei desse assunto com pessoas das áreas de desenvolvimento, liderança, gestão de produto e design.

Algumas das experiências mais citadas:

stress
burnout
caos do dia a dia
conflitos
síndrome do impostor
isolamento
vergonha
achar que é a única pessoa passando por isso

É difícil de entender olhando de fora. A TI como um todo ainda tem oportunidades que outros mercados não tem. Pensar nisso só complica mais para quem está mergulhado nesse turbilhão, seja como dev ou como líder.

Se era pra estar bom e não está, “tem algo errado comigo”. Sei de casos em que o sofrimento é tão silencioso que nem as pessoas que moram junto sabem a respeito.

Só de pensar nisso tudo me parte o coração.

Mas também me vem uma tranquilidade. Passei por experiências similares e tive a oportunidade, e/ou sorte, de aprender que o sofrimento não vem de fora das circunstâncias, e sim de dentro, do conjunto de pensamentos-sentimentos. Aprendi que um estado de mais paz e clareza está sempre disponível, instantaneamente, quando o volume de pensamentos diminui.

Possuímos uma conexão com um sentimento mais profundo que traz novas ideias, e uma capacidade infinita para enxergar as situações de formas novas. Isso é inato, só esquecemos que temos esse recurso.

Sobre ficar ou sair… Tomar decisões desse porte a partir de uma mente agitada não parece uma boa ideia. Temos muito mais clareza quando a poeira baixa.

Às vezes, apenas achar que é possível se acalmar já faz toda diferença. Às vezes, lembrar desse estado mais centrado/inspirado/em paz é suficiente para dar uma respirada e aliviar um pouco. Mas sempre vem alguma ideia de dentro, quando prestamos atenção.

Caso tenha se identificado, saiba que não é só você ❤️

Não tenho soluções nem conselhos. A ideia do que é melhor pra cada um só pode vir de dentro.

Se quiser aprender junto e trocar experiências, vou ficar feliz de escutar.

Google Analytics (GA4) implementation with React - Remix example

Felipe Freitag Vargas — Fri, 01 Nov 2024 19:28:47 +0000

If you want to configure GA4 with code instead of using Tag Manager, here's how I did it. The example uses Remix, but it should be very similar with any React framework.

I've spent quite a few hours configuring GA4 with React, plus a cookie banner and consent mode. I hope it'll be faster next time thanks to these notes. I'll separate the consent mode stuff into another post to keep things simple.

Disclaimer: there might still be issues here, I'll update the post as I find them. But the tag is being recognized and there are events firing.

The gtag code

After creating your Google Analytics account, property and stream, at some point you'll see this code:

<!-- Google tag (gtag.js) -->
<script async src="https://www.googletagmanager.com/gtag/js?id=G-C33KHSZBKZ"></script>
<script>
  window.dataLayer = window.dataLayer || [];
  function gtag(){dataLayer.push(arguments);}
  gtag('js', new Date());

  gtag('config', 'G-.........');
</script>

It has two parts:

Loading the gtag.js script: the async one
Configuring the datalayer array and gtag function

They are NOT the same thing! If you don't need to add a cookie banner to get the user consent, you don't need to worry about it. But if you need to comply with the GDPR or with Brazil's LGPD, you will need to understand a bit more. That will be the theme of a future post.

GA hook

Let's go with the simple implementation, a custom hook.

This hook can be called multiple times if needed, and it will ensure the initialization runs only once. It has a convenient return to let you know if it is ok to use GA.

const useGoogleAnalytics = (
  gaMeasurementId: string | undefined,
) => {
  const [isInitialized, setIsInitialized] = useState(false)
  useEffect(() => {
    const loadScript = () => {
      // gaMeasurementId is optional so not all devs need it to run the app
      if (!window.gtag && gaMeasurementId) {
        // Create the script element
        const script = document.createElement('script')
        script.src = `https://www.googletagmanager.com/gtag/js?id=${gaMeasurementId}`
        script.async = true
        // Append the script to the document
        document.head.appendChild(script)
        // Initialize gtag when the script is loaded - this could be done before
        script.onload = () => {
          window.dataLayer = window.dataLayer || []
          function gtag() {
            window.dataLayer.push(arguments)
          }
          window.gtag = gtag
          window.gtag('js', new Date())
          window.gtag('config', gaMeasurementId, {
            debug_mode: false, // I keep this here to remember where to toggle debug
          })
          // Mark as initialized
          setIsInitialized(true)
        }
      } else {
        // gtag is already available, mark as initialized
        setIsInitialized(true)
      }
    }
    loadScript()
  }, [gaMeasurementId, analyticsAnonymousId])
  return isInitialized
}

Caveat

This code creates a single script that loads GA immediately; if you need to comply with some privacy laws, you can't do it this way! The external script can only be loaded after getting the user's consent. I'll show how I did it in a future post.

Usage

Here's an example of how to track page views:

// root.tsx
export async function loader({ request, params }: LoaderFunctionArgs) {
  return json(
    {  
      gaMeasurementId: process.env.GA_MEASUREMENT_ID, // or however you manage and protect your env vars. Not strictly necessary, but I prefer to manage all of them from the server
    },
  )
}

function GoogleAnalytics() {
  const location = useLocation()
  const { gaMeasurementId } =
    useLoaderData<typeof loader>()

  const isGaInitialized = useGoogleAnalytics(
    gaMeasurementId,
    analyticsAnonymousId
  )

  useEffect(() => {
    if (isGaInitialized && gaMeasurementId) {
      window.gtag('config', gaMeasurementId, {
        page_path: location.pathname,
      })
    }
  }, [isGaInitialized, location, gaMeasurementId])
  return null
}

export default function Component() {
  return (
    <>
      <GoogleAnalytics />
      <Outlet />
    </>

Function to track events

You can use similar code to register any client-side events or user properties you might need. just call window.gtag('event', ...) following Google's API.

Here's a reusable example:

// analytics.client.ts

import type { SnakeCase } from 'string-ts'

function trackClientAnalyticsEvent<T extends string>(
  eventName: T & SnakeCase<T>, // GA only supports snake_case event names. Let's enforce it at type-level to make life easier
  properties?: Record<string, unknown>
) {
  return window.gtag && window.gtag('event', eventName, properties)
}

export { trackClientAnalyticsEvent }

In my case, I'm only using that function to register a few clicks, since most events will be registered server-side.

...  
<Link
  to={`...`}
  onClick={() =>
    trackClientAnalyticsEvent('user_clicked_this_link')
  }
>
  Call To Action!
</Link>
...

This should be enough to get you started. Now you can go on to figure out consent mode and server-side events with the measurement api. Good luck!

As 3 fases do Shape-Up

Felipe Freitag Vargas — Thu, 18 Apr 2024 16:14:59 +0000

O livro do Shape-Up é um ponto de partida fundamental para compreender, utilizar e adaptar a metodologia. Porém, o método é jovem, está em constante evolução e Ryan Singer, seu criador, segue em pesquisa e prática constantes para sua evolução.

Esse post é uma visão geral do método para servir de guia para quem quer iniciar.

Há 3 fases no Shape-Up:

Framing, "enquadramento"
Shaping, "formatação"
Building, construção

Na época em que o livro foi escrito, ainda não havia a distinção entre framing e shaping.

Framing

O primeiro passo é "enquadrar" o problema. Framing ainda não é sobre a solução, é sobre o problema. É sobre a demanda (o que os clientes querem), não sobre a oferta (features). De acordo com Ryan,

O entregável de uma sessão de framing é um problema bem estruturado: algo em que o negócio diz "se pudermos moldar isso em algo viável e executar dentro de X semanas, isso será significativo para nós."

https://www.feltpresence.com/framing/

Shaping

Ao ter um frame bem definido, priorizado em relação a outros e negociado entre os stakeholders, é o momento de fazer o shaping. Enquanto o framing trata do lado da demanda, do problema, o shaping trata da oferta, da solução.

É sobre esse processo que trata grande parte do livro Shape Up, dos capítulos 1 a 6: a partir do frame, estabelecer limites, encontrar e reduzir os maiores riscos técnicos, e chegar na formatação de uma solução que caiba no apetite de X semanas definido no frame.

Shaping é chegar àquele momento de "aha" juntos, onde o conceito se cristaliza. Onde sabemos o que fazer. Quando dizemos: "É isso!" Quando temos algo que sabemos que podemos construir no tempo que temos (apetite) e que satisfaz o que queremos (frame).

https://www.feltpresence.com/shaping-isnt-writing/

O entregável do processo de shaping era chamado de pitch originalmente, porque dentro do Basecamp havia um processo de escolher (apostar) entre múltiplos pitches. Porém, em um contexto onde o que está em shaping partirá para produção, faz mais sentido chamar isso de package, um pacote que contém o que o time de desenvolvimento precisa para construir.

Building

Os capítulos 10 em diante do livro Shape Up tratam deste processo. O time de desenvolvimento parte do pacote, prepara escopos de tamanho implementável e leva cada pedaço até sua conclusão.

O entregável desse passo é ter features em produção, provendo valor real.

Mudando a experiência do trabalho

Felipe Freitag Vargas — Tue, 09 Apr 2024 19:13:08 +0000

"Você ainda tem aqueles episódios de ter que parar de trabalhar uns dias por causa de stress?"

A pergunta me pegou de surpresa. Eu estava conversando com um dev com quem trabalhei há alguns anos e tive que parar um momento para tentar lembrar do que ele estava falando. É verdade, eu tive episódios de intenso stress no trabalho e algumas vezes cheguei no limite de parar de funcionar.

O curioso é que eu sequer lembrava que tinha passado por isso, de tão diferente que as coisas são hoje em dia.

O que mudou?

Não fui morar na praia, não abandonei a área de tecnologia nem mudei de trabalho, mas diria que minha experiência hoje é completamente diferente. Os desafios seguem aí: balancear data apertada para entregar projeto com criação de débito técnico, fazer o time render mais, contratar e treinar, resolver bugs em produção, conseguir a renovação de contrato com cliente, enfim, as coisas normais de desenvolvimento de software.

O trabalho em si teve mudanças, processos evoluíram, houve amadurecimento em vários aspectos. Mas o principal fator na redução do stress, e também aumento de produtividade, foi a mudança da minha relação com a experiência de trabalhar.

Hein? Experiência?

É como quando a arquitetura de um framework ou sistema "clica" e passa a fazer sentido, você enxerga como a coisa funciona e consegue trabalhar com ela de uma maneira totalmente diferente de antes.

O sistema não mudou, mas você agora navega por ele com mais habilidade.

No meu caso, o catalisador foram estudos sobre o entendimento da mente, que me levaram a procurar a mentoria da cbo.digital.
Na mentoria, tive Insights que me ajudaram a navegar todos esses desafios do trabalho e da vida pessoal.

Não é fácil traduzir um insight em palavras, já que ele é um fenômeno de "dar-se conta" de algo que de repente passa a ser óbvio, não em um nível intelectual, mas em um nível de vivência.

Dado esse porém sobre explicar insights, vou tentar: me dei conta que o stress não era algo criado das atividades do trabalho em direção a mim, "de fora pra dentro", mas sim a partir da minha percepção, "de dentro pra fora". Se a percepção muda, a experiência muda, independente do volume de coisas para fazer.

Já faz mais de três anos e insights seguem vindo, cada vez mais me mostrando que tudo pode ser ainda mais leve e tranquilo, mesmo em momentos críticos. Aliás, é muito mais efetivo e eficiente lidar com ações super importantes do trabalho a partir de um estado centrado e leve.

Um dos insights que essa experiência me trouxe foi a vontade de abrir a porta para ajudar mais devs a experienciarem um jeito de trabalhar com mais leveza: o desprograma, uma imersão online para devs que querem mais paz sem abandonar a área de tecnologia!

Delete heroku review apps with Github actions

Felipe Freitag Vargas — Thu, 29 Sep 2022 20:27:38 +0000

Heroku review apps are a very important part of our workflow at Seasoned. We use them a lot since we created a way to use them to create deploy previews of our SPA + API stack.

We used to create review apps automatically for each PR. But at the time of this writing, Heroku is about to stop having a free tier. So we need to be more conscious about when to create and destroy review apps.

It's possible to create them manually via the Heroku dashboard, so before trying to automate their creation, let's find a way to make sure they're deleted when a PR is closed.

There are actions on the Github marketplace that seem to handle the full review app workflow, but all of them do many more things and most are forks of one another. For now, I preferred to handle only the deletion process and to do so manually.

How-to

We need Heroku's Platform API for this. Two API calls are enough:

Find the app id from its name
Delete it from its id

It's worth mentioning we use the predictable url pattern option so we know the app name.

1: get the app name

GET /apps/{app_id_or_name}/review-app

Full curl command:

curl -n https://api.heroku.com/apps/$APP_NAME/review-app \
  -H "Accept: application/vnd.heroku+json; version=3" \
  -H "Authorization: Bearer <heroku-api-key")

This returns a big JSON. Let's use jq to parse it. It's already part of Github runner's preinstalled software, so we don't need to install it inside the action.

curl -n https://api.heroku.com/apps/$APP_NAME/review-app \
  -H "Accept: application/vnd.heroku+json; version=3" \
  -H "Authorization: Bearer <heroku-api-key>" | jq '.id'

"<app-id>"

That will give us the app id

2: Delete the app

All that's left is to delete it.
DELETE /review-apps/{review_app_id}

With curl:

curl -n -X DELETE https://api.heroku.com/review-apps/<app-id>" \
 -H "Content-Type: application/json" \
 -H "Accept: application/vnd.heroku+json; version=3" \ 
 -H "Authorization: Bearer <heroku-api-key>"

Translating to a Github Action

Now we need to make that work inside a Github Action. We could use the Heroku JS client to do the work, but that would mean creating a full Node Github action and that seems overkill for this use case.

I used variables to make the code easier to read, and a step output to have two well-defined steps instead a big list of commands.
The workflow trigger can be "pull request closed", since that will fire both for merged and closed PRs.

So far we have:

# .github/workflows/destroy-review-app.yml
name: Destroy review app
on:
  pull_request:
    types: [closed]

env:
  app-name: <predictable-url-pattern>

jobs:
  heroku-review-application:
    name: Destroy Heroku review app
    runs-on: ubuntu-latest
    steps:
      - name: Get review app id
        id: get-id
        run: |
          RESPONSE=$(curl -n https://api.heroku.com/apps/${{ env.app-name }}-pr-${{ github.event.number }}/review-app -H "Accept: application/vnd.heroku+json; version=3" -H "Authorization: Bearer ${{ secrets.HEROKU_API_KEY }}")
          APP_ID=$(echo $RESPONSE | jq -r '.id')
          echo "::set-output name=app-id::$APP_ID"

      - name: Destroy app
        id: destroy-app
        run: |
          APP_ID=${{ steps.get-id.outputs.app-id }}
          echo "Using id ${{ steps.get-id.outputs.app-id }}"
          RESPONSE=$(curl -n -X DELETE https://api.heroku.com/review-apps/"$APP_ID" -H "Content-Type: application/json" -H "Accept: application/vnd.heroku+json; version=3" -H "Authorization: Bearer ${{ secrets.HEROKU_API_KEY }}")

Note the -r flag on the jq command. It strips the double quotes from the value, it makes it cleaner to use later.

This action works for the happy path. Now we have two edge cases to handle.

Fail on error

In case of an error, it's enough to have a failed action that prints the full response.
The JSON response from the delete endpoing has a status: "deleting" property that we can use to check whether it worked.

STATUS=$(echo "$RESPONSE" | jq -r '.status')
if [ "$STATUS" = "deleting" ]; then
  echo "App deleted"
else
  echo "Error deleting app"
  echo "$RESPONSE"
  exit 1
fi

Exit early if not found

Not all our PRs will have review apps, and we don't want to have failed actions for all the ones that don't! So let's add a condition to exit early if the app doesn't exist.

if [ "$APP_ID" = "not_found" ]; then
  echo "App not found."
  exit 0
fi

Complete action

Voilà! Here's our complete action.
Features:

Run when a PR closes
Delete a review app if it exists
Exit successfully if it doesn't exist
Fails if it finds an app but can't delete it

# .github/workflows/destroy-review-app.yml
name: Destroy review app
on:
  pull_request:
    types: [closed]

env:
  app-name: <predictable-url-pattern>

jobs:
  heroku-review-application:
    name: Destroy Heroku review app
    runs-on: ubuntu-latest
    steps:
      - name: Get review app id
        id: get-id
        run: |
          RESPONSE=$(curl -n https://api.heroku.com/apps/${{ env.app-name }}-pr-${{ github.event.number }}/review-app -H "Accept: application/vnd.heroku+json; version=3" -H "Authorization: Bearer ${{ secrets.HEROKU_API_KEY }}")
          APP_ID=$(echo $RESPONSE | jq -r '.id')
          echo "::set-output name=app-id::$APP_ID"

      - name: Destroy app
        id: destroy-app
        run: |
          APP_ID=${{ steps.get-id.outputs.app-id }}
          if [ "$APP_ID" = "not_found" ]; then
            echo "App not found."
            exit 0
          fi
          echo "Using id ${{ steps.get-id.outputs.app-id }}"
          RESPONSE=$(curl -n -X DELETE https://api.heroku.com/review-apps/"$APP_ID" -H "Content-Type: application/json" -H "Accept: application/vnd.heroku+json; version=3" -H "Authorization: Bearer ${{ secrets.HEROKU_API_KEY }}")
          STATUS=$(echo "$RESPONSE" | jq -r '.status')
          if [ "$STATUS" = "deleting" ]; then
            echo "App deleted"
          else
            echo "Error deleting app"
            echo "$RESPONSE"
            exit 1
          fi

Create the first unit test for your Remix app loaders

Felipe Freitag Vargas — Tue, 09 Aug 2022 00:41:00 +0000

We're using a mix of E2E and unit tests to increase our confidence and maintainability of Remix apps at Seasoned.

Here I'll show one way to unit test a loader, step by step. At the time of this writing, there aren't standard ways of testing components that have Remix code. So we're testing our business logic, loaders and actions separately.

This article will show a sample test without authentication. Our own auth is distinct and is a big topic. The test auth setup is left as an exercise to the reader 😬

If you're interested in E2E, uou can see examples on the remix-forms repo.

What we're building

Let's use the remix-jokes app I built when first following the Remix docs. It's a clean install, without remix-stacks because they didn't exist at the time 😅 This app uses an Express server, a Postgres DB, and Jest to run unit tests.

Setup

We'll test route files. The best place for these test files are close to the routes themselves. But we need to tell Remix the test files aren't routes, or else the server will break. Add ignoredRouteFiles to Remix config and it's all good.

// remix.config.js
module.exports = {
  ...
  ignoredRouteFiles: ['.*', '**/__tests__/**'],
}

Add the first test (and discover a corner case)

Let's test app/routes/jokes/$jokeId.tsx.

//app/routes/jokes/$jokeId.tsx

export const loader: LoaderFunction = async ({ request, params }) => {
  const userId = await getUserId(request)

  const joke = await db.joke.findUnique({
    where: { id: params.jokeId },
  })

  if (!joke) {
    throw new Response('What a joke! Not found.', {
      status: 404,
    })
  }
  const data: LoaderData = { joke, isOwner: joke.jokester_id === userId }
  return data
}

The loader is a named export, so we can import it as any other function. But how do we call it, again? 😕

// app/routes/jokes/__tests__/jokeid.test.ts
import { loader } from '../$jokeId'

describe('loader', () => {
  it('first try', async () => {
    // What params do we need to call the loader? 
    expect(loader()).toEqual('foo') // does not work, of course
  })
})

Typescript to the rescue! It turns out we need 3 params: request, context and params.
The Jest environment must be set to "node" to use the Request class. Let's add a dummy test just to see if the function call works.

// app/routes/jokes/__tests__/jokeid.test.ts
import { loader } from '../$jokeId'

describe('loader', () => {
  it('second try', async () => {
    const request = new Request('http://foo.ber')

    const response = await loader({ request, context: {}, params: {} })

    expect(true).toBe(true)
  })
})

💣💥

We called the loader without the id param and it blew up. The function wasn't dealing with that case before because this route will always have an id, so our function call isn't valid. Let's add an id.

// app/routes/jokes/__tests__/jokeid.test.ts
import { loader } from '../$jokeId'

describe('loader', () => {
  it('second try', async () => {
    const request = new Request('http://foo.ber')

    const response = await loader({ request, context: {}, params: { jokeId: 'foo' } })

    expect(true).toBe(true)
  })
})

The error has changed, so that's progress:

Invalid prisma.joke.findUnique() invocation:


      Inconsistent column data: Error creating UUID, invalid length: expected one of [36, 32], found 3

The jokeId param needs to have a specific length. Let's treat that case in the code.

//app/routes/jokes/$jokeId.tsx
export const loader: LoaderFunction = async ({ request, params }) => {
  const userId = await getUserId(request)

  const jokeId = params.jokeId || ''

  if (![32, 36].includes(jokeId.length)) {
    throw new Response('Joke id must be 32 or 36 characters', { status: 400 })
  }

  ...
}

Now we can run our first real test.

// app/routes/jokes/__tests__/jokeid.test.ts
  describe('loader', () => {
  it('fails with an invalid id', async () => {
    const request = new Request('http://foo.ber')

    try {
      await loader({ request, context: {}, params: { jokeId: 'foo' } })
    } catch (error) {
      expect((error as Response).status).toEqual(400)
    }
    // Todo: assert loader has thrown
  })
})

There's a caveat though. If for some reason we don't fall inside the catch block, there won't be any expect on this test and it will be green. There are multiple ways to handle this, here is one of them:

// app/routes/jokes/__tests__/jokeid.test.ts
...
  it('fails with an invalid id', async () => {
    const request = new Request('http://foo.bar')

    let result
    try {
      await loader({ request, context: {}, params: { jokeId: 'foo' } })
    } catch (error) {
      result = error
    }

    expect((result as Response).status).toEqual(400)
  })

We could also assert that result isn't null, for example. But this solution seems good enough.

Testing 'not found'

It's very similar to the test above. Using a fake random id does the trick.

// app/routes/jokes/__tests__/jokeid.test.ts
...
  it('returns 404 when joke is not found', async () => {
    const request = new Request('http://foo.bar')

    let result
    try {
      await loader({
        request,
        context: {},
        params: { jokeId: '49ed1af0-d122-4c56-ac8c-b7a5f033de88' },
      })
    } catch (error) {
      result = error
    }

    expect((result as Response).status).toEqual(404)
  })

Testing the happy path

This one is straightforward as long as we have something in the database.

// app/routes/jokes/__tests__/jokeid.test.ts
...
  it('returns the joke when it is found', async () => {
    const request = new Request('http://foo.bar')

    const jokes = await db.joke.findMany({ take: 1 })
    const joke = jokes[0]
    const { id } = joke

    let result
    result = await loader({
      request,
      context: {},
      params: { jokeId: id },
    })

    expect(result).toEqual({ joke, isOwner: false })
}

Of course that depending on specific DB data can lead to issues as the project grows. The Prisma docs recommend mocking the client.

Full test file:

// app/routes/jokes/__tests__/jokeid.test.ts
import { loader } from '../$jokeId'
import { db } from '~/utils/db.server'

describe('loader', () => {
  it('fails with an invalid id', async () => {
    const request = new Request('http://foo.bar')

    let result
    try {
      await loader({
        request,
        context: {},
        params: { jokeId: 'foo' },
      })
    } catch (error) {
      result = error
    }

    expect((result as Response).status).toEqual(400)
  })

  it('returns not found when joke is not found', async () => {
    const request = new Request('http://foo.bar')

    let result
    try {
      await loader({
        request,
        context: {},
        params: { jokeId: '49ed1af0-d122-4c56-ac8c-b7a5f033de88' },
      })
    } catch (error) {
      result = error
    }

    expect((result as Response).status).toEqual(404)
  })

  it('returns the joke when it is found', async () => {
    const request = new Request('http://foo.bar')

    const jokes = await db.joke.findMany({ take: 1 })
    const joke = jokes[0]
    const { id } = joke

    let result
    result = await loader({
      request,
      context: {},
      params: { jokeId: id },
    })

    expect(result).toEqual({ joke, isOwner: false })
  })
})

We'll end up using a different approach: creating a test database that is reset for each test run. But that's a topic for a future post!

I hope you have enjoyed writing your first Loader test 😊

How to run a Remix app + package with turborepo

Felipe Freitag Vargas — Mon, 11 Jul 2022 18:24:18 +0000

Developing remix-forms was cumbersome because it wasn't connected directly to a Remix app using it. Testing the initial iterations involved publishing the package and importing it on a separate test web app. It was quick and dirty, and it worked when we had a couple of people writing it.

It was better to have everything in a single place in order to reduce development friction going forward.

Goals

This is a very simple use case that didn't need many features.

Develop the site using the local version of remix-forms
Hot reload the site when the package code changes
Deploy the site easily
Keep CI simple, running the e2e tests that we already have

Spoilers: check remix-forms for the end result or go to the sample monorepo to see a working configuration without any business logic.

For this article, I'll use a new Netlify Remix app and an empty TS package.

Strategy

We considered three options:

It seemed NPM workspaces would work and we wouldn't need any other dependencies. But there were some quirks to make the web app load the local package. After some trial and error, we decided to try the external tools.

Turborepo was pretty simple to setup and the fastest of the three from installation to seeing it working.

Nx docs weren't as easy to follow. We tried it for maybe half an hour, and decided to go with the one that "just worked". Again, our use case isn't complex and there isn't a need for tons of features.

Turborepo was the tool for this job.

Preparing the file structure

.
turbo.json
package.json
`-- packages
   +-- sample-package
`-- apps
   +-- web

First, we created a new root dir and copied the contents of the package to /packages and the Remix app to /apps/web.

Configure Turborepo

Following turborepo's guide, we got a couple of config files.

// ./turbo.json
{
  "$schema": "https://turborepo.org/schema.json",
  "baseBranch": "origin/main",
  "pipeline": {
    "build": {
      "dependsOn": [
        "^build"
      ],
      "outputs": [
        "dist/**"
      ]
    },
    "lint": {
      "outputs": []
    },
    "test": {
      "outputs": [],
      "dependsOn": [
        "^build"
      ]
    },
    "dev": {
      "cache": false
    }
  }
}

And a root package.json:

// ./package.json
{
  "name": "sample-monorepo",
  //...
  "workspaces": [
    "packages/*",
    "apps/*"
  ],
  "devDependencies": {
    "turbo": "^1.3.1"
  },
  "scripts": {
    "build": "turbo run build",
    "dev": "turbo run dev",
    "lint": "turbo run lint",
    "test": "turbo run test",
    "test:ci": "turbo run test:ci"
  }
}

Now wire the app to use the local sample-package:

// apps/web/package.json
{
  "name": "remix-web-app",
  //...
  "dependencies": {
    //...
    "sample-package": "*",
    //...
  }
  //...
}

It's already possible to see it working 🎉

// root dir
$ npm i
$ npm run dev

Reload Remix app when the package changes

But Remix only rebuilds when the apps/web folder changes, not when the package does.
Enter the brand new config.watchPaths from Remix 1.6.4!

// apps/web/remix.config.js
/** @type {import('@remix-run/dev').AppConfig} */
module.exports = {
  //...
  watchPaths: ['../../packages/sample-package'],
  //...
};

Now we run everything with a single command npm run dev at the root dir, and any changes to the package will trigger a Remix rebuild 😁

Build

Run npm run build at the root dir and it's done.

Deploy

We didn't change the publishing process for the package yet.

$ npm run build
$ cd apps/packages/sample-package
$ npm version <major|minor|patch>
$ npm publish

In order to deploy the web app to Netlify, we need one extra configuration on apps/web/nelify.toml. The rest of the file is the default generated by Remix.

// apps/web/netlify.toml
[build]
  command = "cd ../.. && npm install && npm run build"
  ...

We're done! Our basic workflow is much simpler. Clone the repo, install dependencies and everything is ready to run. It's much easier to have more people handling the code of the package.
Merge a PR to main and the website updates, no need for extra steps.

There's certainly room for improvement as we're just scratching the surface of what this structure can do. But for now, that's the job we needed to be done.

How to preview a SPA + API app before merging a PR

Felipe Freitag Vargas — Thu, 30 Jun 2022 19:03:14 +0000

The problem

How to test a SPA + REST API app before merging the pull request, if its parts are hosted in multiple platforms?

We have multiple teams working on separate projects at Seasoned. All of them consist of a React SPA on Netlify plus a Rails API on Heroku. All the code is on Github.
In the beginning of 2022, we moved each project to its monorepo and changed our CI to use Github Actions.

Whenever a dev opened a PR, if it changed only the SPA code, we would have a nice Netlify deploy preview automatically. Reviewers could use a version of the app instead of relying just on unit tests and screenshots. Devs could open draft PRs to ask for help and others could see what they were seeing without needing to clone the branch.

But if the API code had changed, there was no way to test it live. We'd need to either merge it to staging, or the reviewer had to checkout the branch locally and run the whole app. This meant more friction, longer QA cycles, and fewer people helping each other across teams.

What we want

Heroku has a nice feature called review apps. It seems to do what we need: it creates a temporary app for each open PR. The challenge becomes making Netlify preview and Heroku review apps talk to each other, and having something on the database so anyone can test the review app easily without doing tons of setup.

The end result we want looks like this:

Dev opens a pull request
Netlify creates a deploy preview
Heroku review apps deploys the API
Action leaves a comment on the PR with a link to the SPA
Anyone on the team can look at the PR, click a link, and use the app as if it were the staging environment.

We need a few things in order to have a working app:

- SPA knows the API URL
- API knows the SPA URL
- API has the staging database

Here's how we solved each of these challenges.

How to make the SPA know the correct API URL

React knows the API URL from an env var set on Netlify.

// App.js
process.env.REACT_APP_API_URL

We needed to make this value be generated at build time.
None of the Netlify environment variable options seemed flexible enough for this use case.

Time for some good ol' Javascript. I changed the API URL inside React to a function:

// App.js
const getBaseURL = () =>
  window?.env?.REACT_APP_API_URL ?? process.env.REACT_APP_API_URL

In other words, if there is a global value for the API URL, use that one instead of the environment.

And added this to public/index.html:

<!-- index.html -->
<head>
...
    <script src="%PUBLIC_URL%/env-config.js"></script>
...
</head>

This script needs a single line:

// public/env-config.js
window.env = { REACT_APP_API_URL: '<some-api-url>' }

Now all we need to do is create a public/env-config.js at build time and the SPA will use that API URL. We do not need to change anything for staging and production, since those already have their env configured correctly.

Github Actions give you full control, so it's easy to run some shell script to prepare that file. We do need a predictable API URL, and fortunately Heroku Review Apps gives us that. We chose this format:
https://<staging-api-app>-pr-<pr-number>.herokuapp.com

Here's how we did it inside a Github Action workflow:

# .github/workflows/deploy-preview.yml
name: Deploy preview

on: 
  pull_request:

defaults:
  run:
    working-directory: web # This is a monorepo, only run if the SPA directory has changes

env:
  staging-api: <heroku-staging-app-name>
  netlify-app: <netlify-staging-app-name>
...
# Do all your Node setup, caching, etc
...
  build-and-deploy:
    name: Build and deploy
    needs: install
    runs-on: ubuntu-latest
    steps:
...
# Checkout code, install, etc
...
      - name: Set API app and Netlify alias from PR
        run: |
          echo "REACT_APP_API_URL=https://${{ env.staging-api }}-pr-${{ github.event.number }}.herokuapp.com" >> $GITHUB_ENV
          echo "NETLIFY_ALIAS=deploy-preview-${{ github.event.number }}" >> $GITHUB_ENV

      - name: Build and deploy to netlify
        run: |
          echo "Using API URL: ${{ env.REACT_APP_API_URL }}"
          echo "Using Netlify alias: ${{ env.NETLIFY_ALIAS }}"
          echo "window.env = { REACT_APP_API_URL: '${{ env.REACT_APP_API_URL }}' }" > public/env-config.js
          export NETLIFY_AUTH_TOKEN=${{ secrets.NETLIFY_AUTH_TOKEN }}
          export NETLIFY_SITE_ID=${{ secrets.NETLIFY_SITE_ID }}
          npx netlify deploy --build --context deploy-preview --alias ${{ env.NETLIFY_ALIAS }} -m "PR ${{ github.event.number }} ${{ github.head_ref }} commit ${{ github.sha }}"

It's also nice to comment a link to the deploy on the PR:

     - name: Comment link to deploy
        if: github.event.name == 'pull_request'
        uses: marocchino/sticky-pull-request-comment@v2.2.0
        with:
          header: deploy-preview
          recreate: true
          message: |
            Deploy preview link: <https://${{ env.NETLIFY_ALIAS }}--${{ env.netlify-app }}.netlify.app>
            Latest commit deployed: ${{ github.sha }}

Check the full Deploy Preview workflow. It has some more things than what was shown here.

How to create Heroku Review apps

We followed the docs and enabled Review Apps from the Heroku Dashboard itself. We used the same env vars as the staging environment. The URL pattern must match the one the Github action uses: https://<staging-api-app>-pr-<pr-number>.herokuapp.com

Review apps don't have a default setup, so we needed to add an app.json file. It must live in the root dir.

We use the inline buildpack strategy from this article in order to deploy only the api folder. The git push subtree strategy doesn't work here because we're using the automatic review app deploy.

We need to do a few things after the initial configuration:

The API needs the staging database
The API needs to know the SPA URL

The best place we found to make that was inside the postdeploy script. Time for some more shell scripting. By the way, shellcheck made this so much easier.

/* app.json */
{
  "environments": {
    "review": {
      ...
      "scripts": {
        "postdeploy": "bin/postdeploy"
      },
      ...
  }
}

This script is great because it runs only when the app is created, and not on subsequent pushes. That means we won't be reseting the database all the time.

We chose to copy the Staging database instead of preparing a DB seed because our projects have already been running for years. Preparing and maintaining a seed would be a lot of work, while the teams are already setup to use staging.

Using Postgres, it was pretty straightforward to copy the whole staging database:

# api/bin/postdeploy.sh
psql -c "DROP SCHEMA public CASCADE; CREATE SCHEMA public; GRANT ALL ON SCHEMA public TO public;" "$DATABASE_URL"
pg_dump -Fc "$STAGING_DATABASE_URL" | pg_restore --verbose --no-acl --no-owner --dbname "$DATABASE_URL"

We used the platform API to configure the PR-dependent environment variables:

# api/bin/postdeploy.sh
curl -n -X PATCH https://api.heroku.com/apps/$HEROKU_APP_NAME/config-vars \
  -d "{
  \"REACT_APP_URL\": \"https://deploy-preview-$HEROKU_PR_NUMBER--<netlify-staging-app.netlify.app\" \
  -H "Content-Type: application/json" \
  -H "Accept: application/vnd.heroku+json; version=3" \
  -H "Authorization: Bearer $HEROKU_API_KEY"

We need one last thing: to run Rails migrations again, since we droped any migration changes the PR might have introduced.

# api/bin/postdeploy.sh
rake db:migrate

It works, but it takes minutes to build the review app. Let's use a shared cache buildpack to speed things up. We set the staging app name to an env var and now our build copies the cache from there, then runs the bundler and updates anything that it needs.

Check the full code: app.json, postdeploy script.

Testing

Now all we need to do is open a PR. Heroku will deploy the review app, Github actions will deploy the SPA, and we'll receive a nice comment on the PR with the link to see the app running 🎉

There is a caveat. Since we're using the free Heroku PG add-on, the Review App will have limitations. At the time of writing, this limit is 10k rows in the DB. Once this limit is reached, the DB will disable write operations after 7 days. But even if your PR stays open that long, you can close and reopen it to recreate the review app and it will work again.