DEV Community: Abdolah Keshtkar

React: About highly customizable components - P1

Abdolah Keshtkar — Fri, 29 Mar 2024 21:16:05 +0000

Overview

Tables and Lists are common examples of components that should be reusable and customizable.

The Problem

Let's say we have the following component and want to make it customizable (by over-engineering it 😈).

import { FC } from 'react';

interface Props {
  rows: { id: string; name: string }[];
}

const List: FC<Props> = ({ rows }) => {
  return (
    <ul>
      {rows.map((row) => (
        <li key={row.id}>{row.name}</li>
      ))}
    </ul>
  );
};

What are the problems?

We want to pass extra props to the li and ul tags.
We want to use other components instead of the li and ul tags (+ props should adapt to the type of the props of these components).

In this post, we will be addressing the first problem. In the next post, we'll tackle the second one.

Passing Extra Props to an "li"

It is actually quite straightforward; you may have already done it multiple times. We can accept a prop, spread it, and pass it to the li.

import { ComponentProps, FC } from 'react';

interface Props {
  rows: { id: string; name: string }[];
  liProps?: ComponentProps<'li'>;
}

const List: FC<Props> = ({ rows, liProps }) => {
  return (
    <ul>
      {rows.map((row) => (
        <li key={row.id} {...liProps}>
          {row.name}
        </li>
      ))}
    </ul>
  );
};

We can use the ComponentProps type from React to get the props type of any component we pass to it.

type MyCustomComponentProps = ComponentProps<typeof MyCustomComponent>;
type ButtonProps = ComponentProps<"button">;

Let's move forward. Now we can pass props to the li tag. We also get auto-complete (with love to Typing 😏).

<List
  rows={data}
  liProps={{
    style: {
      color: 'red',
    },
  }}
/>

Passing Extra Props to a "ul"

Try to do it yourself in Stackblitz or Codesandbox. If you are too lazy to do it, then let's go.

Here we will do more steps, like having better naming and grouping, but first let's do it the simple way:

import { ComponentProps, FC } from 'react';

interface Props {
  rows: { id: string; name: string }[];
  liProps?: ComponentProps<'li'>;
  ulProps?: ComponentProps<'ul'>;
}

const List: FC<Props> = ({ rows, ulProps, liProps }) => {
  return (
    <ul {...ulProps}>
      {rows.map((row) => (
        <li key={row.id} {...liProps}>
          {row.name}
        </li>
      ))}
    </ul>
  );
};

So, I believe it's fine to have one prop to get the props of others, but it may get crowded in the parent component, so I like to group them, something like this:

import { ComponentProps, FC } from 'react';

interface Props {
  rows: { id: string; name: string }[];
  slotProps?: {
    ul?: ComponentProps<'ul'>;
    li?: ComponentProps<'li'>;
  };
}

const List: FC<Props> = ({ rows, slotProps }) => {
  return (
    <ul {...slotProps?.ul}>
      {rows.map((row) => (
        <li key={row.id} {...slotProps?.li}>
          {row.name}
        </li>
      ))}
    </ul>
  );
};

I use slotProps, inspired by MUI, but feel free to use other names.

Using the component will go like this:

<List
  rows={data}
  slotProps={{
    li: {
      style: {
        color: 'green',
      },
    },
    ul: {
      style: {
        padding: '12px',
      },
    },
  }}
/>

It's pretty cool, right? No? "Wtf, you said no?" Wait dude, so what if we want to pass onClick to li and we want to do an alert with the name of the item on click (or maybe navigate or anything).

So here is where I go into a fight with Performance bros, but let's ignore them for so many seconds and let's find a solution.

I mean, of course, I already have a solution for it; otherwise, I wouldn't write this post 😊.

So the problem is we want to pass different props based on the value of the item. What we can do is accept a callback that returns the props, and we pass the item to it, something that can be used like this:

<List
  rows={data}
  slotProps={{
    li: ({ name }) => ({
      style: {
        color: 'green',
      },
      onClick: () => alert(name),
    }),
    ul: {
      style: {
        padding: '12px',
      },
    },
  }}
/>

In the above example, we accepted a function, passed the row, and got the props. It's actually simple:

import { ComponentProps, FC } from 'react';

interface TItem {
  id: string;
  name: string;
}

interface Props {
  rows: TItem[];
  slotProps?: {
    ul?: ComponentProps<'ul'>;
    li?: ComponentProps<'li'> | ((row: TItem) => ComponentProps<'li'>);
  };
}

const List: FC<Props> = ({ rows, slotProps }) => {
  return (
    <ul {...slotProps?.ul}>
      {rows.map((row) => (
        <li
          key={row.id}
          {...(typeof slotProps?.li === 'function'
            ? slotProps?.li(row)
            : slotProps?.li)}
        >
          {row.name}
        </li>
      ))}
    </ul>
  );
};

Or if we want to be cooler with typing, we can write a cool generic.

Basically, this generic should accept a value type and args type, then return the value or a function that accepts the args type and returns the value.

type MaybeFunc<Value, Args extends Array<unknown>> = Value | ((...args: Args) => Value)

We can use it like so:

interface Props {
  rows: TItem[];
  slotProps?: {
    ul?: ComponentProps<'ul'>;
    li?: MaybeFunc<ComponentProps<'li'>, [TItem]>;
  };
}

Final Code

Note: Of course, there are different patterns like component composition that can be used, but trust me, bro!

Post link in my blog

Optimizing Cypress for Faster Execution: Insights from Neocom

Abdolah Keshtkar — Tue, 14 Nov 2023 12:55:39 +0000

Overview

In Neocom, we operate two main front-end services undergoing testing with Cypress. Due to our startup nature, we experience frequent pushes, merges, and deployments, necessitating careful consideration of our CI speed and costs.

Cypress itself is a robust testing tool, but its weightiness imposes a load on requests.

NOTE: The timing discussed pertains solely to Cypress execution, excluding processes such as Docker builds and CI runs.

Integration tests

It's widely acknowledged that Integration tests can be slow, often due to factors like waiting, timeout testing, etc.

Sometimes, extensive testing on a specific page or component can contribute to slower tests.

Another factor affecting speed is the keyboard delay time of Cypress. Yes, you heard me right—if you have multiple inputs, this can consume considerable time.

Solutions

Initially, we set the keyboard delay to zero, which worked well for several months. However, for API search inputs, consider adding debounce to your API search input or introducing a delay to the Cypress write function. This led to a 10% speed improvement.
Running tests in parallel: While Cypress itself offers parallel execution, it comes with a cost. We opted for the Cypress Parallel library, resulting in significant speed improvements:

Service 1: 06:05 mins => 03:47 mins (37.7% faster)
Service 2: 04:25 mins => 01:36 mins (63.77% faster)

HTTP 1.1

Cypress proxy and local frontend development servers use HTTP 1.1. Browsers, however, have a limit of max 6 connections to the same origin, impacting the speed of requests.

For instance, if you use ES Module and have nearly 200 components to load, the browser can only make 6 requests simultaneously. This sequential loading can result in significant time delays.

Solution

As Cypress proxy doesn't support HTTP 2, and local dev servers typically lack HTTP2 support, we addressed this by bundling less. For example, with Rollup (Vite build), using manualChunks to export code into a few JS Modules improved speed. Example configuration:

import { defineConfig } from "vite"

export default defineConfig({
  .......
  build: {
    rollupOptions: {
      output: process.env.TESTING && {
        manualChunks: () => "index.js",
      },
    },
  },
  .......
})

Results may vary based on Cypress request volume, with more noticeable improvements on the CI.

How about your experiences with Cypress speed? What strategies have you employed to enhance it?

Couchbase Node SDK on Docker

Abdolah Keshtkar — Mon, 14 Nov 2022 20:50:29 +0000

Hey guys,
I have been working on a project using Remix (Node image), Couchbase server, etc. All dockerized.

The problem was to connect to Couchbase, I needed its Node SDK which is current version is 4.2.0 but I hit multiple errors in the way.

I didn't find any instruction about it on the Couchbase website, so I decided to write one.

In the start, your frontend Dockerfile may look like this:

FROM node:18

WORKDIR /app

COPY package.json .
COPY package-lock.json .

RUN npm --verbose ci --force

COPY . .

RUN npm --verbose run build

Wanting Couchbase SDK to be on the project, needs multiple things to be fixed:
First, I can not use node 18, I need node 16.
Second, I need to have cmake.

To do so first let's change the base image and downgrade it to node 16:

FROM node:16

Then we need to pull cmake installation script, you can find them here: https://cmake.org/download/

IMPORTANT: Choose from "Binary distributions" section.

Then here you have two options:
First, download the file and place it beside the docker file to copy it and run it in the Dockerfile
Or, using wget, you can download it inside the Docker build process and run it.

First Option

For the first option, after placing the .sh file beside the docker file:

You need to copy it and run it inside the docker file:

WORKDIR /cmake

COPY cmake-3.25.0-rc4-linux-x86_64.sh ./

RUN ./cmake-3.25.0-rc4-linux-x86_64.sh --skip-license && rm cmake-3.25.0-rc4-linux-x86_64.sh

In the third line, we got rid of it after installing cmake.

Now we have it installed under /cmake/bin folder.

Second option

We need to have wget installed and then download and run the file like the following:

RUN apt update && apt install -y g++ wget bash

WORKDIR /cmake

RUN wget https://github.com/Kitware/CMake/releases/download/v3.25.0-rc4/cmake-3.25.0-rc4-linux-x86_64.sh

RUN ./cmake-3.25.0-rc4-linux-x86_64.sh --skip-license && rm cmake-3.25.0-rc4-linux-x86_64.sh

Adding to the path

Cmake.js which is a library that Couchbase needs cmake, so to make it happen, add the following line:

ENV PATH="$PATH:/cmake/bin"

Final result

FROM node:16

WORKDIR /cmake

COPY cmake-3.25.0-rc4-linux-x86_64.sh ./

# OR

# RUN apt update && apt install -y g++ wget bash
# RUN wget https://github.com/Kitware/CMake/releases/download/v3.25.0-rc4/cmake-3.25.0-rc4-linux-x86_64.sh


RUN ./cmake-3.25.0-rc4-linux-x86_64.sh --skip-license && rm cmake-3.25.0-rc4-linux-x86_64.sh

ENV PATH="$PATH:/cmake/bin" 

WORKDIR /app

RUN npm i couchbase@4.2.0

COPY package.json .
COPY package-lock.json .

RUN npm --verbose i 

COPY . .

RUN npm --verbose run build

Note: I separated Couchbase installing because it takes so much time to be installed but also "package.json" and "package-lock.json" changes more frequently, this way, whenever "package.json" gets updated, we won't need to reinstall Couchbase and we will use the cached layer.

Note: Couchbase takes so much time to be installed, on my system, it toke me 35 minutes :)) so let's use everything we have to avoid reinstalling again and again which this is what I did. (On the server, it took 10 mins)