DEV Community: aromanarguello

Choosing a tech stack for your start up

aromanarguello — Wed, 23 Nov 2022 03:45:23 +0000

Why it's important to choose the right tech stack for your startup

When starting a startup, it's important to choose the right technology stack. A good tech stack will help you save time and money in the long run while also being scalable and efficient. It's worth taking the time to research and select the right technologies for your needs, consulting with experts before making any decisions, and ultimately finding a technology stack that meets your specific goals. There are many options out there, so make sure that you do your research before making any decisions.

If you choose the wrong technology, it can be very difficult and expensive to switch to a more appropriate solution later on.

It's important to choose a tech stack that will scale well as your startup grows. The right tech stack can help your startup scale more quickly. Choosing the right technologies will allow you to focus on what matters most: creating innovative products or services that people will love.

The right tech stack can help your startup attract and retain talent. Choosing the best platform for your company’s needs means that you can attract top talent by making use of modern recruiting tools and social media platforms (like LinkedIn). Not only will this help you fill key positions quickly, but it will also keep your team motivated and engaged throughout their tenure with the company!

What to consider when choosing the right tech stack for your startup

When starting a business or side project, it's important to choose the right stack for your needs. There are a few factors to consider when making this decision, including the nature of your business, your budget, and your technical expertise, such as what languages you are familiar with and/or feel comfortable with, who your target audience is, if it will be a user facing application or an API for other apps to consume. If you're not sure where to start, there are plenty of resources available to help you research and compare different options. Ultimately, the best tech stack for your startup will be the one that meets all of your specific needs and requirements. With so many options available, it's important to take the time to find the perfect fit for your company.

Most likely things you will need are a front-end framework, a database, a way for your client to write and consume that data, and probably authenticate users.

I love Node & Typescript, so I will write from this point of view, but this applies to any language. Unless you want to learn something new, the fastest way to get going is to choose a stack in the language you most feel comfortable. Or as I say, your "get shit done" language.

The benefits of using Reactjs in the frontend

Reactjs is a popular frontend javascript framework that helps developers create user interfaces and single-page applications. Because Reactjs is declarative, it makes code more predictable and easier to debug.

Additionally, Reactjs uses a virtual DOM, which updates in real-time as changes are made, making updates faster and less expensive.

Components written in Reactjs are reusable, meaning you can use them repeatedly without having to rewrite the code. This makes development faster and more efficient.

ReactJS has an expansive open-source ecosystem with plenty of libraries for just about anything you might need. From single functions like date formatting to component libraries for any application requirement!

One of the biggest benefits of using ReactJS is that it has a vast community of developers who can help you with any questions or problems you may encounter when developing the framework.

It's backed by a big tech company known for technical excellence. To some people, this might be positive, and for others, a negative. For me, this is positive because it has a team supporting it. It is also more likely that it will have a long-term support.

My favorite react framework is Nextjs by Vercel. In my opinion, the developer experience is unrivaled. It is packed with well-built features such as Server Side Rendering, File-based Routing, and many more that abstract the complexity of writing unnecessary boilerplate and allow you to go from idea to working MVP quickly.

The benefits of using an API built on Node

Node APIs are a fast, efficient way to build web applications. It is easy to use and learn, making it a great choice for start-ups. Node APIs are scalable and can handle large amounts of traffic. They are compatible with many different programming languages and frameworks. Node is open source and has a large community of developers who can help you with your project.

For the API, I stick to the battle-tested option, Express. You cannot go wrong here. Like React, it has one of the largest open-source communities with loads of support and documentation. It also only takes a few lines to start an API which is nuts.

For the company we just cofounded, I started using NestJS. This framework has grown in popularity in recent years and offers so much.

If you want to build quicker or just to test an idea and don't want to go through the trouble of building a stand-alone API. NextJS by vercel provides you with the ability to build an API within it as a mono repo. You can build a rest API out of the box, add an ORM such as Prisma, and you are ready to go.

In terms of ORM (Object-Relational Mapping), there are amazing Node options out there. My favorite two are TypeORM and Prisma. TypeORM is my go-to. With TypeORM, database modeling is class-based. This allows you to use OOP principles such as inheritance.

The benefits of using a Rest API

A Rest API can help you save time and money by simplifying your start-up's tech stack. By using a Rest API, you can reduce the number of codebase changes that need to be made when integrating new software or services into your start-up. Additionally, using a Rest API can make it easier to integrate with other software and services.

A Rest API can make it easier to scale your start-up's technology infrastructure. As your start-up grows, having a reliable and scalable technology platform will ensure continued success. Using a Rest API can allow you to easily add new servers or scale existing ones without making any codebase changes.

A Rest API can provide a more consistent user experience across different devices and platforms. By providing an interface that is accessible from both desktop and mobile devices, your users will have a consistent experience irrespective of which device they are using.

A RestAPI can help you take advantage of the latest technology trends and standards.

The benefits of using a relational database

A relational database can help you organize your data in a way that makes sense for your business. This can be helpful because it allows you to easily access and manage your data from different applications.

A relational database can make it easier to query and manipulate your data. This means you can easily find the information you are looking for quickly and efficiently.

My personal choice is always PostgreSQL.

Authentication

Authentication is critical to your system, especially if you store user data and PII (personally identifiable information). If you plan to do this, I will almost always recommend using a battle-tested option such as Auth0.

Building an authentication system has many complexities, and it takes a lot of time to implement. At a startup, time is key, and you want to spend that time building features. Most people underestimate this. Options like Auth0 provide you with everything you need out of the box with very little code required.

Hosting

For me the best hosting is AWS. In recent years AWS has done a great job of building managed services such as App Runner, Elastic Beanstalk, Amplify which help you scale quickly!

Ultimately I end up moving into more robust services such as Elastic container service but this requires more devops knowledge.

If you don't want to deal with AWS, Render is a great option. If you were familiar with Heroku, render is pretty much an alternative to it but better in my opinion. With render it's a plug and play, you can just connect your github, set a branch and let render take care of the rest, you don't even need docker.

Extras

Additionally, I highly recommend the following tools for increased collaboration:

Figma for brainstorming, wireframes, designs
Slack for team communications
Notion for all documentation and much more
Linear for project management
Retool to build internal tools

Conclusion

You will need a UI for your clients to engage with your application, a database to store information, and a way for your UI to read and write data to your database, an API. There are many options out there for this, but you should always choose the stack in which you feel the most comfortable.

At the moment my personal recommendation is:

Front-end: NextJS (could be your backend as well)
Back-end: NestJS
Database: PostgreSQL
ORM: TypeORM
Styling library: Chakra UI
Authentication: Auth0

Using AWS Lambdas + headless Chrome to Generate PDF files from HTML

aromanarguello — Thu, 03 Dec 2020 02:26:28 +0000

This post assumes that you have basic knowledge of the Serverless framework and AWS Lambda, have created an AWS account with a lambda function initialized. This article will focus on going over the code used to generate a PDF file using user input received from a client and an HTML template, then store it in an AWS s3 bucket.

Make sure that you have added your AWS credentials to serverless, you can do so from the CLI as so:

export AWS_ACCESS_KEY_ID=<your-key-here>
export AWS_SECRET_ACCESS_KEY=<your-secret-key-here>
# AWS_ACCESS_KEY_ID and AWS_SECRET_ACCESS_KEY are now available for serverless to use
serverless deploy

# 'export' command is valid only for unix shells. In Windows - use 'set' instead of 'export'

First things first, let's create a directory:

mkdir lambdas && cd lambdas

Note:
I have this trusty alias in my ~/.zshrc file that I use to create directories and cd into them:

function mkcd {
    local target=$1
    mkdir -p "$target"
    cd $target
}

Let's install our dependencies:
npm install aws-sdk chrome-aws-lambda puppeteer-core

aws-sdk will help use connect to AWS and make use of their services such as lambda and s3!
chrome-aws-lambda & puppeteer-core will allow us to spin up a headless version of chrome. We will use this instance to create a blank page, add the content, and store it as a PDF

** Make sure you have the serverless framework installed globally **
(npm install -g serverless)

Once inside our directory or your location of choice, we can go ahead and leverage the serverless template scaffolding to create a new handler.js using the nodejs blueprint.
serverless create --template aws-nodejs --name generatePdf

This will create 3 files for us:

handler.js
serverless.yml
.gitignore

The first thing I did was to go ahead and clean up all of the contents in the serverless.yml file and only left what was necessary for us to be able to perform the desired action.

After some cleanup, my serverless.yml file looks like this:

service: pdf

frameworkVersion: "2"

provider:
  name: aws
  runtime: nodejs12.x
  region: us-east-1

functions:
  handler:
    handler: handler.handler # 👈 this access the handler
    memorySize: 1600 # here we tell AWS how much memory to allocate
    timeout: 30
    events:
      - http:
          path: users/create # 👈 this defines the http path
          method: get
          cors: true

package:
  exclude:
    - node_modules/puppeteer/.local-chromium/**

At the time of writing this, the handler.js file should initially look like this:

'use strict';

module.exports.hello = async event => {
  return {
    statusCode: 200,
    body: JSON.stringify(
      {
        message: 'Go Serverless v1.0! Your function executed successfully!',
        input: event,
      },
      null,
      2
    ),
  };

  // Use this code if you don't use the http event with the LAMBDA-PROXY integration
  // return { message: 'Go Serverless v1.0! Your function executed successfully!', event };
};

At this point, none of this is relevant to our goal. We will go ahead and clear everything up, install dependencies and get to the nitty gritty!

If you recall, in our config file, we said that the path to our module would be called handler and that lived within handler.js

functions:
  handler:
    handler: handler.handler // 👈 this
    memorySize: 1600
    timeout: 30

It really doesn't matter what you call your handler, just make sure that the name is the same in both your config file and your exported module.

module.exports.handler = async event => {
   // .. cleaned up content and changed name of
   // exported module from hello to handler
};

Now, let's import and initialize our S3 instance from the aws-sdk package we installed earlier.

"use strict"

const { S3 } = require("aws-sdk");

const s3 = new S3(); // 👈 initialize our instance

module.exports.handler = async event => {
   // .. cleaned up content and changed name of
   // exported module from hello to handler
};

Let's also add the rest of the utilities from chrome-aws-lamda and add some initial boilerplate code.

"use strict"

const { S3 } = require("aws-sdk");
const { puppeteer, args, defaultViewport, executablePath } = require("chrome-aws-lambda");

const s3 = new S3(); // 👈 initialize our instance

module.exports.handler = async (event, ctx, cb) => {
  let result = null;
  let browser = null;

  const date = new Date().toISOString(); // we will use this
                                         // to create filename

  const filename = `pdf-${date}` // you can call this whatever you want
                                 // but make it unique or else the file
                                 // will be replaced

  const pdfPath = `/tmp/${filename}.pdf`
  // I will pause here to further talk about tmp files
};

I want to make a quick note about /tmp/ files in case you are not familiar with them. As the shorthand notation might infer, it refers to a temporary file. These files are typically created by an application to store some form of temporary data.

In a nutshell, whenever we run our function it will generate this temporary directory and once the execution of the function is done, it will discard it. This provides the perfect environment needed to create a pdf file and store it in S3(more permanent storage).

Back from our short break and let's start writing some funky logic.

module.exports.handler = async event => {
  let result = null;
  let browser = null;

  const date = new Date().toISOString(); filename

  const filename = `pdf-${date}` 

  const pdfPath = `/tmp/${filename}.pdf`

  try {
    console.log("Establishing connection...");
    // Initialize and launched puppeteer
    browser = await puppeteer.launch({
      args,
      defaultViewport,
      executablePath: await executablePath,
      headless: true,  // 👈Very important, remember we want to run headless chrome
      ignoreHTTPSErrors: true,
    });

    console.log("Opening new page...");
    // 👇 create a new headless chrome pag
    const page = await browser.newPage();

    console.log("Generating PDF file from HTML template...");

     // 👇 Ignore this line for right now
    await page.setContent('<h1>Hello world!</h1>', { waitUntil: "networkidle2" });

    // 👇 this tells puppeteer to save the webpage as a pdf file
    await page.pdf({ format: "Letter", path: pdfPath });

    const params = {
      Key: pdfPath,
      Body: fs.createReadStream(pdfPath),
      Bucket: "<yourS3Bucket>",
      ContentType: "application/pdf",
    };

    console.log("Uploading PDF...");

    // 👇 Pretty self explanatory but this is what uploads
    // and store our PDF or file to S3
    await s3
      .upload(params, async (err, res) => {
        if (err) {
          console.log(err);
          throw new Error(err);
        }
        console.log("done");
        console.log(res);
        return cb(null, res);
      })
      .promise();

    result = await page.title();
  } catch (error) {
    return cb(error);
  } finally {
    if (browser !== null) {
      console.log("Closing browser...");
      await browser.close();
    }
  }
  return cb(null, result);
};

So! This is pretty much it for the handler itself, but we are still missing something very important! We are missing our HTML template, so go ahead and create a new file inside your directory called template.js (or whatever you want to call it).

Wait! .js file? But I thought we were creating an HTML template!
And yes, you are correct we are creating an HTML template, BUT because we want to be able to add dynamic fields to that template we will return the HTML content from a function. This way we can add variables and interpolate them into our HTML. JS FTW!

From your root directory, run touch template.js and enter the following contents to give you an example of how it would be done:

module.exports.template = ({ someVariable }) => {
  const today = new Date();
  return `
    <!DOCTYPE html>
    <html>
      <head>
        <meta charset="utf-8" />
        <title>PDF Result Template</title>
        <style>
          .container {
            background-color: rebbeccapurble
          }
        </style>
      </head>
      <body>
          <div class="container">
            Hello ${someVariable}!
            Today's date is: ${today}
          </div>
      </body>
    </html>
  `;
};

Up until right now, our serverless function should be able to generate a mostly blank PDF doc with Hello World in it. That isn't dynamic enough though.

To fix this we can import our template.js module into our function and call it from the page set content function.

Inside our handler, we had a comment that said to ignore the below-called function. Well, let's give it some attention now.

In await page.setContent('<h1>Hello world!</h1>', { waitUntil: "networkidle2" })

Replace the first string argument with the important function and pass it some data.

// ... other imports
const { template } = require("./template");
                  // destructure 👇 data from event argument
module.exports.handler = async({ data }, ctx, cb) => {
     // ...
    //
    await page.setContent(template({ ...data }), { waitUntil: "networkidle2" });
   // ...
};

page.setContent could be considered the main bread and butter since this is what merges our blank page and our template to render the desired outcome.

We can test if this works locally by running the following command:
serverless invoke local --function functionName --data '{"data": "Alejandro"}'

Finally, you can run serverless deploy!

Thanks for reading, any feedback and/or improvements are more than welcome :)

Setting up react app from scratch [Workshop recording]

aromanarguello — Tue, 02 Jun 2020 13:48:33 +0000

This past Saturday, May the 30th, 2020, along with ~30 engineers we held a workshop where we built a react app from scratch. We started with an empty terminal and added dependencies until we eventually worked our way to rendering content with React. As we added those dependencies we explored what each of them was doing and how they would play into the React ecosystem.

In the workshop we installed webpack, babel, eslint, prettier, react, react-dom, jest and @testing-library/react. In between I shared some hot Vscode, productivity, and interview tips!

Many of the engineers in the audience were either students or recent graduates who were looking for frontend roles. Thus I took more of an enterprise approach for configuring and optimizing your react apps for production setting in a very basic way. Part 2 will be in a couple of weeks :D

This is pretty much the first time I'm sharing something like this on the web but I think there are many engineers (new comer or veterans) that might find this beneficial, so any feedback is greatly appreciated

I hope you can find some value from this tutorial! :D

Github: https://github.com/aromanarguello/workshop-2020-react

https://www.youtube.com/watch?v=K41DUe38Lc4&t=115s

How to use Themes in styled-components

aromanarguello — Mon, 11 Nov 2019 04:05:06 +0000

Styled-components is my default css-in-js library. I have used other libraries in the past but styled-components remains my personal favorite. I love the fact that I can embed and treat styles as if they were components. It gives me the ability to use maximum reusability. Additionally, I can pass props to these and make really cool conditional styles with minimum effort.

Theming is a great tool to use within front-end applications. It also allows me to write way less code and be more consistent with my styling. By leveraging the theme provider in styled-components I only need to write my main styles and rules in one single object and invoke them in any component that is a descendant of that provider. Theme provider achieves this by leveraging the context API.

This short guide assumes a basic knowledge of styled-components.

I created a code sandbox with only three files in it, but the Theme pattern I use can be added anywhere within the directory of your application.

Update June 2020: I hosted a small workshop where I show how to add styled-components with ThemeProvider to a react app. You can checkout the video here. If you want to skip directly to theme provider, you can jump to minute 26:27.

Given the following structure:

|_ public
|_ src
  |_ App.jsx
  |_ index.js
  |_ Theme.jsx // can go in any folder
|_ package.json

App.jsx

import React from "react";

const App = () => {
  return (
      <div>
        <h1>Hello world!</h1>
        <h2>By the power of styled-components!</h2>
      </div>
  );
};
export default App;

To begin with, inside of your react project install styled-components

npm install styled-components

After I have set up my initial configuration and installed all my dependencies I usually go ahead and create a Theme.jsx component. In this component, I also create the theme object file. You can easily create this within your App.jsx component, but I think it is a good separation of concerns to allow it to live in its own file.

First things first, import React from the react dependency, and then we import ThemeProvider from the styled-components file. Theme provider uses context to provide the properties to its descendants.

import React from "react";
import { ThemeProvider } from "styled-components";

Theme provider takes in a prop called theme, this props takes an object. We can add any property we want our styled-components to have access to. You can let your imagination run wild here! It is very powerful.

const theme = {
  colors: {
    powderWhite: "#FFFDF9",
    persianGreen: "#06B49A",
    lightBlue: "#AFDBD2",
    onyx: "#36313D"
  },
  fonts: ["sans-serif", "Roboto"],
  fontSizes: {
    small: "1em",
    medium: "2em",
    large: "3em"
  }
}

Then, using the render props method we will create a Theme component that will render children with all the properties from the Theme provider. Like I mentioned before, the theme provider takes a theme prop. In that prop is where we reference the object we create above.

const Theme = ({ children }) => (
  <ThemeProvider theme={theme}>{children}</ThemeProvider>
);

Finally, we export the theme.

import React from "react";
import { ThemeProvider } from "styled-components";

const theme = {
  colors: {
    powderWhite: "#FFFDF9",
    persianGreen: "#06B49A",
    lightBlue: "#AFDBD2",
    onyx: "#36313D"
  },
  fonts: ["sans-serif", "Roboto"],
  fontSizes: {
    small: "1em",
    medium: "2em",
    large: "3em"
  }
};

const Theme = ({ children }) => (
  <ThemeProvider theme={theme}>{children}</ThemeProvider>
);

export default Theme;

Back in our App.jsx the component, we now import the theme component that was just created to wrap our entire function. By wrapping our App function, all the descendants of App will have access to the theme object. I usually like to add it to the top level of my project.

We will also import the styled object. In a nutshell, the way we create styled-components is through this method. This method will give us back an HTML element that is mapped to the components and applies the give CSS styles.

import React from "react";
import Theme from "./Theme";
import styled from "styled-components"
const App = () => {
  return (
    <Theme>
      <div>
        <h1>Hello world!</h1>
        <h2>By the power of styled-components!</h2>
      </div>
    </Theme>
  );
};
export default App;

Now, let's create some quick styled-components to highlight how we can access the theme within our styles. I also added props to <Heading> to illustrate how we can pass prop to our styles and use them to do things like conditionally render a font size, but you can do so much more. As I said, you can use your imagination 😁. You can perform any javascript operation. And because styled-components uses template literals, it all feels as if we were writing normal CSS.

import React from "react";
import Theme from "./Theme";
import styled from "styled-components";

const Container = styled.div`
  width: 100%;
  border: ${props => `1px solid ${props.theme.colors.onyx}`};
  background-color: ${props => props.theme.colors.lightBlue};
  font-family: ${props => props.theme.fonts[0]};
`;

const Heading = styled.h1`
  font-size: ${({ isHeading, theme: { fontSizes } }) =>
    isHeading ? fontSizes.large : fontSizes.small};
  color: ${({ theme: { colors } }) => colors.persianGreen};
`;

const App = () => {
  return (
    <Theme>
      <Container>
        <Heading isHeading={true}>Hello World</Heading>
        <h2>By the power of styled-components!</h2>
      </Container>
    </Theme>
  );
};
export default App;

In the <Container> styles I opted out of destructuring in order to show that the concept of theming is possible via the props system. All we are doing is telling our props that we want to access the theme object that lives there. Inside the theme object, we can access any of the keys such as the colors object and reference a specific color (i.e persianGreen).

I personally prefer to destructure my objects such as in <Heading>, in my opinion, it looks cleaner and I prefer less repetition of long chaining.

The props object as a whole now contains two main properties, theme and isHeading, but we can add as many props as we like. A way to great leverage this, is to pass a value from state and tie the style to rendered on state change.

You can start using themes in styled-components really quick as you can see. If you need clarification on any concept from this post, don't hesitate to reach out via comments or spectrum.chat :)!

Thanks for reading!

A note on heading content

aromanarguello — Tue, 29 Oct 2019 03:12:04 +0000

In the world of HTML, our web applications produce an HTML outline in the browser. The HTML outline is sectioned off by different categories of content, among those, the heading content exists. With these, we can layout down the blueprint for our work. Lately, I've been practicing somewhat of HTML first prototyping to improve my accessibility skills.

For me, the idea behind HTML first prototyping is to create a site or web application that will have a better, more scalable and standard abiding structure. In my experience when I apply the CSS styles as I develop the HTML, I end up adding more accessibility violations. This is due to the fact that styling semantic HTML is not an easy feat, so to make it look good (or out of frustration 😅) I introduce, knowingly or unknowingly, a11y (accessibility) violations.

In this post, I want to focus on the h1-h6 heading tags. These h# tags are known and described by the HTML docs as Heading content and they define the headings of a section. In this definition, a section is a container for some DOM nodes in the original tree. Source

When the browser looks at our HMTL document or the page we are on, it will walk across it (top to bottom), and it will divide it into sections or segments -- creating the outline. Screen readers and assistive technologies use this outline to navigate and deliver the outcome to their users. Hence, why it is important for us to write it in the "right way". When a screenreader encounters this h# element within a section, it will rank them according to their number, 1 being the most important in the hierarchy, and 6 the least important.

h1 tag will create a content section (not the same as the section above), h2 will create a content subsection, and so on. It is important to note that equal rank heading tags, do not create nested sections. Meaning h1 will always be the highest and everything in between is represented by that h1. Assistive technology will interpret and announce an h1 as the main heading for that page. If we have more than one it will cause conflict. When subsequent headings of equal or higher rank are added they create implied sections, this is one of the reasons why it is important to only have one upper-level heading per page.

Meaning that this:

      <div>
        <h1>Welcome to this page</h1>
        <h2>Second level</h2>
        <h3>Third level</h3>
        <h4>Fourth level</h4>
        <h5>Fifth level</h5>
        <h6>Sith level</h6>
      </div>

Will be interpreted the same way like this (in terms of their section outline):

      <div>
        <h1>Welcome to this page</h1>
        <section>
          <h2>Second level</h2>
        </section>
        <section>
          <h3>Third level</h3>
        </section>
        <article>
          <h4>Fourth level</h4>
          <h5>Fifth level</h5>
        </article>
        <h6>Sith level</h6>
      </div>

There was some debate some years ago to create the Natural Document Outline, in which headings would be able to create nested accessible sections, thus allowing a user to add multiple h1 tags inside the same document. However, this HTML 5 heading algorithm never saw the light of day. No assistive technology to this day supports it.

Resource 1
Resource 2

The first element of the heading content will represent the heading for that section. It can be written at any spot in your HTML code but to assistive technology, it will be interpreted and announced in the order that the current HTML outline algorithm places it in.

So, this:

      <section>
        <h2>Welcome to my page!</h2>
        <h1>Hello dev.to!</h1>
        <p>This can be a description</p>
      </section>

and this:

      <section>
        <h1>Hello dev.to!</h1>
        <h2>Welcome to my page!</h2>
        <p>This can be a description</p>
      </section>

are both semantically correct. In both examples, h1 will be interpreted as the heading of the page no matter the order that it was written in. If no CSS is applied, the first example would look out of order since h1 has a larger size.

This brings me to another good point, to some it might be obvious, but the docs advise against skipping levels and using heading elements to style subtitles, alternative titles, content text, and/or markup-subheadings. In other words, we should attempt to maintain the hierarchical order in our document, h1 -> h2 -> h3 not h1 -> h3 -> h5, etc. After what I have learned it seems logical because behind the scenes they create these sections and sub-sections. So, visually it might look good and even render a good user experience, however, it would most likely be considered inaccessible for assistive technologies.

On a closing note, you can give the heading property to other HTML elements through aria-* and role attributes.

<div role="heading" aria-level="1">Header</div>

The role attribute tells assistive technologies that this element should be treated as a heading. The aria-level="1" tells what rank the heading will have. To an assistive technology, this would be the equivalent of:

<h1>Header</h1>

Using tools like Lighthouse audit or axe, which both exist as chrome dev tool extensions, really helps me out identify any a11y violations. I've gotten into the habit of running audits on both these tools early on and as I am developing (accessibility driven development!) to make sure my HTML is on point.

Thanks for reading! I hope to read some of your feedback on what I have learned, if anything is missing or if anything can be added to my knowledge!

Build a dropdown in React using Downshift + TS

aromanarguello — Tue, 09 Jul 2019 01:35:37 +0000

Since the moment I laid my hands on Downshift I knew the amazing potential this library has. Nowadays many of us, don't think about the importance of accessibility. Downshift amazingly solves this in many ways. I ran into this article: https://baymard.com/blog/custom-dropdowns-cause-issues once and it states that 31% of custom dropdowns have issues, and I can see why.

I've had to build a few dropdowns with just JSX and they are tough with so many edge cases to cover. Accessibility things such as keyboard navigation and ARIA standards. And not to mention the bugs I've introduced lol! It can become complicated to build them out yourself.

This is one of those scenarios where you have 2 options, build it from scratch or leverage a library like Downshift, the tradeoff is not even fair. This library handles everything if you need to build a dropdown. It comes equipped with full blown out of the box keyboard navigation, all the correct aria props, and manages its internal state. But, you also have the override many many parts of it.

I added a dropdown to a storybook which had an a11y addon (if you don't know what it is, it tells you a11y stats about your components), and it passed 15 different aria-standards with flying colors, oh and 0 violations.

Using Downshift will undoubtedly save you and your teammates time when building out many components. It once took me a week to implement an autocomplete dropdown. Now I can make one in 45 minutes :)! This library is amazing, I hope you give it a try and enjoy it!

Any feedback is much-appreciated :D!

Downshift Github: https://github.com/downshift-js/downshift

We first need to create our dropdown component. With typescript when we import react, we need need to import everything from the React library (import * as React from 'react'). I know there are ways around this but there are no downsides to doing it this way.

Downshift is exported as default component from the library and it uses the Render props method to provide us with many features such as internal state management, incredible a11y methods, auto-complete methods, keyboard-navigation, and some other pretty cool stuff we will explore :)! I won't really be focusing on styling but more on the functionality of the dropdown.

Note: if you try to run it at this step, Downshift will throw an error. This is because Downshift needs to render a DOM element.

First things first, in your react project:

npm install --save downshift

then create a file called Dropdown.tsx

import * as React from 'react'
import Downshift from 'downshift'

const Dropdown: React.FC = () => { 
   // we declare our dropdown as Functional
   // Component type. Still no props to declare
  return (
    <Downshift></Downshift>
  )
}

export default Dropdown

I always like to add styles right after and I love the styled-components library it is hands down my favorite css-in-js library. And with V5 Beast mode being released it is going to freaking sweeeter!

I've developed the convention to call my autocomplete section of the dropdown just Input. This is a personal preference.

import * as React from 'react'
import Downshift from 'downshift'
import styled from 'styled-components'

const Input = styled.input`
  width: 100px;
  border: 1px solid black;
`;

const Dropdown: React.FC = () => {
  return (
    <Downshift></Downshift>
  )
}

export default Dropdown

Now, about the Render props method. We will destructure from Downshift a few methods first, some of them return an object which inserts all those nice aria props into our component to make it accessible. They might also contain event handlers that will all either give you control or operate behind the scenes. Downshifts prefers that we provide hem this spread these objects as props

{...getInputProps()} will provide the input tag with an object that contains all the needed props for it be fully accessible such as aria-autocomplete, aria-controls, aria-label, etc.
Note, if I would have wrapped my component (everything between <Downshift>)
Because we are wrapping our dropdown in a <Form> composed styled component, we need to destructure and spread {...getRootProps()} inside the <Form>

const Form = styled.form`
  display: flex;
  flex-direction: column;
  width: 100px;
  margin: 0;
`;

const Input = styled.input`
  width: 100%;
  border: 1px solid black;
`;


const Dropdown: React.FC = () => {
  return (
    <Downshift>
      {({ getInputProps, getRootProps }) => (
        <Form {...getRootProps()}>
          <Input {...getInputProps()} />
        </Form>
      )}
    </Downshift>
  );
};

export default Dropdown;

Right after the input, I create the actual dropdown options section of the dropdown. I call the <ul> = <Menu> and <li> = <Item>

We will later map over the <Item> to produce a nice menu full of cool items.

Similarly, we will destructure getMenuProps from Downshift and then spread it as a prop inside of Menu. This method will handle adding all the correct aria roles and props.

By default, the menu will add an aria-labelledby that refers to the <label>. But, you can provide aria-label to give a more specific label that describes the options available.

const Form = styled.form`
  display: flex;
  flex-direction: column;
  align-items: center;
  justify-content: flex-start;
  width: 100px;
  margin: 0;
  padding: 0;
`;

const Input = styled.input`
  width: 80px;
  margin-left: 37px;
  border: 1px solid black;
`;

const Menu = styled.ul`
  width: 80px;
  padding: 0;
  margin: 0;
  border: 1px solid;
`;
const Item = styled.li`
  list-style: none;
`;

const Dropdown: React.FC = () => {
  return (
    <Downshift>
      {({ getInputProps, getMenuProps, getRootProps }) => (
        <Form {...getRootProps()}>
          <Input {...getInputProps()} />
          <Menu {...getMenuProps()}>
            <Item>First Item</Item>
          </Menu>
        </Form>
      )}
    </Downshift>
  );
};

export default Dropdown;

Now, we need to give <Item> all its awesome features. We can achieve this
with another method that Downshift provides us with: getInputProps, however, this time we are dealing with an impure function (only call it when you apply props to an item). Same as the previous methods, we will spread into <Item>. However, this time the method takes in an object as an argument. It takes different properties, of which only one is required: item and it is the value that will be selected when the user selects clicks or selects (with keyboard) on an item. Another property, which is not required, is index. We provide an index to getItemProps() because this is how Downshift keeps track of which item is selected and something we will explore later, highlightedIndex.

The most efficient way to achieve our dropdown options is to iterate over an array. I usually choose an array of objects since an object can fit more key/value pairs.

At this point, we can start setting up the first prop for the component. I usually create my interface and assign it to React.FC, this way we tell what kind of shape the prop can expect. For dropdowns, I like to call the array: options.

import * as React from "react";
import Downshift from "downshift";
import styled from "styled-components";

type OptionType = {
  value?: string;
};

// it is considered best practice to append the 'I' Prefix to interfaces
interface IDropdownProps { 
  options: OptionType[];
  onChange?: (selectedItem: string) => void; // this is for later
}

const Form = styled.div`
  display: flex;
  flex-direction: column;
  width: 100px;
`;

const Input = styled.input`
  width: 100%;
  border: 1px solid black;
`;

const Menu = styled.ul`
  width: 100%;
  padding: 0;
`;
const Item = styled.li`
  list-style: none;
  width: 100%;
`;

const Dropdown: React.FC<IDropdownProps> = ({ options }) => { // add IDropdownProps
  return (
    <Downshift>
      {({ getInputProps, getMenuProps, getRootProps, getItemProps }) => (
        <Form {...getRootProps()}>
          <Input {...getInputProps()} />
          <Menu {...getMenuProps()}>
            {options.map((item, index) => ( // we map over the options array
              <Item {...getItemProps({
                item,
                index,
                key: item.value
              })}>{item.value}</Item>
            ))}
          </Menu>
        </Form>
      )}
    </Downshift>
  );
};

export default Dropdown;

About that internal state management, we were speaking of earlier... Downshift manages its own internal state for toggling the dropdown menu between open and closed. We will destructure isOpen from Downshift, which is defaulted to false, and it is handled its state is handled completely internally. By now, we can click into the input and type something and that will also toggle the isOpen to true and open the menu. By default, Downshift has the feature to close the menu when you click outside of its range.

In order to have a visual queue of what Item we are on we will destructure highlightedIndex from Downshift. We will add a new key as an argument in the {...getItemProps()} method, style. The style will allow us to inject CSS properties to the current item. So, we basically tell it hey if the current index of the item you are on is equal to the highlightedIndex (handled by Downshift), make the selection light gray.

Just like that, now we can click into the input, type a letter, the dropdown should open, and you can have keyboard navigation. WOOT WOOT! Yup another benefit of Downshift, full on out of the box keyboard navigation! How sweet is that?!

const Dropdown: React.FC<IDropdownProps> = ({ options }) => {
  return (
    <Downshift>
      {({
        getInputProps,
        getMenuProps,
        getRootProps,
        getItemProps,
        isOpen,
        highlightedIndex
      }) => (
        <Form {...getRootProps()}>
          <Input {...getInputProps()} />
          <Menu {...getMenuProps()}>
            {isOpen &&
              options.map((item, index) => (
                <Item
                  {...getItemProps({
                    style: {
                      backgroundColor:
                        index === highlightedIndex ? "lightgray" : null
                    },
                    key: item.value,
                    item,
                    index
                  })}
                >
                  {item.value}
                </Item>
              ))}
          </Menu>
        </Form>
      )}
    </Downshift>
  );
};

How about we add a button so we can open and close it with a click from our mouse?
For simplicity sake, I will add a simple button and provide it with the event listener methods that the library gives us. I will just add a button because the take away here is how Downshift handles these types of events, all of which are overridable with things like stateReducer

We will destructure getToggleButtonProps method from Downshift and spread it {...getToggleButtonProps()} in the <Button> as a prop. This method will do a couple of things for us. It will give the button all its appropriate roles and aria props, but its main function is to toggle that internal state of the isOpen we destructured earlier, so in essence, it will allow us to open and close the menu with a click!

// Button
const Button = styled.button`
  width: 20px;
  text-align: center;
  padding: 0;
`;
// Added this to align input and button :)
const InputContainer = styled.div`
  display: flex;
`;

const Dropdown: React.FC<IDropdownProps> = ({ options }) => {
  return (
    <Downshift>
      {({
        getInputProps,
        getMenuProps,
        getRootProps,
        getItemProps,
        getToggleButtonProps, // this is what we destructure
        isOpen,
        highlightedIndex
      }) => (
        <Form {...getRootProps()}>
          <InputContainer>
            <Input {...getInputProps()} />
            <Button {...getToggleButtonProps()}>{isOpen ? "-" : "+"} . 
            </Button> 
             // here is where we spread it 
          </InputContainer>
          <Menu {...getMenuProps()}>
            {isOpen &&
              options
              .map((item, index) => (
                <Item
                  {...getItemProps({
                    style: {
                      backgroundColor:
                        index === highlightedIndex ? "lightgray" : null
                    },
                    key: item.value,
                    item,
                    index
                  })}
                >
                  {item.value}
                </Item>
              ))}
          </Menu>
        </Form>
      )}
    </Downshift>
  );
};

Sweet! So now we have a dropdown that opens and closes, it has some options, and we can navigate up and down through those options with the keyboard. Now we need to add the filtering functionality. So that we can type into our <Input> and narrow down our search!

We need to destructure inputValue from Downshift. This holds the initial value when the component is initialized.

Now, we've added the functionality to narrow down our searches based on the letter entered

Additionally, we need to add a prop called itemToString to <Downshift>. Downshift uses this to handle the value for the selected item. Without this, when we select an item either by click or enter, the <Input> component would be populated by the string [object Object] and of course we wouldn't want that. In essence, it is what ultimately leads to the string value of the input field. Either an item selected or an empty string, or a place holder of choice

I personally prefer to make it as close as possible as the <select><option> API. So, next, I like to add the event listener for event changes.

const Dropdown: React.FC<IDropdownProps> = ({ options, onChange }) => {
  return (
    <Downshift 
      onChange={selectedItem => onChange(selectedItem ? selectedItem.value : "")} 
      itemToString={item => (item ? item.value : "")}
    >
      {({
        getInputProps,
        getMenuProps,
        getRootProps,
        getItemProps,
        getToggleButtonProps,
        isOpen,
        highlightedIndex,
        inputValue,          // we destructure this from Downshift
        clearSelection       // add this to clear the currently selected item
      }) => (
        <Form {...getRootProps()}>
          <InputContainer>
            <Input {...getInputProps()} />
            <Button {...getToggleButtonProps()}>
              {isOpen ? "-" : "+"}
            </Button>
             // add this to clear the currently selected item
            <Button onClick={clearSelection}>x</Button> 
          </InputContainer>
          <Menu {...getMenuProps()}>
            {isOpen &&
              options
                .filter(item => !inputValue || item.value.includes(inputValue))     // added to narrow down ooptions                .map((item, index) => (
                  <Item
                    {...getItemProps({
                      style: {
                        backgroundColor:
                          index === highlightedIndex ? "lightgray" : null
                      },
                      key: item.value,
                      item,
                      index
                    })}
                  >
                    {item.value}
                  </Item>
                ))}
          </Menu>
        </Form>
      )}
    </Downshift>
  );
};

Usage

import * as React from "react";
import { render } from "react-dom";
import Dropdown from "../components/Dropdown";
import "./styles.css";

const data = [
  { value: "One" },
  { value: "Two" },
  { value: "Three" },
  { value: "Four" },
  { value: "Five" }
];

function selectedItem(val) {
  console.log(val);
}
function App() {
  return (
    <div className="App">
      <h1>Hello CodeSandbox</h1>
      <Dropdown onChange={selectedItem} options={data} />
    </div>
  );
}

const rootElement = document.getElementById("root");
render(<App />, rootElement);

Thanks for reading!

Setting up Jest + React-Testing-Library

aromanarguello — Sat, 29 Jun 2019 15:47:09 +0000

In the past few months, I've had the immense pleasure to work with what I can say is my favorite library to use in the React + Friends environment, react-testing-library. This library is a piece of art.

There hasn't been a library more intuitive, easy to set up and more beginner friendly. In some occasions, it has been even a great way to break in a developer into a new project. With this guide, my aim is to share what I have learned in the process of configuring tooling for different projects and sort of the best practices that I have personally adopted. We will walk through the steps to get your environment setup with create-react-app and setting up a React project from scratch (jest*, web-pack, babel, etc…).
More than a how-to test guide, this guide is a step by step walkthrough on how to set up your testing environment in a React application. For learning how to write a unit test there are plenty of guides by more knowledgeable people than myself going over that topic. However, I will say that for me, the best way to become better at testing is to actually write tests. One of the biggest struggles I see both new and old developers who haven't written test, is learning the distinction between what Jest's role is and what react-testing library's role. In my own experience, the way to learn that distinction is by repetition, getting stuck, doing research, reiterating.

Eager to hear feedback from the community!

Index:

Directory file structure & conventions I've picked up
Getting started with Jest + RTL and create-react-app
Getting started with Jest + RTL from scratch
Config to setup with Typescript
Examples
Curated resources to help you get started with RTL

File structure:

Article I wrote on How I structure my React Apps (not with hooks):
https://blog.usejournal.com/how-i-structure-my-react-apps-86e897054593

Best practices and convention has been for the longest time, even before react was around, to create a folder __ test __ and just put your test files inside that folder. I have kinda done things differently and this is absolutely just personal preference. As I kept working with it the following system it kinda just stuck and the team I work with and my self pretty much enjoy it (I think!).

The typical file structure in my projects:

- node_modules
- public
- src
  - components
    - MyComponent
      - MyComponent.jsx
      - MyComponent.styles.js
      - MyComponent.test.js      // here is what I do different
    - index.js            // source of truth for component export
  - utils
    - helpers.js
  - pages
  - App.jsx
  - App.test.jsx
  - App.styles.js
  - index.js

As I point out in the comment above. This is my biggest personal deviation from the popular convention. It just seems to me that in the age of component driven development it makes more sense for me to create this sort of encapsulated environments for your components (most important thing is to be consistent and work with what makes you comfortable 😁). Adding one test folder for each component you have, which in a large code base, with a lot of components and component variations, it seems like something that just not DRY. Additionally, I do not find any personal benefit behind adding that folder. Besides when jest crawls your root directory and looks for files to run it's not looking for a folder in particular (well, depends on your jest's RegEx pattern).

Naming and casing conventions:

- PascalCase for component file name and folder name
- Generally, I want to indicate if my components are container or component.
  Containers will usually be class components that contain state and logic,
  whereas components will house the actual content, styling and receive props from the container. 
  Example:
  - `MyComponent.container.js`
  - `MyComponent.component.js`
  - `MyComponent.jsx`          // if no container
  - `MyComponent.styles.js`
- lowerCamelCase for Higher Order Component file and folder name
- lowercase for all other root directory folders. For example: `src`, `components`, `assets`

Some conventions worth noting

Describe method:

describe('My component', () => {
  // group of test()
})

Describe method is one of what jest calls Globals methods, which you don't have to import or require to use. The describe statement, in particular, is used to group similar test together.

Test method

test('some useful message', () => {
   // logic
}, timeout) // timeout is optional

Test functions are the bread and butter though. This is the function that actually runs your tests. According to Jest's documentation, the first argument is the name of the test, the second argument is the callback where you add your testing logic (assertions, etc.), and the third argument, which is optional, is the time out.

The test function also has an alias that can be used interchangeably it(): it('test', () => {})

Getting started jest and RTL with CRA:

Full disclosure. I love using CRA it setups everything for you and reduces the amount of technical overhead you will get over time as dependency versions fall behind. With react-scripts, you pretty much just have to worry about that part.

npx create-react-app ProjectName

npx create-react-app ProjectName --typescript

right off the bat, the first thing I do is install dependencies needed:

npm install --save-dev @testing-library/jest-dom

npm install --save-dev @testing-library/react

In the package.json file I add the following script:

"test": "jest -c jest.config.js --watch"

Quick note: first thing when I start a new react project is to add those dependencies + styled-components and my types if need be.

Testing library documentation defines jest-dom as a companion library for React Testing Library that provides custom DOM element matchers for Jest. In essence, it is the dependency that provides statements (or matchers*) such as toHaveStyles or toHaveAttribute.

Example:
expect(Component).toBeInTheDocument() <- matcher

Once your project is created, inside my src folder I add a file called setupTests.js.

- src
  - components
  - App.js
  - setupTests.js

The setupFiles is executed before the test framework is installed in the environment. For our case, it is especially important, because it will allow us to run the correct imports before the tests are executed. This gives us the opportunity to add a couple of imports.

So in your setupTests.js file:

import '@testing-library/jest-dom/extend-expect'

And that's it for that file :).

This is all you need to get up and running with jest and react-testing-library!

Getting started on jest and RTL with a React app from scratch:

This part will be a little longer since there are more tools to cover and configure. In a way, we will walk through my step by step process to build a react application from scratch. create-react-app does abstract a lot of the configuration complexity and it does it really well, now we have to configure our babel and for our case most importantly the jest configuration. Higher overview the jest config takes care of making sure that jest knows where to look for, what to look for and how to execute it.

A Great resource to setup your React App from scratch:
https://blog.bitsrc.io/setting-a-react-project-from-scratch-using-babel-and-webpack-5f26a525535d

Directory structure

- node_modules`
- public
  - index.html
- src
  - components
    - MyComponent
      - MyComponent.jsx
      - MyComponent.styles.js
      - MyComponent.test.js      // here is what I do different
    - index.js             // source of truth for component export
  - utils
  - pages
  - App.jsx
  - App.test.jsx
  - App.styles.js
  - store.js
  - index.js
- webpack.config.js
- jest.config.js
- .gitignore
- .eslintrc
- .prettierrc

index.html:

<!DOCTYPE html>
  <html lang="en">    
    <head>        
      <meta charset="UTF-8" />        
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />        
      <meta http-equiv="X-UA-Compatible" content="ie=edge" />                                    
      <title>React JS + Webpack</title>
    </head>    
    <body>        
      <div id="root"></div>    
    </body>
  </html>

App.js

import React from 'react';

const App = () => <h1>Hi World</h1>;

export default App;

index.js

import React from "react";
import ReactDOM from "react-dom";
import App from "./App";

ReactDOM.render(<App />, document.getElementById("root"));

webpack.config.js:

const webpack = require("webpack");

// plugins
const HtmlWebpackPlugin = require("html-webpack-plugin");

module.exports = {
  entry: "./src/index.js",
  output: {
    filename: "./main.js"
  },
  module: {
    rules: [
      {
        test: /\.(js|jsx)$/,
        exclude: /node_modules/,
        use: {
          loader: "babel-loader"
        }
      },
      {
        test: /\.(png|svg|jpg|gif)$/,
        use: ["file-loader"]
      },
      { test: /\.jsx$/, loader: "babel-loader", exclude: /node_modules/ },
      { test: /\.css$/, use: ["style-loader", "css-loader"] }
    ]
  },
  devServer: {
    contentBase: "./dist",
    hot: true
  },
  plugins: [
    new HtmlWebpackPlugin({
      template: "./public/index.html",
      filename: "./index.html"
    }),
    new webpack.HotModuleReplacementPlugin()
  ]
};

jest.config.js:

module.export = {
  roots: ['<rootDir>/src'],
  transform: {
    '\\.(js|jsx)?$': 'babel-jest',
  },
  testMatch: ['<rootDir>/src/**/>(*.)test.{js, jsx}'], // finds test
  moduleFileExtensions: ['js', 'jsx', 'json', 'node'],
  testPathIgnorePatterns: ['/node_modules/', '/public/'],
  setupFilesAfterEnv: [
    '@testing-library/jest-dom/extend-expect'', 
    '@testing-library/react/cleanup-after-each'
  ] // setupFiles before the tests are ran
};

MyComponent.js:

import React from 'react'
import styled from 'styled-components'

const MyComponent = props => {

  return (
    <h1>`Hi ${props.firstName + ' ' + props.lastName}!`</h1>
  )
}
export default MyComponent

MyComponent.test.js:

import React from 'react'
import { render, cleanup } from '@testing-library/react'
import MyComponent from './MyComponent'

afterEach(cleanup)

describe('This will test MyComponent', () => {
  test('renders message', () => {
     const { getByText }= render(<Mycomponent 
                                 firstName="Alejandro"
                                 lastName="Roman"
                              />)

     // as suggested by Giorgio Polvara a more idiomatic way:
     expect(getByText('Hi Alejandro Roman')).toBeInTheDocument()
})

input example:

import React from 'react'
import { render, fireEvent } from '@testing-library/react'
import Input from './Input'


test('accepts string', () => {
  // I try to avoid using data-testid as that is not something a user would
  // use to interact with an element. There are a lot of great query and get 
  // methods
  const { getByPlaceholderText } = render(<Input placeholder="Enter
                                           Text" />);
  const inputNode = getByPlaceholderText('Search for a problem or application name');

  expect(inputNode.value).toMatch('') //tests input value is empty

  // if you need to perform an event such as inputing text or clicking
  // you can use fireEvent
  fireEvent.change(inputNode, { target: { value: 'Some text' } }));

  expect(inputNode.value).toMatch('Some text'); // test value 
                                                // is entered
});

Typescript config

tsconfig.json:

{
  "include": [
    "./src/*"
  ],
  "compilerOptions": {
    "lib": [
      "dom",
      "es2015"
    ],
  "jsx": "preserve",
  "target": "es5",
  "allowJs": true,
  "skipLibCheck": true,
  "esModuleInterop": true,
  "allowSyntheticDefaultImports": true,
  "strict": true,
  "forceConsistentCasingInFileNames": true,
  "module": "esnext",
  "moduleResolution": "node",
  "resolveJsonModule": true,
  "isolatedModules": true,
  "noEmit": true
  },
  "include": ["./src/**/*"],    
  "exclude": ["./node_modules", "./public", "./dist", "./.vscode"]
}

jest config:

module.exports = {
  roots: ['<rootDir>/src'],
  transform: {
    '\\.(ts|tsx)?$': 'babel-jest',
  },
  testMatch: ['<rootDir>/src/**/?(*.)test.{ts,tsx}'],   // looks for your test
  moduleFileExtensions: ['ts', 'tsx', 'js', 'jsx', 'json', 'node'],
  testPathIgnorePatterns: ['/node_modules/', '/public/'],
  setupFilesAfterEnv: [
    'jest-dom/extend-expect',
    '@testing-library/react/cleanup-after-each'
  ]  // sets ut test files
};

webpack config:

const path = require('path')

// Plugins
const HtmlWebpackPlugin = require('html-webpack-plugin')

module.exports = {
    entry: {
        dev: './src/index.tsx',
    },
    output: {
        path: path.resolve(__dirname, 'dist'),
        filename: 'js/[name].bundle.js',
    },
    devServer: {
        compress: true,
        port: 3000,
        hot: true,
    },
    devtool: 'source-map',
    resolve: {
        extensions: ['.ts', '.tsx', '.js', '.jsx'],
    },
    module: {
        rules: [
            /**
             * Gets all .ts, .tsx, or .js files and runs them through eslint
             * and then transpiles them via babel.
             */
            {
                test: /(\.js$|\.tsx?$)/,
                exclude: /(node_modules|bower_components)/,
                use: ['babel-loader'],
            },

            /**
             * All output '.js' files will have any sourcemaps re-processed by
             * source-map-loader.
             */
            { test: /\.js$/, enforce: 'pre', loader: 'source-map-loader' },
        ],
    },
    plugins: [
        new HtmlWebpackPlugin({
            template: './public/index.html',
        }),
    ],
}

Extra resources:

Some resources that helped me learn different parts of using React testing library:

Docs:

https://testing-library.com/docs/react-testing-library/intro

Create-react-app: https://www.youtube.com/watch?v=Yx-p3irizCQ&t=266s

Testing redux: https://www.youtube.com/watch?v=h7ukDItVN_o&t=375s

Component unit testing: https://www.youtube.com/watch?v=KzeqeI046m0&t=330s

Mocking and more component testing: https://www.youtube.com/watch?v=XDkSaCgR8g4&t=580s

Portals: https://www.youtube.com/watch?v=aejwiTIBXWI&t=1s

Mocking: https://www.youtube.com/watch?v=9Yrd4aZkse8&t=567s

Test async components: https://www.youtube.com/watch?v=uo0psyTxgQM&t=915s