DEV Community: Akos

A Brief History of Web Development

Akos — Wed, 27 Dec 2023 11:16:31 +0000

The most thrilling days of web development are happening now. We have access to the best tools, making website and web app development an unparalleled experience. Faster, more efficient solutions are being developed monthly, causing the entire field to evolve like there's no tomorrow.

But it hasn't always been like this.

About twenty years ago, when I made that first website for the kindergarten where my mother worked, the coolest thing was the marquee effect that I just recently learned has been deprecated. 💔

Meet Macromedia Dreamweaver, where web development started for me:

But once I figured I could not only drag and drop things on the canvas, but there's this HTML view, and some say there's even a PHP server somewhere that can manipulate and store data, there was no going back.

This is where my history of web development started.

Request-response

I considered PHP as an extension on top of HTML altough this wasn't completely true.

I could already create mindblowing static sites using the right amount of marquee (RIP 💔), but tapping into a data source on the server made me feel like Neo.

<!DOCTYPE html>
<html>
  <body>
  <?php
    $sql = "SELECT username FROM users WHERE id = 1";
    $result = $conn->query($sql);
    echo "<h1>Welcome, " . $user_username . "!</h1>";
  ?>
  </body>
</html>

I'm not sure if this is how PHP looks today. Hashnode's AI code generator gave this to me, and it certainly looks like something I wrote!

Using this tech, I built my first SaaS right before the year I went to the university. It was a phpBB-like forum for our middle school. Using the same stack, I wrote an even bigger app used as a nationwide registration system for a national mathematical competition.

I didn't know what SaaS or being productive as a programmer meant back then because I just dabbled with these things.

15 years later, it's an absolute yes. HTML, CSS, PHP, and MySQL made me extremely productive. And I haven't used JavaScript at this time. I used maybe snippets I found on the internet, but I showed no interest in learning it because I didn't need it.

The apps I've built in those years mostly looked like current government websites:

Remember clicking that submit button a couple of times?

Ajax responses, the first spinners

It didn't take me long to realize the value of Ajax. Suddenly, I didn't need full page reloads to show dropdowns with different values or to disable a Submit button when the request was already processing.

Ajax improved the user experience by adding a slight cost to the maintenance.

At this time, most of my applications were still 99% PHP, HTML, and CSS. Fast forward 4 years to my graduation.

I learned a whole lot of Java at the university and continued selling websites as a side hustle until I landed my first developer job in January 2012.

JSF (Jakarta Server Faces) was popular then, and the company I worked for was bullish on enterprise Java.

Looking at you, ReponseTaskServerAdapterPropertyObserverSetter.

We built web apps that looked like desktop apps, which were incredibly painful to develop, deploy, and maintain.

They looked like this:

JSF wanted to be a silver bullet; we didn't use much pure HTML because JSF libraries had components for buttons, inputs, autocompletes, etc. But it was a world full of promises and a horrifying development experience.

The SPA revolution

SPAs came like a savior.

Once we realized we could expose REST APIs on the server and write our entire client in JavaScript, our productivity reached HTML, CSS, and PHP levels again.

The client apps resembled what you would have today in a React application.

// bundle.js
var message = new Message();
var messageView = new MessageView({ model: message });

$('#root').append(messageView.render().el);

// index.html
<html lang="en">
  <body>
    <div id="root"></div>
    <script src="/bundle.js"></script>
  </body>
</html>

A nothingburger and a client app packed into a ginormous bundle.js file.

The bundle got to the client, but it had to fetch some data to render the app first.

And this is when our apps started to have more of these:

The Spinner Hell

But it was not just the spinners. This client-rendering behavior introduced a whole lot of other issues, like layout shifts:

https://web.dev/static/articles/cls/video/web-dev-assets/layout-instability-api/layout-instability2.webm

The bundle sizes got out of control unless you were really, really careful. You could have gzipped a date library that added 50kB to your bundle size when you could have converted the timestamp from the db into a human-readable format before sending the response!

Websites felt slower, but the spinner kept spinning, giving us some hope.

RSC, Remix

Up until now, we simply didn't have better ways to deal with this problem other than maybe using UI skeletons. They weren't a perfect solution either, and they looked weird when they got out of sync with the rest of the app.

React Server Components are an idea to tackle this problem with an initial implementation, but not much acceptance from the community yet.

Ryan Florence wrote an excellent blog post about the key differences, both in theory and in practice, between RSC and Remix in React Server Components and Remix.

To sum up, React Server Components follow the Render-Fetch waterfall. This means the component gets rendered first and then it fires a fetch.

In contrast, Remix uses the Fetch, Then Render waterfall, which is closer in behavior to what we had before the spinner armageddon.

Remix's loader does all the fetches, and when they're ready, only the result (component populated with the result of the loader) is returned to the browser.

Remix acts like an SPA on subsequent navigations and fetches only the necessary data to show the view.

See what happens after I switch between /me and /settings:

Hitting /me for the first time, retrieves the simple HTML page already pre-populated with the data no need for loading spinners.

Kind of like in:

<!DOCTYPE html>
<html>
  <body>
  <?php
    $sql = "SELECT username FROM users WHERE id = 1";
    $result = $conn->query($sql);
    echo "<h1>Welcome, " . $user_username . "!</h1>";
  ?>
  </body>
</html>

But switching back and forth between the /settings and the /me page fetches only what's necessary a JSON containing the data needed to display /me.

Why this changes everything

Instead of going with the overused "Next.js is PHP now" memes, I want you to think about where it all started and how far we've come.

This is an evolution.

It's all about constantly changing, trying new things, keeping what worked, and leaving behind what didn't.

From marquee 💔, PHP/HTML/CSS, to JSF, and the painfully slow deployment times that made web development with Java an absolute nightmare, back to a much simpler render request-response cycle.

Today, we can pick from the best tools the industry offers.

They all provide a lot better development experience than I could have imagined 20 or 10 years ago.

Congrats to the Next.js and the Remix teams for their fantastic job and community support.

I hope the React team will finalize the RSC Next year and everyone can use it to their fullest potential to build even better apps.

Your Guide to Testing React Components

Akos — Thu, 21 Dec 2023 09:21:13 +0000

This blog post gives you a bird's eye view of the different ways to test your React components and some ideas for converting your tests from Enzyme to React Testing Library.

One of my most significant projects this year was moving the Enzyme tests of a gigantic fintech application to React Testing Library (that's a mouthful, so I'll use RTL in the text).

While there are tools to automate this process, we didn't want to simply write the equivalent of the enzyme tests in RTL but also improve the existing tests and cover previously untested behaviors. We learned a lot about how to find alternatives to the "Enzyme way" of testing, like prop assertions.

So this year, I wrote mainly about testing React Components.

As a result, the Testing React series was born, containing eight articles so far:

https://akoskm.com/series/react-testing

So, let's dive into it and see what to use and when!

Component Props

If you read only the first article of the series, you're already good to go. How to test props in React Testing Library presents you the simplest way to prop testing: mocking your component and, instead, the real thing returning a string that prints out the props, something like this:

jest.mock("./PermissionsContainer", () => ({ profileId }) => `This is PermissionsContainer profileId:${profileId}`);

While this works great for most components, sometimes you run into two issues with this approach:

the prop is an object that's huge when stringified
the rest of the test relies on the behavior of the component that you mocked

This is why I edited the blog post and provided an alternative to this approach that lets you assert prop values but also call the actual component:

const permissionsContainerMock = jest.fn();jest.mock('./PermissionsContainer', () => (props:any) => permissionsContainerMock(props));test("renders Container with the correct props", () => { permissionsContainerMock.mockImplementation(props => { const Profile = jest.requireActual('../components/Profile').default; return <Profile {...props} />; }); // expect(permissionsContainerMock).toHaveBeenCalledWith(your props);});

These two approaches will get you covered for prop testing and turning those Enzyme component.prop tests into RTL.

Component Hooks

Hooks are incredible mechanisms in React that help you abstract and share some logic between components.

Usually, you want to test them with your component code, but some hooks are too complex to be verified with the component.

This is why the RTL team gave us renderHook that lets you render your hook and verify how it behaves while loading, receiving new arguments, etc.

    const { result } = renderHook(() => usePermissionsHook("1234-fake-4567-uuid") ); expect(result.current.isLoading).toEqual(true); expect(result.current.permissions).toEqual([]);

How to Test Custom Hooks with React Testing Library and Jest gives you a complete walkthrough on testing React Hooks.

Accessing the DOM

While finding DOM elements based on CSS queries with Enzyme was easy, this is not so simple because of RTL's philosophy.

Classnames

But sometimes, you want to ensure that an alert has the warning or success styling.

In How to test a className with Jest and React testing library, I present you two ways to do this, but my preferred method is finding the text inside the alert using the selector argument of the RTL query:

render(<Alert type="error" message="Something went wrong" />);expect( screen.getByText( 'Something went wrong', { selector: '.alert.alert-error' } )).toBeInTheDocument();

This differs from what you used to do with Enzyme because RTL won't let you look only for the CSS selectors. First, you must specify a piece of text that will be visible to the user which is aligned with RTL's philosophy:

React Testing Library aims to test the components how users use them. Users see buttons, headings, forms and other elements by their role, not by their id, class, or element tag name.

Complex structures

Testing the DOM becomes increasingly more complex when you move on to headings or table structures because RTL supports many roles.

Test complex DOM structures with React Testing Library provides you with examples for testing headings and table cells.

Snapshots

If none of these methods work, you can still use Snapshot testing; that's a great way to assert complex DOM structures that rarely change. I found an excellent application: checking if the component rendered the right SVG.

SVGs are sometimes too long to put into a test, and once you know you have the SVG for your "Home" icon, it rarely changes.

Jest Snapshots: Beginner's Guide to Snapshot Testing helps you get started with snapshot testing.

Getting Better

Not exclusive to RTL or React Component testing, but after seeing so many tests and good/bad patterns, I felt the need for an article discussing strong vs. weak tests.

How to Write Stronger Unit Tests with Jest gives you hints on how to write better tests with almost no extra effort.

Getting Faster

On the bright side, if you've reached this point, you have many tests! Handling their slowness might seem like a good problem to have.

Well-known testing mechanisms such as beforeEach/all can encapsulate the repeated parts of your tests, but remember, they add to the runtime of each test.

How to speed up your integration tests, through a practical example, shows you how we speeded up our CI time.

Conclusion

Finally, I'd like to balance out all this testing with one of my favorite tweets:

// Detect dark theme var iframe = document.getElementById('tweet-807626710350839808-928'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=807626710350839808&theme=dark" }

Don't dive straight into writing unit tests if you don't have an automated method for verifying the essential functionality of your app.

Spend your and your team's time where it makes the most sense.

Do everything with moderation, including unit tests.

Creating a CI/CD Pipeline with Docker and GitHub Actions: A Step-by-Step Guide

Akos — Fri, 15 Dec 2023 15:52:58 +0000

We all love shipping new features and building stuff probably the main reason we're programmers!

And web development doesn't have to be any more complicated unless... something breaks.

When something breaks, it can bite you for two reasons:

You must find what broke and when this is quite challenging. It could be that the thing that doesn't work now has been broken for weeks or even months, but you just realized it!
Bugs cost you money imagine launching some Cyber Monday deals for the users of your fresh SaaS with the payment system broken.

As someone who has experienced both issues, setting up a CI/CD pipeline is one of the first tasks I undertake for projects I intend to launch.

But what is CI/CD, and why are they almost always mentioned together?

Terminology

CI

CI stands for Continuous integrations. When you change your application code, you'd like it to work with the rest of the code. CI helps you verify this.

Without automation, you'd test all app functionality manually before shipping the change to the users. With automation, these changes are tested as part of CI.

Running a linter or the TypeScript compiler is a great way to start your CI workflow. They catch early bugs fast and prevent your more resource-intensive steps, such as unit or integration tests, from running.

Once the CI step is done, you're confident your new code works with the rest of the code.

CD

CD is showtime. 🚀 It's time to ship this change to your users, usually by deploying the app on a remote server. But for desktop applications, it means packaging and uploading the executables to storage.

Because of this, I use CD as an acronym, Continuous Delivery, and not Deployment not everything is a web app and can be deployed.

Whatever you do, at this point, CI has already given you the confidence that you're ready to move forward and introduce this change to your users.

GitHub Actions

GitHub Actions is a feature of GitHub for CI/CD within your GitHub repository. It allows you to create custom workflows to build, test, package, release, or deploy your code based on specific triggers such as a push event, a pull request, commits, etc. Workflows consist of one or more jobs , which are series of steps that run commands.

Adding CI to your existing project

First, we'll build a simple CI workflow that will run tsc when we make a commit. Creating a workflow starts with creating a workflow file.

Creating a Workflow file

Jump into your project's root directory and create the file .github/workflows/main.yml:

mkdir -p .github/workflowstouch .github/workflows/main.yml

The first command creates the folder structure (make sure you use -p otherwise you'd have to create the .workflows folder separately) and the second creates an empty file.

Open this file and then proceed to the next step.

Adding steps to your workflow file

There are three elements of a workflow file you need to define:

name: Deploy to Digital Oceanon:jobs:

name the name of your workflow.
on a rule that describes when this workflow is triggered.
jobs - you can have as many jobs as you want. GitHub Actions jobs run in parallel. This means that if you have multiple jobs defined in your workflow, they will all start running simultaneously when the workflow is triggered. You can also make them dependent on each other with the needs keyword, but we'll explore that next time.

The steps listed in jobs can be many things:

single line commands such as copying files or logging parameters
running npm, yarn, or any other executable on the system
running other GitHub actions

Example of a workflow file

If you want to work with your repository in the workflow and what else you would do anyway the workflow must access it.

We already mentioned that GitHub Actions can run other GitHub actions. Luckily, there's a GitHub action for checking out the current repository's source code. You'll be using it like this:

jobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4

Now that you have the source code in place, you can do npm install and do some type-checking.

Here's how the workflow will look like that does all this:

name: Deploy to Digital Oceanon: push: branches: - main # Set a branch to deploy when pushedjobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Install run: npm install - name: Run Typecheck run: npm run typecheck

Testing the workflow file

It's time to commit and push these changes to our main branch. Once you open the commit history, you'll notice a appeared next to your commit message.

This indicates that the commit triggered a workflow run. Click the to explore further.

You recognize the steps from our workflow file:

Great job! You just triggered your workflow run that will automatically check for TypeScript errors every time a commit is made to the main branch!

Server Setup - AWS/DigitalOcean

Now that we have some basic checks in place and the confidence in our codebase has grown, it's time to deploy our application.

Deployment options

There are countless options for where to deploy your application, and new ones are added almost every month.

Choosing a service provider is not an easy task, but I have two go-to solutions:

DigitalOcean - I use it most of the time. Suitable for small MVPs as well as for more complex apps. Super versatile and easy to use. Simply pricing, fixed-price instances.
AWS - endless solutions, a lot more complex, but it's more feature-rich. DigitalOcean runs on AWS. Pay-as-you-go model - takes some time to understand, but it's flexible.

Luckily, both let you rent a single server instance that you can connect to with SSH and deploy your stuff, set up a database, and other applications that will support your main app, and so on.

Deployment Overview

On a high level, for both providers, you have to do three things:

Generate a pub/private key pair locally
Create a server on the platform EC2 for AWS, Droplet on DigitalOcean
Tell the server to trust the pub key I'll describe this later
SSH into the server and deploy your app using Docker

Create a Server

You'll need a passwordless keypair for both providers.

To create one use ssh-keygen -t ed25519 -a 100 -f ~/.ssh/deploy_key_aws. To make it passwordless, simply don't specify a password when prompted.

AWS

Sign up for AWS
Go to Key pairs and do Import key pair. This is the only way I found to import locally created keypairs to AWS and avoid using their pem keys - that you have to download, store, etc. Click Browse under Key pair file and upload ~/.ssh/deploy_key_aws.pub. Click Import key pair. You can also follow the official docs here.
Create an EC2 Instance, and at the Key pair (login) section, specify the keypair you imported. If you have an existing instance, see the docs here.
Launch the instance

DigitalOcean

Sign up for DigitalOcean with my referral link or by going to www.digitalocean.com. In the sidebar, click Droplets, choose Create Droplet, and follow the wizard. You'll find the detailed instructions on creating your first Droplet from the Control Panel here.
Copy the public key value. You can print it to the console using cat ~/.ssh/deploy_key_aws.pub.
Create a Droplet
Connect to the Droplet using their Console
Open the file .ssh/authorized_keys
Add the value of Step 2. as a new line in this file and save the file

Docker Setup

Neither the DigitalOcean Droplet nor the AWS EC2 instance will have docker installed by default, so you have to follow the official guide to install and set them up correctly:

AWS

This could be a guide for itself, but GitHub Copilot told me these are the steps and they worked.

Log into your AWS EC2 machine and run the following:

sudo yum update -ysudo yum install dockersudo service docker startsudo usermod -a -G docker ec2-usersudo chkconfig docker on

Log out and log back in again to pick up the new docker group permissions. But you don't have to do this because we'll deploy from GitHub Actions anyway.

DigitalOcean

They actually have a guide! 👏

https://www.digitalocean.com/community/tutorials/how-to-install-and-use-docker-on-ubuntu-22-04#step-1-installing-docker

Don't read the whole thing, just Step 1 and Step 2.

Adding CD

Now, you'll connect your GitHub workflow to one of these servers and deploy your application.

You'll use Docker Hub to store the images and Docker to deploy them.

You'll find a detailed guide on Dockerizing your Node.js applications in How to Publish Docker Images to Docker Hub with GitHub Actions .

For this guide, I'll assume you already read the previous guide and successfully dockerized the app you want to deploy.

The previous guide ended with building and pushing the image to Docker Hub, pulling and running it locally.

This time, instead of running it locally, you'll SSH into the AWS EC2 or Digital Ocean Droplet, pull and deploy the app there.

To do this, extend your workflow file .github/workflows/main.yml with the following:

name: Deploy to Digital Oceanon: push: branches: - main # Set a branch to deploy when pushedjobs: deploy: runs-on: ubuntu-latest steps: # this is unchanged # checkout & typescript checks # pushing the image to docker hub - see the link above - name: SSH and deploy to AWS EC2 uses: appleboy/ssh-action@master with: host: ${{ secrets.AWS_EC2_IP }} username: ${{ secrets.AWS_EC2_USER }} key: ${{ secrets.AWS_EC2_SSH_KEY }} script: | docker pull akoskm/saas:latest docker stop saas_container docker rm saas_container docker run -d --name saas_container --env-file .env -p 3000:3000 akoskm/saas:latest

This GitHub action uses appleboy/ssh-action to log into the target machine specified by AWS_EC2_IP and using the credentials AWS_EC2_USER and AWS_EC2_SSH_KEY.

These will be your Action Secrets, which you must create by going to repository Settings. Select Secrets and Variables > Actions in the sidebar and click New repository secret.

Here's how to find the values for all three secrets:

AWS_EC2_IP - Get information about your instance to find out the IP address of your EC2 - screenshots included.
AWS_EC2_USER - the value of this, as I'm writing the blog post, is ec2-user. If this changes, it'll probably be updated in Connect to your Linux instance from Linux or macOS using SSH.
AWS_EC2_SSH_KEY - this is the value of the passwordless key we created in Create a Server. Run cat ~/.ssh/deploy_key_aws and use that as the value.

Testing CD

Push a new commit to the main branch and watch the workflow trigger. Compared to what you were seeing in Testing the workflow file previously, you should have these additional steps:

Congratulations, you just created a fully integrated CI/CD workflow for your application!

Conclusion and further improvements

CI/CD doesn't stop here! While this was enough to get you started, here are some more ideas:

include in the workflow your unit and integration tests
create a workflow that deploys to a staging server from a development branch and a workflow that deploys to production from main
try creating multiple jobs inside the same workflow file. You could create a static-checks job that runs npm install, build, typechecks, and lint, and a deploy job that builds the image and deploys it, but only if static-checks is successful. See jobs.<job_id>.needs.

Good luck with taking your app development workflow to the next level.

I understand this process is not trivial, so if you have any questions, please reach out to me on X @akoskm or in the comments.

Thanks,

Akos

The Ultimate Full Stack Framework for 2024: Remix

Akos — Wed, 13 Dec 2023 09:46:17 +0000

It's been eleven years since I set foot in the world of full-stack development. This path was not chosen out of preference, but rather out of necessity. Working with small companies from the start, the only chance to advance was to be as versatile as possible.

I appreciate the technology I can work with today, as it hasn't always been this impressive.

Between 2012 and 2014, our local environment's reload time after making changes to HTML or CSS was measured in minutes. Java, JSF, and J2EE marked my entry into full-stack development. Although it felt enterprise-like on the backend, frontend development was a nightmare.

This forced us to explore ways of shipping frontends separately from the backends. This is how I discovered, Backbone.js, Angular, and later React. Since 2014, I have used CRA, Next.js, and Razzle around React, but nothing felt as right as Remix.

Let me explain.

Separation of concerns

If I think about these years, this separation has always existed in some form.

There was the server and the client. Two separate projects. Context switching, or at least project-switching all the time.

Let's say you were working on a simple TODO app, and you wrote this frontend code:

import React, { useState } from 'react';

const TodoComponent = () => {
  const [title, setTitle] = useState('');

  const handleSubmit = async () => {
    await fetch('/todo', {
      method: 'POST',
      headers: { 'Content-Type': 'application/json' },
      body: JSON.stringify({ title }),
    });
  };

  return (
    <div>
      <input
        type="text"
        value={title}
        onChange={(e) => setTitle(e.target.value)}
        placeholder="Enter todo title"
      />
      <button onClick={handleSubmit}>Add Todo</button>
    </div>
  );
};

export default TodoComponent;

This is great, but is there anything else /todo expects besides the title? What I would do at this point is open up the API endpoint implementing POST /todo:

import { addTodo } from "~/todoStore";

app.post('/todo', (req, res) => {
  const { title, description } = req.body;

  if (!title || !description) {
    return res.status(400).json({ error: 'Missing required fields' });
  }

  addTodo({
    title,
    description
  });

  res.status(201).json({});
});

And then, I would figure out that I must provide description too. Back to the frontend code, add a new field, send it to the backend, and so on.

The Remix way

In Remix, when I want to create a simple Todo form that accepts some text input and sends it to the backend, I do:

everything in the same file
without registing an endpoint in a router
without importing all kinds of wrappers and reading framework-specific documentation

Remix builds heavily on existing Web APIs, which I think is the reason why it can stay so lean.

If you write a Todo form with a single input and an endpoint that records that input, it would all go into the same file and look like this:

import { json } from "@remix-run/node";
import type { ActionFunctionArgs } from "@remix-run/node";
import { Form } from "@remix-run/react";
import { addTodo } from "~/todoStore";

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const { todo } = Object.fromEntries(formData.entries());
  await addTodo(todo);
  return json({ ok: true });
}

export default function Index() {
  return (
    <Form method="post">
      <label htmlFor="todo">Item name</label>
      <input type="text" name="todo"/>
      <input type="text" name="description"/>
      <button>Add</button>
    </Form>
  );
}

Sorcery, right?

Backend and the frontend, next to each other.

Here's what else you see above:

Form - a Remix way of doing <form>. If you would submit this plain form with a <button> you would actually make a POST request to the server. However, with Form Remix realizes this POST intent, intercepts it, and turns the POST into a fetch.

action - this is the default action invoked by submitting the only form on this page. Inside action you're writing your backend code.

No more states

Form Inputs

Totally unexpected, but throughout the building of my SaaS boilerplate with Remix, I used useState once in the entire project:

This was surprising, given that I have a Sign-up form separate for users and organizations, a Sign-in form, a User invite, and an edit form.

That's a lot of forms!

Yet, as you saw from the example above, because of how Remix handles form submissions, in most cases your usual:

const [email, setEmail] = useState('');

onChange={(e) => setEmail(e.target.value)}

isn't necessary.

Loading states

Indicating the loading state and disabling buttons at the right time are all something we've done.

And we probably did it like this:

const [loading, setLoading] = useState(false);

async function handleSubmit(data) {
  setLoading(true);
  await fetch(...);
  setLoading(false);
}

Remix handles this (and a bunch of other common use cases) with its built-in hooks. One of them is useNavigation. It's a simple hook that returns you the current state of the page navigation:

idle - the page is idling, no requests are being made
submitting - an action is being called, likely after a form submission
loading - The loaders for the next routes are being called to render the next page - we didn't discuss loaders here, but check them out.

Based on navigation.state, you always know if there is an action running on your page or if it's just idling. If it's the latter, it's probably safe to remove that loading indicator or re-enable that button.

Standards

I highly recommend you go over the 30-minute tutorial of Remix that explains how it works in-depth.

Remix builds on "old-school web" instead of reinventing the wheel. The way a form POST is turned into fetch requests is a good example of that.

It encourages the use of existing Web APIs. This is from their landing page:

Remix is a full stack web framework that lets you focus on the user interface and work back through web standards to deliver a fast, slick, and resilient user experience. People are gonna love using your stuff.

Which I think summarizes what Remix represents.

It also encourages you to think differently and use web standards. This is how, probably for the first time ever, I found a platform API for something that I always used a library for:

// Detect dark theme var iframe = document.getElementById('tweet-1730226106018476324-244'); if (document.body.className.includes('dark-theme')) { iframe.src = "https://platform.twitter.com/embed/Tweet.html?id=1730226106018476324&theme=dark" }

Conclusion

I gave Remix a shot without any big expectations, and it blew me away. Guess this is when they say to underpromise and overdeliver.

I'll keep using Remix for my future projects. The one I'm building is a SaaS boilerplate that combines Remix with FusionAuth, a customer authentication and authorization platform. Another tool that makes developers' lives awesome.

Huge congrats to the Remix team.

Make sure to check out their website and join their Discord.

How to Publish Docker Images to Docker Hub with GitHub Actions

Akos — Wed, 13 Dec 2023 08:56:03 +0000

Docker has been gaining popularity ever since because it provides a simple way to package your code and ship it as a runnable image.

Docker also brings you Docker Hub, where storing your images is free.

Combined with GitHub Actions, you automate the process of building and pushing images to Docker Hub.

This is one of the most cost-effective ways to deploy MVPs and most of your web apps. This is how I'm doing it, so I wanted to share my process here.

I assume you have a Node.js application you want to Dockerize and deploy, and you have Docker installed on the machine or where you want to deploy the image. If not, see Install Docker Engine (I also use Docker Desktop locally).

Terminology

Docker image: An image is a read-only template for creating a container. It's often based on another image with added customizations. For instance, you might build an image using the Ubuntu base but include your application.
Dockerfile: simple syntax for defining the steps needed to create and run the image.
Docker container: a runnable instance of the image.

Create the Dockerfile

Open your Node.js project, and in the root directory, create a file Dockerfile.

This file describes how your application should be packaged and run. Some of these commands are self-explanatory, but I added comments to make things clear:

# Use a base image with the latest Node.js LTS installedFROM node:20# Set the working directory inside the containerWORKDIR /app# Copy package.json and package-lock.json to the working directoryCOPY package*.json ./# Install dependenciesRUN npm install# Copy the rest of the application code to the working directoryCOPY . .# Build the appRUN npm run build# Start the appCMD ["npm", "start"]

Building and running your image locally

Before we dive into how to automatize this, let's make sure that this actually works.

Build

To create a Docker image using the Dockerfile you just made, run the following command in your command line:

docker build -t my-image:latest .

The format is always [name of the image]:[tag]. This will help you better organize your images and align with how other docker images are named.

After the command runs, type docker images to list the images on your machine. I have a bunch of them, but you can see my-image that I've just built:

Run

Running the image will start a container based on the image. You can run docker ps to list the currently running containers.

To run the image you just created, type this into your command line:

docker run my-tag

Imagine docker containers like machines on your local network. They have their network inside the container that, by default, you can't access. If you spin up a Node.js app inside the container, you can't access it unless you expose the container's specific port to your machine. So, for example, if your Node.js app is running on port 3000, you might want to run the above command with the -p argument that does this:

docker run -p 3000:3000 my-image

This command starts a new Docker container just as before, and the -p option maps port 3000 of the container to port 3000 of the host.

If you want to supply environment variables from an .env file to your application, use the --env-file flag.

To run the image in background mode, add the -d flag:

docker run -d -p 3000:3000 --env-file .env my-image

To list the running docker containers after this command type docker ps:

I ran the image using the above command, and it showed up in the running containers after I typed docker ps again.

Create a DockerHub account

To easily deploy our images on different locations, for example, on an AWS EC2 instance or a DigitalOcean droplet, you need a way to distribute them.

This is where Docker registries come into play. Docker Hub is a public registry that anyone can use, and Docker searches for images on Docker Hub by default. You can also run your private registry.

You can create a Docker Hub account here if you haven't already.

Create a GitHub Actions workflow

Now that you have ensured our image works, it's time to automate building and uploading it to Docker Hub using GitHub Actions.

If you're new to GitHub Actions, check out Understanding GitHub Actions.

Start by creating a .github/workflows/main.yml file in your project's directory with the following contents:

name: Deployon: push: branches: - main # Set a branch to deploy when pushedjobs: deploy: runs-on: ubuntu-latest steps: - name: Checkout code uses: actions/checkout@v4 - name: Install run: npm install - name: Run Typecheck run: npm run typecheck

Here's what's happening above:

The workflow triggers the deploy job on a push into the main branch
The deploy job checks out the codebase and runs some checks on it. You do this because the following steps are expensive - they might last several minutes - and you don't want to package anything broken. This is the best time for your static analysis tools.

Push the image to Docker Hub

After the checks have passed, let's publish our image to Docker Hub. Extend your workflow with two more steps:

name: Deployon: # No changesjobs: deploy: runs-on: ubuntu-latest steps: # No changes - name: Login to Docker Hub uses: docker/login-action@v3 with: username: ${{ secrets.DOCKERHUB_USERNAME }} password: ${{ secrets.DOCKERHUB_TOKEN }} - name: Build and push uses: docker/build-push-action@v5 with: push: true tags: akoskm/my-image:latest

First, you log in to your Docker Hub account using your username and the token you created as described in Create and manage access tokens. Notice that I added akoskm as a prefix to my image name and tag. You'll have to use your Dockerhub username here.

Then, build and push the docker image to the Docker Hub repository.

After this is complete, you'll find the new image in your DockerHub Repository:

Pull and run the image from DockerHub

Now that you pushed your image to DockerHub, you can pull it on any machine with Docker installed. As mentioned earlier, Docker searches for images on Docker Hub by default.

So, for example, after logging in to your AWS EC2, you can run the following command:

docker pull akoskm/my-image:latest

Finally, run your image as before:

docker run -d -p 3000:3000 --env-file .env akoskm/my-image:latest

I hope you found this article helpful and that it will make your next app launch easier!

If you enjoyed the article, please consider liking it and, more importantly, sharing it with those who might find it useful!

Want to see this in action? Check out my SaaS boilerplate app that I'm building with Remix!

For questions, suggestions, or help, reach out to me on X @akoskm or in the comments.

Thanks,

Akos

How to handle multiple form actions in Remix

Akos — Thu, 07 Dec 2023 08:30:10 +0000

Form actions in Remix are handled by the action function that runs on your server. They work very much like loaders, except they're called when you make a DELETE, PATCH, POST, or PUT to your route.

Remix's action/loader structure is incredibly straightforward and easy to grasp! If you've got some experience with data flow in client-server applications, you'll find this a piece of cake. But before we answer how we can handle multiple form actions in Remix, let's understand how the data flow works.

The Remix Fullstack Data Flow

In the Remix Fullstack Data Flow, the loader fetches data from the backend and passes that data to your component. The action passes your component data to the backend. After the action finishes, loaders are revalidated and return the current state of the backend to the component.

This is how Remix keeps your backend and frontend data in sync without any additional code to do refetches.

Also, in Remix each route has one loader and one action.

The issue arises when, on the client, you want to handle different functionalities, and each functionality would require a different action on the backend.

Let's take a look at this simple Todo app:

export async function loader() {
  return json({ todos: getTodos() });
}

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const { todo } = Object.fromEntries(formData.entries());
  await addTodo(todo);
  return json({ ok: true });
}

export default function Index() {
  const { todos } = useLoaderData<typeof loader>();
  const actionData = useActionData<typeof action>();

  return (
    <div className="max-w-md">
      <h1 className="text-2xl pb-10">Todos</h1>
      <Form method="post" className="flex flex-col gap-4">
        <label htmlFor="todo">Title</label>
        <input type="text" name="todo" id="todo" autoComplete="off" />
        <button>Add</button>
      </Form>
      <ul>
        {todos.map((todo) => (
          <li key={todo.id} className="text-lg pt-5">
             {todo.text}
          </li>
        ))}
      </ul>
    </div>
  );
}

There is nothing fancy here, just an input and a button to submit a todo item to your list.

The problem with multiple actions

Let's say we want to extend the functionality with a button to remove all items with a single click:

<Form method="post" className="flex flex-col gap-4">
  <label htmlFor="todo">Title</label>
  <input type="text" name="todo" id="todo" autoComplete="off" />
  <button>Add</button>
  <button>Clear</button>
</Form>

But because we have only one action handler, it doesn't matter which of these buttons we click, the action result is the same:

The solution

To work around this, we'll add two new attributes to each of these buttons: name and value.

I like to use name="intent" (reminds me of Android's Intent) and a custom value describing the action we want to run:

<Form method="post" className="flex flex-col gap-4">
  <label htmlFor="todo">Title</label>
  <input type="text" name="todo" id="todo" autoComplete="off" />
  <button name="intent" value="add">Add</button>
  <button name="intent" value="clear">Clear</button>
</Form>

Now, whenever we submit our form data, the request's request.formData will contain an additional field formData.get("intent").

We can use this value to decide what to do next:

export async function action({ request }: ActionFunctionArgs) {
  const formData = await request.formData();
  const { todo } = Object.fromEntries(formData.entries());
  const intent = formData.get("intent");
  switch (intent) {
    case "add": await addTodo(todo); break;
    case "clear": clearTodos(); break;
    default: throw new Error("Unexpected action");
  }
  return json({ ok: true });
}

And finally, here's how the UI works after taking into consideration the value of intent:

You can experiment with the above pattern in the Codesandbox I created.

How to clear form after submit in Remix

Akos — Mon, 04 Dec 2023 08:30:10 +0000

Clearing a form in React after submission is typically accomplished by setting the states containing the input values to an empty string.

In the case of a simple TodoList component, this means something like this:

const TodoList = () => {
  const [title, setTitle] = useState('');

  async function handleSubmit(e) {
    e.preventDefault();
    await fetch('/todo', {
      method: 'POST',
      body: JSON.stringify({ title }),
    });
    setTitle('');
  };

  return (
    <form onSubmit={handleSubmit}>
      <input value={title} onChange={(e) => setTitle(e.target.value)} />
      <button type="submit">Add Todo</button>
    </form>
  );
};

If you saw my post The Ultimate Full Stack Framework for 2024: Remix, you know that with Remix, you can completely avoid most of the states and still reset the form after the submission is complete.

Let's see how!

The useActionData hook

Remix provides many helpful hooks for submitting forms, inspecting if the page is loading, or automatically capturing output values of backend actions.

The hook that helps you with the latter is useActionData.

It works like this:

// server action
export async function action({ request }: ActionFunctionArgs) {
  return json({ ok: true });
}

// client
function Todo() {
  const actionData = useActionData();

  // after you fire a request to your action by submitting this form
  // after the response actionData will be { ok: true }
  return (
    <Form>
      <button>Submit</button>
    </Form>
  );
}

You fire a request by submitting the only form on the page. After the request is completed, the response is in actionData. In this case, it's { ok: true }.

We can use the value in actionData to detect that the submission was successful.

Here's how to achieve that with things built into React and Remix.

Capturing the results

When actionData first runs on the client, it returns undefined.

Because of this, we have to react (🥁) when actionData change from undefined to { ok: true }:

function Todo() {
  const actionData = useActionData();

  useEffect(() => {
    if (actionData?.ok) {
      // reset the form
    }
  }, [actionData);

  // rest of the component
}

Now, we have a way to identify that the submission is completed.

Let's reset the form!

To do that, we're going to use the HTMLFormElement's reset method.

Capturing the form

To call the reset method on the HTMLFormElement we need a way to capture a reference to it.

This is where React's useRef helps us:

function Todo() {
  const form = useRef<>(null);

  // use effect as before
  return (
    <Form ref={form}> ... </Form>
  );
}

Clearing the form

Now that we both know when the request was finished and have a reference to the form that sent the request, let's combine the above two snippets:

// server action
export async function action({ request }: ActionFunctionArgs) {
  return json({ ok: true });
}

// client
function Todo() {
  const actionData = useActionData();
  const form = useRef<>(null);

  useEffect(() => {
    if (actionData?.ok) {
      form.current?.reset();
    }
  }, [actionData])

  // after you fire a request to your action by submitting this form
  // after the response actionData will be { ok: true }
  return (
    <Form>
      <input name="title" />
      <button>Submit</button>
    </Form>
  );
}

Conclusion

I like that this approach relies on information that's coming from Remix and not from some kind of states that we manually tracked before.

The problem with such app state tracking is that it gets out of control once you add a separate state for loading indicators, error messages, disabling inputs, and buttons on form submission.

All this can be achieved with Remix's built-in hooks without using a single state. This reduces the amount of client-side logic you implement and later maintain.

Have fun using Remix!

Succeeding as a Software Developer: The Essential Mindset Shift

Akos — Wed, 29 Nov 2023 08:05:04 +0000

My developer journey began in an era that's hard to imagine.

No social media, X (Twitter), YouTube, or online courses existed.

I couldn't compare my skills to anyone because I didn't know any programmers in real life or online (you didn't really "know people online" back then).

I didn't know if I was a bad, average, or good programmer. I believe this, alone, helped me more than anything else.

It was 2001, and I bought a book about C a couple of months ago.

There was the book, and I started writing my first program.

I didn't share my progress because I had nobody to share it with, but I was happy when something worked. Okay, this is not entirely true; I demoed these programs to my parents. Although they showed signs of interest, it was probably because I was sitting in my room writing code instead of driving without a license.

I loved experiments because I had a lot of questions, but I haven't had anyone to ask.

You could run indefinite experiments with this thing called C, change variables and inputs, and see the results instantaneously. It was kind of a miracle for me.

"Will this thing work? I have no clue, but let's give it a shot!" I learned a ton by experimenting and building many apps.

Three years later, when I entered high school, I sold my PHP app to a local company. I never quit programming since (although I considered it once) and built pretty much everything that's the basis for anything we use today.

Some points originate from the difference between the Fixed and the Growth mindset, which inspired this post. Many books were created on the same topic, but here's the original I recommend reading.

Mindset: The New Psychology of Success

The book at places might sound like it was made up, and it's just another self-help crap, but hold tight during those parts. I'm sure you'll read something new or understand why you did things in the past.

My career is probably not even at 50%, but I feel there are some key elements of a successful programmer mindset that I wanted to share with you. Here they go.

Be The Beginner

Two years ago, I wrote about the advantages of seeing yourself as an amateur. Studies in the book I recommended above show that prejudice affects people's decisions negatively. This is the result of the fixed mindset.

If you assume you're a programming genius, your mind will try everything to keep this status.

First, to appear as a genius, you don't make mistakes. This implies that you never try new things and never experiment, withdrawing yourself from the opportunity to grow.

And that's how you stop growing as a programmer.

Advice is Plenty

In programming, wherever you look, you get advice for free. You just have to see it as advice. And I'm not talking about self-made senior developers who earned internet points and are now telling you how to be a millionaire.

I'm talking about other developers and teammates, carefully reviewing your code, and helping you.

With a fixed mindset, these comments could feel paralyzing. The "X requested changes" might feel ashaming.

"What I didn't get right this time, OMG".

But there should be no question whether it's good that someone is requesting changes from you. It's someone else's knowledge applied to your stuff. Someone else's mind, seen in action. It's not something you want to fight although a healthy conversation about whether they were right or weren't is more than welcome you should grab that advice.

Quit at 5

Hustling was super popular in the Gary Vee era, and now people who were his avid followers are coming at you with a different tactic: drop things at 5 PM. Don't spend any more minutes working than you absolutely have to.

Here's what Dave Cutler has to say about this:

During my early years at my first employment, I don't remember there was a thing I said no to, although I was employed as a front-end developer. Write a new backend service? Sure, why not? Design a DB Schema? Okay, do I need a pencil or paper for that, or ...? I asked many, seemingly stupid questions.

But now, without a second thought, I hear this from beginner developers and contractors I work with: "I prefer not to do x and y".

I get it. You don't like it, and that's fine.

But remember that the things you use today, including this blogging platform, weren't built because people said, "I'd rather do something else".

The Money

We do programming for a living. However, in my experience, how much money you make at a given moment could be less important in the grand scheme of things than you think.

If there's a learning opportunity and your life circumstances allow, I'd take a job for 20% less than I would typically do and think of it as paying for a course.

When I started freelancing, I was happy to take on projects where I could earn and learn.

But be careful not to use "I'm still leaning" as an excuse when someone is paying for your services.

Learning doesn't authorize you to do anything less than your absolute best work, which might mean you go way below your hourly rate anyway because you have to do additional research, but time showed me it's worth it.

Giving Back

After working in various industries, such as healthcare and construction, for personal reasons or through client engagements, I see now that the growth of programming has been greatly influenced by the inherent mindset of sharing knowledge and educating others.

Think of open source and just how many free tools you use today.

Programming is a self-sustaining perpetual mobile that functions because people are thought to give back to the community in some form because that's also how they became programmers.

Without being paid or expecting any future returns on it, because I bet there is a programmer who you set out on an incredible journey than you did your part.

How I became a Web Developer

Akos — Wed, 25 Jan 2023 23:00:00 +0000

I often post Twitter threads about React, TypeScript, and JavaScript courses. However, after every successful post, my DMs are almost full of people asking, How to become a Web Developer?

So this got me thinking, am I approaching teaching the wrong way, and should I start from the basics? You can learn a lot from what I share, but only if you're already familiar with programming. But if you're a beginner, they probably aren't that helpful.

At some point in my career, I was also a beginner, and if you are too - I don't want to let you down.

So here's my journey of becoming a Web Developer with no formal education when I was about to start middle school.

How to become a Web Developer, or really, anything

There has to be some initial motivation to learn more about the profession. You most definitely can't become something you don't know anything about. You can't become a carpenter if you've never heard about carpenters.

But I'm sure - since you're reading this - you already heard about web developers.

In 2001 I got my first computer and my first dial-up modem.

In my community, people knew almost nothing about computers, except that they are the next big thing and are expensive. Kind of like Crypto these days. For the price of a PC, you could have bought tons of stuff. My dad was thinking hard about buying a trailer or a computer. He could've bought a trailer for work for that money. But in the end, I think he made the right choice. 😄

So we discovered this thing called: the Internet. I was fascinated by the fact that anyone in the world can make a website, a creation, a hello world with a marquee effect - and it becomes a thing for everyone. You can go, see it, tell it to other people where they can find it - if they had Internet, it was rare back then.

I knew I had to understand how people create websites and how I could make them too.

At this point in my life, I had little clue what HTML or CSS is. I knew some tools make a website appear in a certain way. My initial motivation wasn't to learn the tools but to learn to build the thing.

So how to become a web developer? What's the neverending source of drive that can last forever?

Is it HTML? I doubt so. I don't even write pure HTML anymore. Is it CSS? I never truly learned CSS and use UI Frameworks like Bootstrap and TailwindCSS to this day.

I'd say it's the curiosity to explore the web and understand what you can do with it. To unleash what you have learned, again and again, to build different things with or without purpose.

Reverse engineering at 16

By 2003, the Internet was already "big" among the local nerds. I knew one other guy in my entire school who also knew what HTML is and how you can build basic websites.

How did we learn to create HTML sites? Macromedia Dreamweaver!

This is version 8, I used something soo old I couldn't find a picture of it 😂

What? No books? No Fancy editors?

Back in 2003 - for a teenager - it was almost impossible to find programming HTML books, especially where I was living. We had a couple of software of unknown origin 🏴 and we had to work with what we had.

We built a ton of websites in Dreamweaver's visual editor. And I mean a Ton. A website for our local school, the kindergarten, one for each neighbor's dog, for our favorite movies, anything you can imagine.

But some annoying bugs forced us to look under the hood and switch to the Code view of Dreamweaver.

And this is how we got introduced to HTML.

Yep! No books, no tutorials, but out of necessity.

As we built and tweaked more and more websites, we realized that coding some stuff in the code editor is much faster. It also produced fewer bugs than the UI builder.

And this is how we switched from the visual to the HTML editor.

In the meantime, our English has improved, and we started looking at online forums to expand our knowledge.

One of the most important technologies that I picked up next and that led to my first client was: JavaScript? No. PHP. No! ASP? Nah It was Joomla!

Why on Earth did you learn Joomla - you're wondering (Joomla is a Content Management System written in PHP).

I won't surprise you if I tell you that most people don't know how to build websites. And it wasn't any different 20 years ago! I knew that to make some real money with the web, I have to give people more freedom. I can't tell them: "Hey if you don't like the footer you can change it on line 59!"

So I started building out my new websites - you can call these portfolio websites - with Joomla.

Being part of a small community, people already knew I do websites. Fortunately, a festival was preparing in my village around that time of the year.

The organizers reached out to me and asked if I could make a website for them. They would update the contents later, the program schedule if it changes, publish new performers, etc.

I showed them Joomla and they were blown away. And this is how I landed my first paid gig for some big money back then.

PHP, more side hustles, University

In 2004 I was already learning PHP and tweaking Joomla. I also built a PHP app that was able to bulk-modify excel files.

I sold this software to a local shop with a huge inventory where the prices were changing frequently based on the exchange rate of the local currency compared to USD. They were calculating and updating every price manually.

I told them they could do this with a click of a button - you can imagine their reaction.

But you can also imagine me slowly understanding where this can lead.

I started middle school and focused on programming (Turbo C and PHP) - and pretty much-neglected everything else there was for me to learn. Learn about an operating system called Linux that changed everything for me forever.

My final work in middle school was an online platform that schools in my country used to register their pupils for a National Math competition. It contained all elements of registration for school, and teachers, handling files uploads of CSV, excel, and transforming and saving them to a MySQL database.

The system was used extensively for three months while the registrations lasted.

It served the entire country and I felt super proud.

One of my teachers only told me this after I presented my final work:

you could have sold this for a fortunate.

He was right. I wanted to finish my studies ASAP and make money with programming. I didn't want to go to University - I was thinking, why waste four years when I could be selling people what they need?

Finally, thanks to my parents, I decided to give the University a shot. I'll skip the debate on formal education or Bootcamps. I believe they don't compare. They provide different opportunities. If you go to the University, you'll encounter some situations only a University can bring. For example, I was able to publish a scientific work that has an ISBN! Whether they are relevant for what you'll be doing later, you'll find that out.

One of my dear friends, who's a brilliant mind and is programming to this day, couldn't go the University, but instead, he invested that time into getting better at coding. He not only made a living for himself but helped his parents and now works for a company that everyone reading this knows.

For me, the University was somewhat relevant. I learned a lot about data structures and algorithms at a very advanced level, and I worked a ton with Java - which later became the language I did Web Development with for four years.

And the rest is history.

Conclusion

I admit I originally titled this post "How to became a Web Developer" and wanted to turn it into a guide-like thing. But instead, I decided to write about how I did it.

Because those were different times, learning and networking were also different.

These times have their challenges.

I respect everyone who tries to make sense of this neverending stream of programming content these days.

How to test props in React Testing Library

Akos — Fri, 13 Jan 2023 09:21:13 +0000

In this post, we'll learn how to test the props a React Function Component receives with React Testing Library and Jest.

Before React Testing Library appeared, most of us were writing tests with Enzyme.

Enzyme had a completely different approach to testing React components.

We could play with the React components' internal state and test some implementation details.

After finding a component in the DOM, we could do pretty much anything with it.

Call state() to modify its state (super bad idea) or props() to check what props it received:

// This is most likely what we did in Enzyme
const wrapper = mount(
  <div>
    <MyComponent
      includedProp="Success!"
      excludedProp="I'm not included"
    />
  </div>
);
const myComponent = wrapper.find(MyComponent);
expect(myComponent.props().includedProp).to.equal('Success!');

The power provided by Enzyme got out of control, and many of us started using it to test implementation details, which should be avoided at all costs. It makes the tests fragile and the codebase more difficult to change.

We won't go over the Jest and React Testing Library setup here because I provided a working Codesandbox where you can both see the setup and experiment with the code.

Let's jump into it and see how we could test the props on a simple component.

Here's a Profile component that displays some data about our user:

import PermissionsContainer from "../PermissionsContainer";

interface Props {
  firstName: string;
  lastName: string;
  age: number;
  profileId: string;
}

const Profile = ({ firstName, lastName, age, profileId }: Props) => {
  return (
    <div>
      <span>
        {firstName} {lastName}, {age}
      </span>
      <PermissionsContainer profileId={profileId} />
    </div>
  );
};
export default Profile;

Let's say we want to make sure that the PermissionsContainer receives the same profileId as the Profile component, but without actually running any code from PermissionsContainer.

If we write a simple test like the one below, it will render the PermissionsContainer and run any code inside of it:

import { render, screen } from "@testing-library/react";
import Profile from "./index";

describe("Profile", () => {
  const renderProfile = () =>
    render(
      <Profile
        firstName="John"
        lastName="Doe"
        age={35}
        profileId="1234-fake-5678-uuid"
      />
    );

  test("renders app", () => {
    renderProfile();
    expect(screen.getByText(/John Doe/i)).toBeInTheDocument();
  });
});

This is not what we want!

So to mock the PermissionContainer module that Profile imports we're going to use jest.mock.

To mock the entire function component, so it's a no-op, we would do something like this:

jest.mock("./PermissionsContainer");

But we can also tell the mock what ./PermissionsContainer should return when it's imported by specifying the second parameter.

jest.mock("./PermissionContainer",
  () => 'This is PermissionsContainer'
)

When Profile imports ./PermissionsContainer instead of receiving the actual module, it will receive this function: () => 'This is PermissionsContainer'

See what happens in the DOM when we mock the module:

import { render, screen } from "@testing-library/react";
import Profile from "./index";

jest.mock("./PermissionContainer",
  () => 'This is PermissionsContainer'
)

describe("Profile", () => {
  const renderProfile = () =>
    render(
      <Profile
        firstName="John"
        lastName="Doe"
        age={35}
        profileId="1234-fake-5678-uuid"
      />
    );

  test("renders app", () => {
    renderProfile();
    // screen.debug is going to print the current DOM into the console
    screen.debug();
    expect(screen.getByText(/John Doe/i)).toBeInTheDocument();
  });
});

We'll see in the console the output of debug:

<body>
  <div>
    <div>
      <span>
        John

        Doe
        , 
        35
      </span>
      This is PermissionsContainer
    </div>
  </div>
</body>

We specified a simple function () => 'This is PermissionsContainer' as the default export of the PermissionsContainer module, and when the module got imported and was run by React, it produced a simple string.

We're on track!

The code inside PermissionsContainer is not running anymore, but we'd still like to check what props it receives!

All we have to do is update our mock implementation to handle the parameters it receives:

jest.mock("./PermissionsContainer", () => ({ profileId }) =>
  `This is PermissionsContainer profileId:${profileId}`
);

Now we should see the following output after returning the test:

<body>
  <div>
    <div>
      <span>
        John

        Doe
        , 
        35
      </span>
      This is PermissionsContainer profileId:1234-fake-5678-uuid
    </div>
  </div>
</body>

Now we could write a test that checks if this specific prop value is printed in the DOM:

  test("renders Container with the correct props", () => {
    renderProfile();
    expect(
      screen.getByText(
        "This is PermissionsContainer profileId:1234-fake-5678-uuid"
      )
    ).toBeInTheDocument();
  });

And this is how we check if PermissionsContainer receives the correct prop from its parent component without actually running PermissionsContainer.

Got any questions? Are you moving from Enzyme to jest?

Let me know in the comments below if you're facing any difficulties!

How to type React Props with TypeScript

Akos — Fri, 06 Jan 2023 06:39:01 +0000

Typing React Props with TypeScript can be done in different ways, but not each way will provide you with an equal level of type safety.

First, let's take a look at a simple component we'll use to demonstrate the two methods, but without typing the props first:

I always set "noImplicitAny": true, so my editor warns me about the untyped props.

Let's type them with React's FC interface.

React.FC

React.FC is a generic type in the React module that defines a functional component in TypeScript. It is a shorthand for describing a functional component that has a prop type.

In our example, ProfileCard is a functional component that expects to receive props with a name string and an age number. These props are typed using the Props interface, and the component is typed as React.FC<Props>, which specifies that it is a functional component with the specified prop types:

As we see, the errors disappeared because through React.FC<Props>, we specified the types for both the name and age props.

props: Prop

Another, even more straightforward way to type React props is to specify the object type inside the function's signature.

Below we're simply telling react that this object has a specific type:

Now let's see the differences between the two regarding type safety.

Differences in type safety

When using React.FC, if you define a default value with a different type than the type in Props, it'll merge the two types and assign that as the new type for the prop.

You might expect the below code to fail the TypeScript compilation, but it won't.

Here's the new type React.FC created for name:

However, if you use the props: Prop method to type your props, you get an error right away:

Conclusion

Because of this difference, I always prefer the props: Prop way to define props in React.

But keep in mind, if you are using TypeScript in your entire codebase, a wrongly typed default value might pop up an error in the component that ends up using it.

Here's an example of that:

The TypeScript compiler warns us that ProfileName expects a name with the type of string and not with the type of string | boolean.

Stop Doing Coding Tutorials

Akos — Fri, 18 Nov 2022 09:18:34 +0000

Disclaimer I don't want to gatekeep and tell you what tutorials are worth reading. In fact, I welcome all and every kind of tutorial, keep writing them!

This post is for those who are reading them and feel they're not progressing.

About a year ago I learned about the idea of tutorial purgatory or tutorial hell. I'm confident, I can set you on the right course to escape it.

Completing tutorials feels good. They're a lot shorter than a book, ideal for a daily dose of dopamine.

They're mostly free, further encouraging you to grab them, and it can be hard to stop because there's the reward when you complete them!

Finally, I learned how to use Array.map, enough for the day! - said by no one ever

Why there are so many tutorials?

Tutorials exist for different reasons. Some people write tutorials for a living. They write one every single day. Is it the 20th "Getting started with X", "Learning Y in 10 minutes", or the 100th spin on "Why you should be using Z right now"?

Some people write tutorials only to practice writing.

You don't have to read all the tutorials out there on trivial topics like how to use Array.map, that's ridiculous.

I'm not talking here about tutorials discussing how to integrate different tech or platforms that sometimes indeed need a tutorial because the official docs simply cant explain the integration with every possible tech out there.

What to do instead?

You can create plenty by following the official documentation.

Most of the libraries you want to work with already have a simple "Getting Started" page:

React 👉 https://reactjs.org/docs/getting-started.html

Others are packed with examples, comprehensive documentation, screencasts, free courses:

TailwindCSS 👉 https://tailwindcss.com/docs

These are free resources. They're up to date, coming from the developers of the library itself. Packed not only with examples but best practices and patterns you should follow.

Conclusion

As a beginner, these pages should be your bread & butter.

The next step is basically just using this tech to build something.

I believe this is just as important as reading up on tech as not even more important.

Remember always build something with the tech you just learned, otherwise, it'll be just another completed tutorial on your pile of completed tutorials.

Let me know in the comments what was the last thing you've learned and what did you build with it?

DEV Community: Akos

A Brief History of Web Development

Request-response

Ajax responses, the first spinners

The SPA revolution

The Spinner Hell

RSC, Remix

Why this changes everything

Your Guide to Testing React Components

Component Props

Component Hooks

Accessing the DOM

Classnames

Complex structures

Snapshots

Getting Better

Getting Faster

Conclusion

Creating a CI/CD Pipeline with Docker and GitHub Actions: A Step-by-Step Guide

Terminology

CI

CD

GitHub Actions

Adding CI to your existing project

Creating a Workflow file

Adding steps to your workflow file

Example of a workflow file

Testing the workflow file

Server Setup - AWS/DigitalOcean

Deployment options

Deployment Overview

Create a Server

Docker Setup

Adding CD

Testing CD

Conclusion and further improvements

The Ultimate Full Stack Framework for 2024: Remix

Separation of concerns

The Remix way

No more states

Form Inputs

Loading states

Standards

Conclusion

How to Publish Docker Images to Docker Hub with GitHub Actions

Terminology

Create the Dockerfile

Building and running your image locally

Create a DockerHub account

Create a GitHub Actions workflow

Push the image to Docker Hub

Pull and run the image from DockerHub

How to handle multiple form actions in Remix

The Remix Fullstack Data Flow

The problem with multiple actions

The solution

Further reading

How to clear form after submit in Remix

The useActionData hook

Capturing the results

Capturing the form

Clearing the form

Conclusion

Succeeding as a Software Developer: The Essential Mindset Shift

Be The Beginner

Advice is Plenty

Quit at 5

The Money

Giving Back

How I became a Web Developer

How to become a Web Developer, or really, anything

Reverse engineering at 16

PHP, more side hustles, University

Conclusion

How to test props in React Testing Library

How to type React Props with TypeScript

React.FC

props: Prop

Differences in type safety

Conclusion