DEV Community: glocore

Tip: Add Typography as Components to your Tailwind Config

glocore — Tue, 30 May 2023 04:41:50 +0000

Tailwind allows you to create custom "components" in its config via plugins.

Here's a hack to define your typography as tailwind components, using Tailwind utilities:



// tailwind.config.ts

import plugin from 'tailwindcss/plugin';

export default {
  // ...the rest of your config

  plugins: [
    plugin(({ addComponents }) => {
      addComponents({
        ".typography-h1": {
          "@apply text-[2rem] lg:text-[2.5rem]": "",
        },

        ".typography-h2": {
          "@apply text-[1.5rem] lg:text-[2rem]": "",
        },

        // ...rest of your typography
      });
    }),
  ],
};

Now you can use these components to style your markup, and you'll also receive autocomplete:

Discriminated Unions Without Common Properties

glocore — Thu, 10 Nov 2022 07:52:37 +0000

If you have two or more types without any common properties (ie., they're mutually exclusive), you can't create a discriminated union with them:


type Props = { a: boolean } | { b: string }

const obj1: Props = { a: true } // ✅ valid
const obj2: Props = { b: "hello" } // ✅ valid
const obj3: Props = { a: true, b: "hello" } // ✅ valid, but we'd like this to be an error, ie., you can either include a or b, but not both

TS Playground

Solution

If you are dealing with two types, then you can use a custom XOR type (source):


type Without<T, U> = { [P in Exclude<keyof T, keyof U>]?: never };
type XOR<T, U> = (T | U) extends object ? (Without<T, U> & U) | (Without<U, T> & T) : T | U;

// USAGE

type Props = XOR<{ a: boolean }, { b: string }>

const obj1: Props = { a: true } // ✅ valid
const obj2: Props = { b: "hello" } // ✅ valid
const obj3: Props = { a: true, b: "hello" } // ❌ error

TS Playground

You can alternatively use the ts-xor package to do exactly that.

If you have more than two types, you can nest XOR operators, like this:


type Props = XOR<{ c: number }, XOR<{ a: boolean }, { b: string }>>

TS Playground

The drawback with this XOR type is that the errors shown are cryptic, so perhaps avoid this if you're creating types for a library.

Configure Emotion with your Vite React Project

glocore — Thu, 07 Oct 2021 07:15:23 +0000

@vitejs/plugin-react-refresh was migrated into @vitejs/plugin-react, and many Emotion + Vite tutorials and boilerplates out there became outdated as a result.
The Vite monorepo has an example react-emotion setup, which seems to works quite well. Here's the gist:

1. Install Emotion Dependencies

Make sure you have the following installed:

yarn add @emotion/react
yarn add -D @emotion/babel-plugin

2. Update vite.config.js

The @vitejs/plugin-react plugin accepts a custom babel config via the babel option. Here, we add the @emotion/babel-plugin plugin we just installed.
Also, to be able to use the css prop in our JSX, we need to instruct @vitejs/plugin-react to use Emotion's jsx function instead of the default jsx-runtime when compiling JSX. We do this by setting the jsxImportSource option to @emotion/react.

import { defineConfig } from "vite";
import react from "@vitejs/plugin-react";

// https://vitejs.dev/config/
export default defineConfig({
  plugins: [
    react({
      jsxImportSource: "@emotion/react",
      babel: {
        plugins: ["@emotion/babel-plugin"],
      },
    }),
  ],
});

Optional: TypeScript support

When using Emotion with TypeScript, your editor may complain that css is not a valid prop. This is because by default, css is not a recognised prop in React and your TypeScript compiler doesn't know about Emotion. Fix this by instructing TypeScript to use types from Emotion instead:

{
  "compilerOptions": {
    "jsxImportSource": "@emotion/react"
  }
}

Hope this helps!

Tip: Create Functions to Improve Code Readability

glocore — Sat, 12 Jun 2021 13:35:04 +0000

Functions are a great way to make a chunk of code reusable. But even if you'll only ever do something once in your program, it may be a good idea to wrap it in a function to indicate what it does. This makes it easier for the reader to understand what's going on without having to read the complete implementation.

In the example below, the complex ternaries are only going to be used to create finalBaseUrl and finalPath, but it's hard to understand what's going on without actually reading the implementation.

const finalBaseUrl =
  this.baseUrl.slice(-1) === "/"
    ? this.baseUrl.slice(0, this.baseUrl.length - 1)
    : this.baseUrl;

const finalPath = path.slice(0, 1) === "/" ? path.slice(1, path.length) : path;

Instead, if we create functions with appropriate names to encapsulate the complex ternary logic, a reader can skip reading the implementation.

const dropTrailingSlash = (string) =>
  string.slice(-1) === "/" ? string.slice(0, string.length - 1) : string;

const dropLeadingSlash = (string) =>
  string.slice(0, 1) === "/" ? string.slice(1, string.length) : string;

const finalBaseUrl = dropTrailingSlash(this.baseUrl);
const finalPath = dropLeadingSlash(path);

Although we end up with more lines of code, it's much easier to scan and understand what's going on. You may instead choose to write a comment explaining your code, but such comments often tend to go out of sync as your code changes.

If you work with React, you can apply the same for hooks. Rather than having a large chunk of code in a useEffect hook, you can break it down into multiple effects and assign it relevant names to indicate what they do.

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

Thanks for reading!

Understanding ESLint Configuration

glocore — Sat, 03 Apr 2021 12:11:44 +0000

In this post, I try to make sense of the commonly used configuration options in .eslintrc. This is only a quick introduction and not a comprehensive list of all the available settings.

ESLint works on a system of "rules". These rules help you maintain consistency, enforce best practices and catch potential bugs in your code. The default eslint package comes with a set of built-in rules, but you can add more using plugins.

`parser`

A parser converts your source code into a format that ESLint understands. By default, ESLint uses a parser called "Espree", but you can use a different one by specifying it in the parser field of your .eslintrc file. For example, to be able to lint TypeScript code, you'll need to install the @typescript-eslint/parser package and specify it in .eslintrc:

{
  "parser": "@typescript-eslint/parser"
}

`plugins`

A plugin may contain rules, configs and environments. For example, if you install the React ESLint plugin (eslint-plugin-react package), you can enable it in .eslintrc like so:

{
  "plugins": ["react"] // omit the "eslint-plugin-" prefix
}

This lets you use the rules that have been defined in the plugin. The plugin may also provide "configs", which apply a set of these rules in bulk. You can enable these configs by including them in the extends field (see below).

`extends`

This field allows you to apply configs, which are a set of rules that are applied in bulk. You can install a standalone config as an npm package (like eslint-config-airbnb). Some plugins also provide their own configs (for example, eslint-plugin-react provides a config named recommended). ESLint also ships with its own recommended config.

{
  "extends": [
    "eslint:recommended",
    "plugin:react/recommended", // configs from plugins use the notation plugin:<plugin name>/<config name>
    "airbnb", // omit the "eslint-config-" prefix for standalone configs
    "../path/to/my/custom/config.js"
  ]
}

`rules`

This field lets you change settings for individual rules. If you've installed any plugin(s), you can also specify any rules included by it. Finally, you can also override any rules applied from a config. A rule's value can be one of off, warn or error.

{
  "rules": {
    "eqeqeq": "off",
    "curly": "error",
    "quotes": ["error", "double"],
    "plugin1/rule1": "error" // rules from plugins have the notation <plugin-name>/rule-name
  }
}

`env`

An environment provides predefined global variables. This lets you use global variables such as the window and global objects available in browser and node environments. To enable specific environments, add them to the env object in your .eslintrc like so:

{
  "env": {
    "browser": true,
    "node": true
  }
}

Check the docs for the full list of supported environments. You can also add environments from plugins.

Thanks for reading!

References:

React Native Navigation (RNN) with Expo Bare Workflow

glocore — Sat, 06 Mar 2021 07:32:36 +0000

React Native Navigation (RNN) uses native views to render and navigate between screens in your app. This requires some setup on your native code for it to work.
The docs mention using npx rnn-link to automatically make the required changes on your native code. When setting up RNN on my Expo app, I found that running npx rnn-link only worked for Android, and I had to go through the manual process for iOS. Here are the steps I followed:

Step 1

Run pod install inside your ios directory.

Step 2

Modify AppDelegate.m as follows. I recommend using Xcode for this as it may point out potential issues as you modify the file.

That's it! The rest of it is handled by React Native's auto-linking feature for versions > 0.60.

React Native: Command PhaseScriptExecution failed

glocore — Fri, 05 Mar 2021 17:47:36 +0000

If your React Native builds fail in Xcode with the following message:

Command PhaseScriptExecution failed with a nonzero exit code

one possible reason could be that Xcode is using an outdated version of Node (in my case, it was because I use nvm to manage my Node versions, but Xcode used an old version of Node that I had installed via HomeBrew a long time ago).

By default, Xcode will use the Node binary located at /usr/local/bin/node. Check its version by running:

/usr/local/bin/node -v
node -v

If the first command outputs an older version of Node, simply delete it and replace it with a symlink to the newer one:

rm -rf /usr/local/bin/node
ln -s $(which node) /usr/local/bin/node

Hope that helps!

Create custom Passport middleware in Express

glocore — Sun, 13 Dec 2020 07:58:36 +0000

We're going to be looking at how we can dynamically select the passport middleware that we want to use based on the requested route. This is useful if you have multiple auth handlers in your app and you want a consistent way of handling them without repeating code.

So if you find yourself doing something like this:

app.get(
  "/login/facebook",
  passport.authenticate("facebook", { /* options */ })
);

app.get(
  "/login/google",
  passport.authenticate("google", { /* options */ })
);

app.get(
  "/login/twitter",
  passport.authenticate("twitter", { /* options */ })
);

... and then handling the return callback routes like this:

app.get(
  "/login/facebook/callback",
  passport.authenticate("facebook"),
  (req, res) => {
    /* ... */
  }
);

app.get(
  "/login/google/callback",
  passport.authenticate("google"),
  (req, res) => {
    /* ... */
  }
);

app.get(
  "/login/twitter/callback",
  passport.authenticate("twitter"),
  (req, res) => {
    /* ... */
  }
);

... we can see that a lot of similar code is being repeated. This would mean that any changes that we make would have to be repeated thrice (in this case).

Refactor

Now in order to abstract this out, we can use Express' route parameters to determine the handler that we want to use.

One thing to note is that passport.authenticate() returns an Express middleware, which accepts req, res and next as arguments. So we're going to take advantage of this fact by forwarding these arguments to the passport middleware.

So for the initial login route handler, we're going to refactor it like this:

app.get("/login/:provider", (req, res, next) => {
  const { provider } = req.params;

  const passportOptions = {
    // compose your options object
    // here based on the provider.
  };

  const passportMiddleware = passport.authenticate(
    provider, passportOptions
  );

  // this is important, else
  // you'll see a blank screen.
  passportMiddleware(req, res, next);
});

And similarly for the callback route handler:

app.get(
  "/login/:provider/callback",
  (req, res, next) => {
    const { provider } = req.params;

    const passportOptions = {
      /* ... */
    };

    const passportMiddleware = passport.authenticate(
      provider, passportOptions
    );

    passportMiddleware(req, res, next);
  },
  (req, res) => {
    // the provider route param is available
    // here too, along with the user object that
    // passport attaches upon successful authentication
    const { provider, user } = req.params;

    // ...
    // Conditional code based on the provider.
    // Preferably, the conditional logic would
    // be defined elsewhere, where it would accept
    // a `provider` as an argument and would
    // return data accordingly. This would ensure that
    // the route handler code doesn't get cluttered
    // with conditional logic.
  }
);

Typos? Improvements?

Thanks for reading. If you notice any typos or would like to suggest improvements, please feel free to either create an issue or PR here.

Quick Express-TypeScript Setup

glocore — Fri, 27 Nov 2020 08:26:17 +0000

Steps to create a barebones Express app with TypeScript and ESLint.
A sample app setup is available here. To clone it locally, run:

npx degit metamodal/blog/quick-express-typescript-setup/example express-ts-project

Else follow along to setup the project manually.

Step 1

Create an npm project:

mkdir express-ts-project
cd express-ts-project
npm init -y

Step 2

Install dependencies:

# Express-related deps
npm install express cors

# Tooling
npm install -D typescript eslint nodemon ts-node @typescript-eslint/eslint-plugin @typescript-eslint/parser

# Typings
npm i -D @types/cors @types/express @types/node

cors: to allow cross-origin requests
ts-node: to run TypeScript programs directly from the terminal (instead of having to transpile to JavaScript first)
nodemon: to run your project in "watch" mode, meaning the program is automatically restarted every time you change your code
@typescript-eslint/parser: allows ESLint to understand TypeScript syntax
@typescript-eslint/eslint-plugin: loads the ESLint rules defined by you

Step 3

Create a file named tsconfig.json in the root of your project and paste the following config:

{
  "compilerOptions": {
    "lib": ["es2018"],
    "module": "commonjs",
    "target": "es2018",

    "strict": true,
    "esModuleInterop": true,
    "skipLibCheck": true,
    "forceConsistentCasingInFileNames": true,
    "sourceMap": true,
    "outDir": "dist"
  },
  "include": ["src/**/*"],
  "exclude": ["node_modules", "**/*.spec.ts"]
}

Step 4

Create a file named .eslintrc in the root of your project, and paste the following config:

{
  "root": true,
  "parser": "@typescript-eslint/parser",
  "plugins": [
    "@typescript-eslint"
  ],
  "extends": [
    "eslint:recommended",
    "plugin:@typescript-eslint/recommended"
  ]
}

Step 5

Create a folder named src and inside it a file src/index.ts. Paste the following in index.ts:

import express from "express";
import cors from "cors";

const app = express();
const port = 3000;

app.use(cors({ origin: true }));

app.get('/', (req, res) => {
  res.send('Hello World!')
})

app.listen(port, () => console.log("Listening on port " + port));

Step 6

Add the following in the scripts object in package.json:

"scripts": {
  "build": "tsc",
  "start": "nodemon src/index.ts"
}

Step 7

From the root of your project, run the command:

npm start

Go to http://localhost:3000 on your browser. If you see "Hello World!" printed on your screen, everything has worked correctly.

Typos? Improvements?

Thanks for reading. If you notice any typos or would like to suggest improvements, please feel free to either create an issue or PR here.

Control a Dialog Box Asynchronously using React Hooks

glocore — Thu, 25 Jun 2020 11:28:37 +0000

We often control dialog boxes by including the component in our JSX and controlling its visibility and behaviour with state variables and props.

Most of the time however, these are pretty standard components that require very little data to render, like a confirmation dialog box, for example. With hooks, we should be able to do something like this:

const { getConfirmation } = useConfirmationDialog();

// ...

const confirmed = await getConfirmation({
  title: "Attention!",
  message: "Are you sure you would like to delete this entry?",
});

if (confirmed) {
  // perform operation
}

In this post, we will create the above hook. This will allow us to have a single confirmation dialog box at an app-level, and communicate with it using the context API.

An example implementation of this can be found in this CodeSandbox.

Step 1: Setup the context

Create an empty context object and a provider HOC, which we can later wrap at an app level.

import React from "react";
import ConfirmationDialog from "./ConfirmationDialog";

const ConfirmationDialogContext = React.createContext({});

const ConfirmationDialogProvider = ({ children }) => {
  return (
    <ConfirmationDialogContext.Provider>
      <ConfirmationDialog />
      {children}
    </ConfirmationDialogContext.Provider>
  );
};

Step 2: Add the control mechanism

Here we add a state variable dialogOpen to control the visibility of the dialog. We also create another state variable called dialogConfig, which would contain the dialog content and action callback.

We then use these to create trigger functions for displaying the dialog, as well as handler functions that are called when the action buttons are pressed.

const ConfirmationDialogProvider = ({ children }) => {
  const { dialogOpen, setDialogOpen } = React.useState(false);
  const { dialogConfig, setDialogConfig } = React.useState({});

  const openDialog = ({ title, message, actionCallback }) => {
    setDialogOpen(true);
    setDialogConfig({ title, message, actionCallback });
  };

  const resetDialog = () => {
    setDialogOpen(false);
    setDialogConfig({});
  };

  const onConfirm = () => {
    resetDialog();
    dialogConfig.actionCallback(true);
  };

  const onDismiss = () => {
    resetDialog();
    dialogConfig.actionCallback(false);
  };

  return (
    <ConfirmationDialogContext.Provider value={{ openDialog }}>
      <ConfirmationDialog
        open={dialogOpen}
        title={dialogConfig.title}
        message={dialogConfig.message}
        onConfirm={onConfirm}
        onDismiss={onDismiss}
      />
      {children}
    </ConfirmationDialogContext.Provider>
  );
};

Step 3: Create a hook to trigger the dialog

Use this hook to trigger the dialog from anywhere in your app. It returns a function that lets you await the user input. This would let you use the async/await syntax rather than passing in a callback.

const useConfirmationDialog = () => {
  const { openDialog } = React.useContext(ConfirmationDialogContext);

  const getConfirmation = ({ ...options }) =>
    new Promise((res) => {
      openDialog({ actionCallback: res, ...options });
    });

  return { getConfirmation };
};

Step 4: Add the provider HOC at the app level

Finally, we wrap that HOC we created in Step 1 around our app (or at whatever level you prefer).

const App = () => {
  return (
    <ConfirmationDialogProvider>
      {/* Your app here */}
    </ConfirmationDialogProvider>
  );
}

Usage:

const { getConfirmation } = useConfirmationDialog();

// ...

const confirmed = await getConfirmation({
  title: "Attention!",
  message: "Are you sure you would like to delete this entry?",
});

if (confirmed) {
  // perform operation
}

Once again, here's a CodeSandbox of an example implementation.

Typos? Improvements?

Thanks for reading. If you notice any typos or would like to suggest improvements, please feel free to either create an issue or PR here.

Add Jitsi Meet to your React App

glocore — Wed, 24 Jun 2020 06:16:58 +0000

Step 1: Create a container for Jitsi

The Jitsi iframe needs a container element of a pre-defined height and width to render into.

import React from "react";

const VideoConference = () => {
  const jitsiContainerId = "jitsi-container-id";

  return <div id={jitsiContainerId} style={{ height: 720, width: "100%" }} />;
};

export default VideoConference;

Step 2: Load the Jitsi Meet API Library Script

Unfortunately, this isn't available as an NPM module, and so we're gonna have to go old-school here. We first create a <script/> element with its src pointing to the source of the API library. We then append this to the document's body.

The script takes an onload callback, which runs once the script has been loaded and executed. In order to convert this into a promise, we pass it the resolve method of an empty promise.

const VideoConference = () => {
  // const jitsiContainerId = ...

  const loadJitsiScript = () => {
    let resolveLoadJitsiScriptPromise = null;

    const loadJitsiScriptPromise = new Promise((resolve) => {
      resolveLoadJitsiScriptPromise = resolve;
    });

    const script = document.createElement("script");
    script.src = "https://meet.jit.si/external_api.js";
    script.async = true;
    script.onload = resolveLoadJitsiScriptPromise
    document.body.appendChild(script);

    return loadJitsiScriptPromise;
  };

  // return ( ... )
};

Let me know in the comments if you have a more elegant way of promise-ifying the script loading part! 😄

Step 3: Load the Jitsi IFrame

Once the script is loaded, it adds a class named JitsiMeetExternalAPI to the global window object. Instantiating this class loads the Jitsi iframe and returns an API object, which we can later be used to customise and control the Jitsi interface.

const VideoConference = () => {
  // const jitsiContainerId = ...
  const [jitsi, setJitsi] = React.useState({});

  // const loadJitsiScript = () => { ... }

  const initialiseJitsi = async () => {
    if (!window.JitsiMeetExternalAPI) {
      await loadJitsiScript();
    }

    const _jitsi = new window.JitsiMeetExternalAPI("meet.jit.si", {
      parentNode: document.getElementById(jitsiContainerId),
    });

    setJitsi(_jitsi)
  };

  React.useEffect(() => {
    initialiseJitsi();

    return () => jitsi?.dispose?.();
  }, []);

  // return ( ... )
};

Our initialiseJitsi function is called only once when the component is first rendered, and Jitsi's dispose() method is called when the component is destroyed.

Good!

This should give you a barebones setup. Here's a CodeSandbox with what we've done so far.

Configure Jitsi

There are quite a few options to configure your Jitsi iframe. For example, if you are rolling your own Jitsi server, you can specify its URL endpoint instead of meet.jit.si. The object from instantiating JitsiMeetExternalAPI also provides quite a few methods and event listeners to configure and control the Jitsi interface. Check out Jitsi's docs for all the options, methods and events available.