DEV Community: Minh-Phuc Tran

Make Copyable Code Block For Your Blog

Minh-Phuc Tran — Sun, 31 Jan 2021 04:46:28 +0000

A couple of days ago I implemented a feature to allow viewers on my website to easily copy code blocks on my website. Personally, it is quite a useful feature
for a technical blog.

In this article, I'm going to share how you can implement the same for your sites - applicable to all React-based sites.

`useCopyableRef` hook

Thanks to React hook functionality, I've encapsulated the logic into an easily understandable and reusable hook:

import { useRef, useState } from "react";
import copyToClipboard from "copy-to-clipboard"; // You'll need this package: `yarn add copy-to-clipboard`.

const useCopyableRef = <T extends HTMLElement = HTMLElement>(
  delay: number = 4 * SECONDS // You may want to change this to 4000, or define SECONDS somewhere in your application.
) => {
  const ref = useRef<T>(null);

  const [isCopied, setCopied] = useState(false);
  const copy = () => {
    if (isCopied) return;

    if (!ref.current) throw new Error("Ref is nil.");
    copyToClipboard(ref.current.textContent || "");

    setCopied(true);
    setTimeout(() => setCopied(false), delay);
  };

  return { ref, isCopied, copy };
};

export default useCopyableRef;

It's simple, right?

Usage in UI components

useCopyableRef is similar to useRef, additionally, it returns isCopied and copy props, which you'd need to implement your UI components.

Implementing your UI components can be as simple as the following example:

import useCopyableRef from "~/hooks/useCopyableRef";

const CodeBlock = (props: React.HTMLProps<HTMLPreElement>) => {
  const { ref, isCopied, copy } = useCopyableRef<HTMLPreElement>();
  return (
    <>
      <pre ref={ref} {...props} />
      <button onClick={copy} disabled={isCopied}>
        {isCopied ? "Copied!" : "Copy"}
      </button>
    </>
  );
};

export default CodeBlock;

That's it, don't forget to style your components however you want to!

MDX (Unified) Mutating Options Object Cost Me 2 Hours

Minh-Phuc Tran — Thu, 28 Jan 2021 14:28:59 +0000

A couple of days ago, I got into a very annoying issue while using MDX in my Next.js website. It cost me almost 2 hours to resolve.

Context

First, let's quickly go through some technical concepts in case you didn't work with MDX and Next.js a lot:

MDX is essentially a set of unified plugins. unified is a generic interface for processing content as structured data. Thanks to this, I was able to write granular plugins to customize how I use MDX quite extensively.
Next.js is built on top of Webpack and loads MDX from a Webpack loader (@mdx-js/loader).
I have different plugins and configurations for different MDX documents based on their file paths so that I can have custom syntaxes for different types of documents.

In order to achieve that I have a custom Next.js plugin that will resolve into different MDX options for different documents:

const configureMDX = ({ realResource }) => {
  if (realResource.startsWith(folders.blog)) return configs.blog;
  if (realResource.startsWith(folders.cheatsheet)) return configs.cheatsheet;
  return configs.base;
};

module.exports = (next = {}) =>
  Object.assign({}, next, {
    webpack(config, appOptions) {
      config.module.rules.push({
        test: /\.(md|mdx)$/,
        use: (info) => [
          appOptions.defaultLoaders.babel,
          {
            loader: require.resolve("@mdx-js/loader"),
            options: configureMDX(info),
          },
        ],
      });

      if (typeof next.webpack === "function") {
        return next.webpack(config, appOptions);
      }

      return config;
    },
  });

configs.base, configs.blog, and configs.cheatsheet are just typical MDX options:

// configs.base
module.exports = {
  remarkPlugins: [
    frontmatter,
    parseFrontmatter,
    [
      extractFrontmatter,
      {
        title: { type: "string" },
        description: { type: "string" },
      },
    ],
    unwrapTexts,
    titleFromContents,
    descriptionFromContents,
    pageURLElements,
    [namedExports, ["title", "description", "url", "path", "folder", "slug"]],
  ],
  rehypePlugins: [prism, a11yEmojis],
};

// configs.blog
module.exports = {
  remarkPlugins: [
    frontmatter,
    parseFrontmatter,
    [
      extractFrontmatter,
      {
        title: { type: "string" },
        description: { type: "string" },
        date: { type: "string", format: "date", required: true },
        tags: {
          type: "array",
          items: { type: "string", minLength: 1, required: true },
          uniqueItems: true,
          maxItems: 4,
        },
        cover: {
          type: "object",
          properties: {
            url: { type: "string", format: "url" },
            icons: {
              type: "array",
              items: { type: "string", minLength: 1, required: true },
              uniqueItems: true,
              maxItems: 3,
            },
          },
        },
      },
    ],
    unwrapTexts,
    titleFromContents,
    descriptionFromContents,
    pageURLElements,
    generatedCover,
    [
      namedExports,
      [
        "title",
        "description",
        "url",
        "path",
        "folder",
        "slug",
        "date",
        "tags",
        "cover",
      ],
    ],
    [defaultExport, "~/layouts/blog"],
  ],
  rehypePlugins: [prism, a11yEmojis],
};

It's quite natural, right? Indeed, it worked just fine with Next.js dev server. It only failed when building for production.

The issue

Basically, I used the plugin extractFrontmatter to both validate and expose
attributes from frontmatter as props to my layout component. Only blog documents
required date attribute. Nonetheless, when I built for production, all documents required all attributes from different configurations combined! It was as if someone merged all the configurations together before executing the build process, despite the fact that the configuration code I wrote is completely side-effect free - all functions are pure and just return values without modifying anything.

I started to look into @mdx-js/loader code, then @mdx-js/mdx code, and they all looked just fine.

So, I had to debug further to see when the options got modified (I actually just
did console.log).

All values returned from my configureMDX are correct, so there was nothing wrong here. These values will then be sent to @mdx-js/loader invocations and it was magically modified somehow right at the beginning of @mdx-js/loader.

I really had no idea how it worked this time and just did tons of different guesses, made changes upon, and saw how it turned out 😥.

The fix

Thank god! After ~2 hours, I had (probably) a correct guess and managed to fix the issue.

Webpack code didn't look like modifying anything (although the logs showed changes happened right at the beginning of a Webpack loader), MDX code didn't look like modifying anything either, so I guessed Unified did it. I jumped into unified repository, and... yeah, it mutated the plugin options 🥶.

function addPlugin(plugin, value) {
  var entry = find(plugin);

  if (entry) {
    if (plain(entry[1]) && plain(value)) {
      value = extend(entry[1], value); // this equals Object.assign(...)
    }

    entry[1] = value;
  } else {
    attachers.push(slice.call(arguments));
  }
}

But really? All returned values from my configureMDX are correct, when this mutation takes place? I'm still not sure, at this time, I really just want to fix the issue and get rid of it.

So, to avoid the mutation, I simply changed my configuration code from objects to functions returning the object, this way all mutations will be discarded:

const configureMDX = ({ realResource }) => {
  if (realResource.startsWith(folders.blog)) return configs.blog();
  if (realResource.startsWith(folders.cheatsheet)) return configs.cheatsheet();
  return configs.base();
};

My guess was that Next.js or Webpack resolves configurations for every file before invoking loaders, this way all values returned by configureMDX are correct before going into loaders, then right after the first loader execution, it got mutated.

Final thought

This post isn't to blame anyone, I really enjoy using the Unified and MDX so far, and I appreciate the authors' works a lot. This post is just a rare story that I think other developer folks may find interesting. The lesson from this is to implement your code in a way that as side-effect free as possible, because it makes the flow crystal clear and intuitive, side effects make debugging very hard! When you can't avoid side effects, make sure to document and highlight it!

How-to Integrate Plausible Analytics With Next.js and Vercel

Minh-Phuc Tran — Mon, 25 Jan 2021 13:07:28 +0000

Plausible is a privacy-focused analytics solution for modern websites. It and Fathom are probably 2 biggest names in the space. I chose Plausible because its pricing is more beginner-friendly and it is also open-source.

This article is a quick snippnet that I wrote to properly enable Plausible for my Next.js + Vercel website.

Plausible Script component

To enable Plausible, you'll need place a script tag in head of your HTML document. To achieve that in Next.js, I create a component for easier maintainance:

// ~/components/plausbile-script.tsx
import Head from "next/head";
import PKG from "~/package.json"; // Load configuration from package.json.

const PlausibleScript = () => (
  <Head>
    <script
      key="plausible-script"
      src={PKG.site.plausible.scriptURL}
      async
      defer
      data-domain={new URL(PKG.homepage).host}
    />
  </Head>
);
export default PlausibleScript;

Then render it in my pages/_app.(jsx|tsx):

// ~/pages/_app.tsx
import PlausibleScript from "~/components/plausible-script";

const MyApp = ({ Component, pageProps }: AppProps) => (
  <>
    <Head>
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      {/* Other head elements */}
    </Head>
    <PlausibleScript />
    <Component {...pageProps} />
  </>
);

Put configuration in `package.json`

You may realize that my PlausibleScript doesn't directly define script src, instead it references values from package.json. Personally, package.json is a great place to put configuration for a site or package (the name said it, right?), package.json isn't just for npm.

// ~/package.json
{
  // ...
  "description": "🏚 Home on the Web — Everything I learned and created: software dev, programming tutorials, career, startups, and open-source.",
  "homepage": "https://phuctm97.com",
  "site": {
    "title": "Minh-Phuc Tran - Software Engineer",
    "plausible": {
      "scriptURL": "https://plausible.phuctm97.com/js/index.js"
    }
  }
  // Other values...
  // Keep configuration in package.json is also a great way to separate implementation details and configurations.
}

Doing this way I can also reuse standard npm values , in this case, it is homepage.

Enable only in production

Finally, I don't want views on my local and preview environment to be counted, Plausible should only be enabled in production. To achieve that, I simply update my _app.tsx:

// ~/pages/_app.tsx
import PlausibleScript from "~/components/plausible-script";
import { IS_PRODUCTION } from "~/constants";

const MyApp = ({ Component, pageProps }: AppProps) => (
  <>
    <Head>
      <meta name="viewport" content="width=device-width, initial-scale=1.0" />
      {/* Other head elements */}
    </Head>
    {IS_PRODUCTION && <PlausibleScript />}
    <Component {...pageProps} />
  </>
);

Because I'm hosting my site on Vercel, IS_PRODUCTION is:

// ~/constants.ts
export const IS_PRODUCTION =
  process.env.NODE_ENV === "production" &&
  process.env.VERCEL_ENV === "production";

VERCEL_ENV is a system environment variable defined by Vercel while building and running your applications for specific environments (preview and production). To be able to reference it client-side in a Next.js application, you'll need to modify your next.config.js:

module.exports = {
  // Other configurations.
  env: {
    VERCEL_ENV: process.env.VERCEL_ENV,
  },
};

That's it 🤟🏻!

How-to Keep Your Packages Always Up-to-date with Dependabot

Minh-Phuc Tran — Fri, 15 Jan 2021 12:27:27 +0000

One of the ways that I do to keep myself up-to-date with the latest technologies is to configure automatic dependencies upgrade, which helps in 2 ways:

Keep my products/packages always up-to-date, especially avoid potential vulnerability as soon as possible.
Remind me of the technologies I'm using that have introduced new features or bug fixes. I can quickly look at it and learn what is newly possible.

In this article, I'll walk you through how I did it very easily and conveniently.

Last Sunday, there were quite a few packages updated in my products.

Dependabot

Dependabot is a Github bot that automatically tracks and opens PRs to update dependencies for you. It used to be a separate product but was acquired by Github in 2020 and became available completely for free 🤯.

Basic configuration

To configure it, you need just a couple of lines of code:

Create a file .github/dependabot.yml in your repository.
Add some configuration to instruct Dependabot what to update:

version: 2

updates:
  - package-ecosystem: npm
    directory: /
    schedule:
      interval: weekly
  - package-ecosystem: github-actions
    directory: /
    schedule:
      interval: weekly

Dependabot supports a lot of different package ecosystem including npm, Python, Go, Rust, Maven, Docker, etc, and also Github Actions recently. Check out more here.

Interval

You can configure Dependabot to update daily, weekly, or at another specific interval. My experience with weekly updates is the best so far.

Workflow

After commiting your dependabot.yml to your repository, Dependabot will help you update packages by opening PRs, which you can accept or reject. By receiving updates via PRs, you get a chance to make sure that all your tests/checks are passed before promoting to your live distribution.

Dependabot is also intelligent enough to automatically rebase PRs when you pushed new changes to master (or whatever branch you configured), so you don't always have to review and merge it right away. In fact, I often ignore it until late in the day, when my energy level is the lowest, then I review one or several of them.

Badge

One little tip that I often do especially for an open-source package is to put a badge letting the users know that this package is configured to be automatically up-to-date.

![dependabot status](https://img.shields.io/badge/dependabot-enabled-025e8c?logo=Dependabot)

That's it. Dependabot has been super convenient for me, especially for open-source packages that I've done implementing and don't want to think about maintaining its dependencies. I hope it will benefit you, too!

Simple Script Cut 50% Size Of My React Website

Minh-Phuc Tran — Tue, 12 Jan 2021 13:12:08 +0000

Hi friends, it's @phuctm97 again. It has been 3 days since my last post, it's my first week at my new job so things have been a little hectic 🤓. Anyway, today article is a very simple but kinda mindblowing script that I did a couple
of days ago in my Next.js/React website that cut my site's bundle size from 90kb to a little less than 50kb.

Before:

After:

So here is how.

Note: my site is built on top of Next.js (and React).

Preact

It's all possible thanks to Preact. Preact is a 3kb alternative implementation of React that provides 100% compatible APIs to React, what it means is that Preact and React are interchangeable but Preact is 4kb whereas React is 40kb. You may be skeptical about whether it's stable, see this list of companies, you'll be confident using it.

So, it's kinda no-brainer to use Preact. However, do keep in mind that the team implementing Preact and React are separate and we aren't sure about what will happen in the future. Also, Preact devtools support is currently quite limited in comparison to React.

So, I figure the best way to use it:

Dev with React and simply swap React and Preact in production bundle, no changes to my dependency tree - I got the best of both worlds, amazing devtools and ecosystem of React and smallest bundle size of Preact for my users 🔥.

Next.js plugin

My website is powered by Next.js, however the same concept is appliable to any other React-based project:

const withPreact = (next = {}) =>
  Object.assign({}, next, {
    webpack(config, options) {
      const { dev, isServer } = options;

      // Use Preact only in client production bundle.
      if (!dev && !isServer) {
        Object.assign(config.resolve.alias, {
          react: "preact/compat",
          "react-dom": "preact/compat",
          "create-react-class": "preact-compat/lib/create-react-class",
          "react-dom-factories": "preact-compat/lib/react-dom-factories",
        });
      }

      if (typeof next.webpack === "function") {
        return next.webpack(config, options);
      }

      return config;
    },
  });

const withMDX = require("@next/mdx")();

module.exports = withPreact(
  // Any other Next.js config. MDX is used as an example for compatibility here.
  withMDX({
    pageExtensions: ["ts", "tsx", "mdx"],
  })
);

You can see that I'm able to use other React-based technologies, too, (MDX in this case).

Also, you'll need to have Preact installed in your package.json:

yarn add preact

Alright, that is it! I'm using it in my website, it's really a no-brainer using Preact this way. Don't worry, I'll let you know whenever my website is not functioning correctly 😉.

Hope it is simple and useful enough to help you save half of your site tomorrow, too!

Write My First Tailwind CSS Plugin

Minh-Phuc Tran — Sat, 09 Jan 2021 13:53:42 +0000

Building my website for a while using Tailwind CSS, I started to have more and more specific needs like backdrop-filter to create blur overlay effects, autofill pseudo-class to style form fields when they have been autocompleted, etc, and these use cases weren't covered by TailwindCSS core packages. So I had to leave my HTML and write separate CSS files to be able to use custom CSS properties. Although writing separate CSS is fine, I just don't like having ad
hoc CSS files here and there, which feels like an anti-pattern using Tailwind CSS for me, especially when your theming system starts to appear everywhere. So, I asked:

"Why don't I just create a TailwindCSS plugin, I'll get to see how it works more specifically, too!".

So, here I am.

TL;DR: It turned out pretty fun!

tailwindcss-autofill variant

The first plugin adds a variant, which is to add styles when an element entered a special state like hover, focus, etc.

The state I needed is when a form field was autocompleted.

By default, when a form field has been autocompleted, its foreground and background will be changed to some browser defaults.

But the defaults clearly don't work with my design. The perfect way to style it with TailwindCSS is:

<input className="autofill:bg-white autofill:text-gray-700" />

So, I wrote a variant to support it. It turned out to be quite simple:

const plugin = require("tailwindcss/plugin");

const autofill = plugin(({ addVariant, e }) => {
  addVariant("autofill", ({ modifySelectors, separator }) => {
    modifySelectors(({ className }) => {
      const newClass = e(`autofill${separator}${className}`);
      return [
        `.${newClass}:-webkit-autofill`,
        `.${newClass}:-webkit-autofill:hover`,
        `.${newClass}:-webkit-autofill:focus`,
      ].join(",");
    });
  });
});

module.exports = autofill;

What I did is calling addVariant in a tailwindcss/plugin invocation with 2 essential things:

A name or indicator: autofill. This will enable the syntax autofill:text-gray-100.
A function that will modify the suffixed class. For example, when I use autofill:text-gray-100, this function will receive a className = text-gray-100 and its job is to modify this class into something that will properly handle the targeted state, which is -webkit-autofill in this case.

I released this as an NPM package, check out its repo to see more.

Now, what I needed to do is to just add this plugin into plugins in my tailwind.config.js.

module.exports = {
  // ...
  plugins: [
    require("tailwindcss-autofill"),
    // Other plugins.
  ],
  variants: {
    extend: {
      // Enable `autofill` variant for essential plugins.
      borderColor: ["autofill", "dark"],
      textColor: ["autofill", "dark"],
      backgroundColor: ["autofill", "dark"],
    },
  },
};

This plugin works fine with borderColor, focusRing, and most others, unfortunately, backgroundColor and textColor won't work because the browsers use special properties that got prioritized (it's weird). So, I had to hack it further, and the solution is to use -webkit-text-fill-color for the foreground and a special box-shadow value to override the background.

tailwindcss-text-fill and tailwindcss-shadow-fill

-webkit-text-fill-color and background fill using box-shadow are again special properties that weren't supported by TailwindCSS core packages. So, I wrote 2 other plugins, tailwindcss-text-fill and tailwindcss-shadow-fill respectively.

This time, the two new plugins add utilities instead of variants. TailwindCSS utilities are classes to conveniently style elements like text-gray-100, bg-red-50, etc.

Here is the code of one of them:

const plugin = require("tailwindcss/plugin");
const flatten = require("flatten-tailwindcss-theme");

const textFill = plugin(
  ({ addUtilities, variants, theme, e }) => {
    const colors = flatten(theme("colors"));
    const utils = Object.entries(colors).reduce(
      (res, [key, value]) =>
        Object.assign(res, {
          [`.${e(`text-fill-${key}`)}`]: {
            "-webkit-text-fill-color": value,
          },
        }),
      {}
    );
    addUtilities(utils, variants("textFill"));
  },
  { variants: { textFill: [] } }
);

module.exports = textFill;

This plugin will generate multiple text-fill-{color} classes for you, like what text-{color} or bg-{color} did. The cool thing about this is it dynamically respects your theme and generate classes for only colors you are used to (colors in your current design system) and all Intellisense features on VS Code are automatically integrated (same for the tailwindcss-autofill plugin):

Final result

Finally, it worked 🔥!

Here is how I styled my component:

<input
  className={classNames(
    "bg-white dark:bg-gray-800 text-gray-900 dark:text-gray-100",
    "autofill:text-fill-gray-900 autofill:shadow-fill-white dark:autofill:shadow-fill-gray-800 dark:autofill:text-fill-gray-100"
  )}
/>

To see the final result in real life, checkout my website and test the Subscribe to the newsletter form input yourself to see the result now!

Final thoughts

I know what you're thinking now

A couple of different CSS properties and pseudo-classes turned into 3 JS plugins.

Yeah, it is true. But the fact is these plugins didn't take a lot of time or LoCs either, especially now I've already known how to do it, it took literally the same energy compared to creating separate CSS, class names, and maintaining them along with other Tailwind-based configurations. On the other hand, I can reuse these plugins for different purposes in the future, too. And also remember
that it is rare to write extra CSS when using Tailwind, the more plugins I (and others) added, the less likely I had to write extra CSS in future projects.

All the plugins are released and open-source, check out if you want to see more:

Upgrade My Blog From Plain HTML to "Well-Designed" In 2 Weeks. I Suck.

Minh-Phuc Tran — Thu, 07 Jan 2021 14:12:48 +0000

About 3 weeks ago, I started my blog in plain HTML, then gradually tried to make it look better and more modern-ish. It has been 2 weeks so far and I've never liked how my website looked only until today.

Checkout my website if you want to see how it looks first.

2 weeks was too long...

2 weeks ago, if anyone said to me that it's going to take 2 weeks to make a blog look good, I'd definitely say back "It's way too long man, it shouldn't take that long!". And yeah, it took me 2 weeks and I've been saying that to myself every single day in the last 2 weeks. It didn't feel good at all, it felt like years.

So what's wrong?

It always "looks" better in my imagination

When I first talked to myself that I'm going to make my website look better, I could immediately have an imagination inside my head about how it were going to look amazing and how easy it were to implement it - just put some CSS and that's it.

The problem with my imagination was that things looked good because I believed they were gonna look good, not because every single detail in it actually looked good. There were no detail in my imagination, literally zero detail.

(Try this yourself, remember the last time that you imagined you were going to make something beautiful, try to go into details of that "beautiful" thingy and see if you know what every single detail really looked like)

When I started to sit down and write some code, I had to face the details that never existed in my mind. There was no surprise, I had no idea how each element should look, especially when sitting next to each other. I ended up just trying lots of different combinations and they all just looked bad!

Looking for inspiration

Being stuck and feeling like I'm the worst developer in the world, I decided to look for some inspiration and then maybe just copy-paste to save my life.

Then, I realized that my imagination was really just the style of how I want my website to look. I ended up with the following list:

These websites roughly describe my imagination.

The trap of inspiration

Having an inspiration helped to sharpen the details of my imagination, like a button, a paragraph, a title, or a form.

I thought that I were going to make it this time but I fell into another trap:

I don't want my website to look exactly the same as any of these websites, but it should look similar.

So, I put pieces from this and pieces from that into my website, and guess what, my website became a mess.

F*ck! It was all because of these websites, I shouldn't use in the first place, I should have come up with my design system.

(LoL, I'm laughing at myself writing this now, my thinking process was just so weird)

A way out

You may have thought that I was just kidding about dropping the inspiration sites, but I actually did it. However, I didn't start any design system, it was just an overkill doing so, and you've probably realized that there's no way I could build a design system myself now.

What I did was just to think about my website's design systematically. What it means is to start with the layout first, what sections my site should have, then
what content each section should display, and why. Then for each section, I implement it separately, if a section is too big, I break it down into multiple elements again and repeat the same process. The key point of this method is to not allow you to overthink about the details, just imagine the site as a set of black boxes and your design job is to put these black boxes together, you'll go into each box later. Once you've done, you don't go back.

Alright, that's it, there are more specific knowledge into building the actual site, but it was late now and I wanted to focus on the design part in this article. Hope you enjoy the story and learn something from it!

Auto Shrink Header On Scroll in React

Minh-Phuc Tran — Mon, 04 Jan 2021 13:54:07 +0000

I've always liked this effect: keep the header of your website sticky then auto-shrink and blur when users scroll down.

Today, I finally got some free time to implement it for my website, so I'm writing this article hopefully to help you do the same for yours if you also like it 😉.

Motivations

There're 2 primary motivations that makes me love this effect:

You can put a couple of calls to action (CTAs), then as your users are reading content on your website, they keep seeing these CTAs, which can increase the odds that they'll click them. I like to keep links to my newsletter and Twitter here. (An extra tip that I like to do here is to make a little animation or transition that occasionally runs to remind the user's the CTAs)
I want to optimize for CTAs but I don't want users on my website to have bad experience, which is actually even more important. To avoid bad UX, the header shouldn't take too much space, especially when users are reading the main content.

How-to

Basic idea

The basic idea is to subscribe to onscroll event of the browser, then check if the user scrolls pass a certain offset and update CSS of the header component arcordingly.

Subscribe to `onscroll` using hook



const Header = () => {
  useEffect(() => {
    const handler = () => {
      // Check and update component here.
    };

    window.addEventListener("scroll", handler);
    return () => window.removeEventListener("scroll", handler);
  }, []);

  // return <Component ... />
};

Use useEffect hook to subscribe to event onscroll when the component is mounted (notice the last parameter []), also remember to return an unsubscribe function when the component is unmounted to avoid memory leaks.

Check for scroll position



const Header = () => {
  const [isShrunk, setShrunk] = useState(false);

  useEffect(() => {
    const handler = () => {
      setShrunk((isShrunk) => {
        if (
          !isShrunk &&
          (document.body.scrollTop > 20 ||
            document.documentElement.scrollTop > 20)
        ) {
          return true;
        }

        if (
          isShrunk &&
          document.body.scrollTop < 4 &&
          document.documentElement.scrollTop < 4
        ) {
          return false;
        }

        return isShrunk;
      });
    };

    // Previous logic.
  }, []);

  // return <Component isShrunk={isShrunk} />
};

Notice setShrunk is called with a function instead of just pure value, this pattern helps ensure we are checking against the lastest previous value. Also, there are a gap between offsets to shrink and to expand (20 and 4), this helps avoid flashing of changed styles.

That's it. I hope it helps. Check out the full source code to see more details.

Misunderstanding @tailwindcss/typography costs me 2 hours

Minh-Phuc Tran — Sat, 02 Jan 2021 12:41:50 +0000

After falling in love with Tailwind CSS, I incorporated it into my website. However, there's one thing that is both nice and annoying about Tailwind CSS is that it has a very opinionated CSS reset, which clears pretty much all default styles. I understand Tailwind creators' rationale for it, having everything reset to "no style" means all styles are consciously implemented by you, there's no surprise. So, I said "Okay, I guess I have to implement my own 'default style' then.".

Why having default style?

There's a reason why browsers had default styles:

Imagine going back to the time when there was no CSS, only HTML.

HTML was first created to write and share stories, that's why we had h1, h2, h3, p, strong, em, etc, and because of their meanings (heading, paragraphs, strong, emphasized, etc), there should visual way to express these meanings to readers (who don't know HTML tags).

This style of writing is still mainstream on the web, most contents on the web are still articles with headings, paragraphs, images, etc. Markdown was also created to make this type of writing easier, every Markdown token is basically a mapping to an HTML tag.

So, for a blog, these default styles are a must.

What does the implementation look like?

Implementing default styles isn't difficult, however it takes time to make things look good, especially for edge cases when these elements are stacked or nested together. Here is my very simple one that took me ~2 hours:

@layer base {
  main {
    @apply container max-w-2xl mx-auto my-10 px-4 lg:px-0;
  }
  h1,
  h2,
  h3,
  h4,
  h5,
  h6 {
    @apply font-medium pt-5 mb-2;
  }
  h1 {
    @apply text-5xl;
  }
  h2 {
    @apply text-4xl;
  }
  h3 {
    @apply text-3xl;
  }
  h4 {
    @apply text-2xl;
  }
  h5 {
    @apply text-xl;
  }
  h6 {
    @apply text-lg;
  }
  p {
    @apply font-normal text-base mb-4;
  }
  blockquote {
    @apply bg-gray-100 my-6 pt-4 pb-px px-3 border-l-8 border-gray-300;
  }
  ol,
  ul {
    @apply mb-4 pl-8;
  }
  ol {
    @apply list-decimal;
  }
  ul {
    @apply list-disc;
  }
  ol ol,
  ol ul,
  ul ol,
  ul ul {
    @apply mb-0;
  }
  ul ul,
  ol ul {
    list-style-type: circle;
  }
  pre {
    @apply mb-4 p-5 overflow-auto;
    background: #f5f2f0; /* for consistency with Prismjs theme */
  }
  code {
    @apply bg-gray-100 text-sm font-bold p-1 rounded-sm;
  }
  code:before,
  code:after {
    @apply font-normal text-xs;
    content: "`";
  }
  pre code {
    @apply bg-transparent font-normal p-0;
  }
  pre code::before,
  pre code:after {
    content: none;
  }
  hr {
    @apply my-4;
  }
  a {
    @apply text-blue-500;
  }
  img {
    max-width: 100%;
    vertical-align: middle;
  }
}

Tailwind's team implemented these styles 🤦🏻‍♂️. Surprise?

After having implemented the above styles, I was okay but wasn't really happy about how it looked, so I went around to see what others did for some inspiration.

And, I found people suggesting the official plugin @tailwindcss/typography. I'd already known that Tailwind CSS supported plugins and also knew it was the only official plugin. However, because of the name, I thought it was something for us to customize fonts, which wasn't my problem. But guess what, @tailwindcss/typography was built exactly for the above reason - to provide "good" default styles for typical writing HTML tags 🤦🏻‍♂️. All you need to do is install @tailwindcss/typography, put that into the tailwindcss.config.js#plugins, and add class prose to your document top-level tag.

<article class="prose">
  <h1>Heading 1</h1>
  <p>Lorem ipsum</p>
  <!-- ... All tags inside will be styled properly-->
</article>

The plugin supports a good amount of common scenarios: nested lists, lists with paragraphs, code blocks, and even tables (which I didn't have time to implement). It also allows developers to extend and customize default styles quite easily.

So, comparing @tailwindcss/typography with my implementation was a no-brainer. And I guess I've wasted 2 hours of my time because of the name. Anyway, I learned a hard lesson that I'll remember for the rest of my life:

Typography is not just about font styles. Typography is about making written content legible, readable and appealing when displayed.

A Quick Exploration Into Deno

Minh-Phuc Tran — Thu, 31 Dec 2020 13:21:53 +0000

Deno v1 was released a couple of months ago and there were a lot of different opinions about it. Personally, I had a chance to quickly look at its documentation and did kinda like it, I also trust Ryan Dahl - the creator behind Deno (and Node.js).

So, here a deeper look into Deno and what it can potentially do.

Deno's goals

First, we should understand why Deno was created in the first place, what problems it is solving:

Deno aims to be a productive and secure scripting environment for the modern programmer.

Deno's documentation

This definitely sounds very general. I had to look further into its documentation to understand what problems Deno is solving.

First of all, although Deno and Node.js can co-exist, being another TypeScript/JavaScript runtime, Deno's ultimate end goal is definitely to replace Node.js, which means it was built to solve Node.js's problems. By describing Deno "a productive and secure scripting environment" Deno creator is saying that Deno is solving the problem of Node.js being not productive and insecure. As I worked with Node.js and a few other modern languages (Go, Kotlin) before, I definitely can relate that Node.js has these two issues:

Not productive:
- Did you ever switch from TypeScript back to JavaScript then realize that was a wrong choice? The number of LOCs in JavaScript codebase although can be fewer than the same project in TypeScript and no restriction seems to be easier, writing and collaborating in JavaScript is just much slower nowadays.
- The Node.js devtool ecosystem though is powerful, is very fragmented: npm, yarn, CDN, linter, formatter, TypeScript, Flow, etc. You see all the "starter" projects with tons of configuration files?
Insecure: I don't know if you have this feeling but every time I installed a new Node.js package, I wish the developer didn't push a virus script into it. The node_modules and installation process always feel cumbersome and insecure.

How Deno solve these problems?

TypeScript out of the box, no configuration.
Ship only an executable file, no node_modules, and run everywhere without an installation process (except for the executable itself).
Secure by default, you have to explicitly grant certain permissions before a script can do certain critical tasks.
Have builtin devtools (deno fmt, deno bundle, deno lint, etc) and is a package manager itself.
ES Modules native. Imports via URLs.
Be browser-compatible.

What does that mean?

Looking at Deno's features set, I had to say its vision is more ambitious than I thought. All with a single executable:

Write secure-by-default system scripts and server-side applications in TypeScript with zero configuration. TypeScript compilation is also abstracted away, for scripting experience, it is like running TypeScript natively (what ts-node does).
Have builtin fast (swc) compiler and bundler for modern ES syntax supported by modern browsers, essentially replacing webpack, parcel, rollup, etc.
Have builtin fmt and lint tools, essentially replacing prettier, eslint, etc.
Write, compile, and deploy code for both servers and modern browsers.

Common misconception

Import by URLs??

A lot of people are skeptical about this and are afraid of unexpected changes upstream. However, this concept was originally designed in ES standard and is implemented in most modern browsers, Deno doesn't reinvent the wheel here.

First of all, there shouldn't be concern about changes upstream, production software should always vendor 3rd packages, we have always been doing that by bundling applications. Lock versions can also be done easily by keeping checksums of previously downloaded packages.

This pattern also helps to have truly on-demand imports, you only load a package when your execution reach its import, while in Node.js everything is fetched no matter when and whether you'll use it.

Web protocol also enables more advanced import features (by communicating metadata in HTTP headers, etc), allows to opt in interceptors doing complex tasks, for example on-demand compilation.

Top-level await

This isn't just about allowing us to do "cool" async and await at top-level in our index.ts or app.ts. This is built in combination with native ESM to further enable async on-demand imports and secure-by-default features:

A package is only loaded (downloaded) when a user did a certain action (went to a screen, used a feature), we can display a loading while importing the package.
A permission may be asked and granted only until an import is loaded.

Summary

I love it! I can picture a bright future with Deno, where you can write, compile, bundle, and deploy performance TypeScript applications to both server and client, with just a single Deno executable and little-to-zero configuration.

Imagegen as a Service (Free), All Bloggers Should Have One

Minh-Phuc Tran — Wed, 30 Dec 2020 12:28:59 +0000

Hi folks, I've just built an Imagegen (Image Generator) as a Service. I originally built it as a feature of my website, then DigitalOcean hackathon was announced, so here it is an introduction, a submission, as well as a quick tutorial how I built it. One cool thing about this service is that it is open-sourced, easily to customize for your needs, and can be deployed completely free.

What I built

🌌 Imagegen (Image Generator) as a Service, which is a (REST) API service that can generate dynamic images for different purposes, is especially useful to generate cover images for content distribution:

Blogging & writing.
Videos' thumbnails.
Open-source repositories' social images.
etc.

Features:

Markdown support.
Dark mode enabled.
Easily display popular brands' icons by names.
Twitter emojis.
Requires zero action if you publish posts to DEV.to using DEV.to API.
Easily share consistent styles between your content images, embed your name/trademark to all your content.
Update all images with a single code change.
Cached requests to improve performance and reduce loads.
Multiple API versions.
There are 2 deployment models:
- Node.js + Docker, which can be deployed to every cloud platform that supports Docker deployment, e.g. DigitalOcean. The project is pre-configured to deploy to DigitalOcean App Platform with a single click, too.
- Next.js + Serverless functions, which can be deployed serverlessly to platforms that support Next.js API routes as Serverless functions (only Vercel currently supports).

Category Submission

Well, frankly, it's Random Roulette. Nevertheless, I believe it can be very useful for personal site/portfolio (I use it on my website) and business blogs.

App Link

img-nodejs-dwkvo.ondigitalocean.app

It's an API service, so there's no UI, the API is served at /api/v1 and /api/v2, the URL above will redirect you to the Github repository with details documentation.

Screenshots

Following are some examples of using this service's API, you can copy and paste each URL on your browser to see it yourself.

With title and brands' logos

https://img-nodejs-dwkvo.ondigitalocean.app/api/v2/%F0%9F%97%BE%20**Imagegen**%20as%20a%20Service?&icons=Node.js&icons=Docker&icons=DigitalOcean

With Markdown and brands' logos

https://img-nodejs-dwkvo.ondigitalocean.app/api/v2/%F0%9F%91%8B%F0%9F%8F%BB**Hi**%20This%20is%20a%20_generated%20image_%20with%20**Markdown**%20support?icons=dev.to

With Dark mode

https://img-nodejs-dwkvo.ondigitalocean.app/api/v2/%F0%9F%8C%99%20**Dark%20mode**%20is%20supported,%20too!?theme=dark&icons=dev.to&colors=invert

Link to Source Code

Node.js + DigitalOcean repository

Next.js + Serverless repository

Permissive License

The project is released under the MIT license and is completely free.

Background

I'd actually still build this project and release it open-source even if DigitalOcean didn't organize the hackathon because it was a part of my website.

My website is where I'll blog very often (currently one post per ~2 days) and document everything I did and learned as a software engineer. One thing I want to achieve building my website is to automatically distribute my content as much as possible, in order to maximize distribution in long term and at scale. It currently supported auto distribution to DEV.to and Hashnode (you're probably reading a distributed copy of the original post).

One part of this automation is to generate cover images for posts and let people know where to find me. ➡️ This service 🤓

I believe automating all that is the a scalable way to grow an audience in the long term, while I can focus my energy on high leverage tasks.

How I built it

This article is already fairly long (compared to typical dev posts), so I'll write a quick concept here and write complete tutorials in separate posts for both Node.js based and Next.js based versions. There are also more details in the project's repository.

Concept

The purpose of this service is to dynamically turn structured data into images. An easy way to think about it is that it is like a React component that receives props then renders visualization, which is an image in this case.

Each API is a HTTP GET at /api/{version}/{...props}:

A version represents a component that requires a certain type of props and defines how an image should look.
props are constructed using HTTP path and query params.

For example, /api/v2/Hello, World!?theme=dark will render an image in Dark mode with title Hello, World!.

API spec

See img-nodejs#API.

Implementation

Generate images

To be able to render dynamic images, I used Puppeteer to render HTML in a headless Chrome, then take screenshots and render them back to clients.

export default async (req: NextApiRequest, res: NextApiResponse) => {
  const props = parseRequest(req);
  const html = getHTML(props);
  if (isHTMLDebug) {
    res.setHeader("Content-Type", "text/html");
    res.end(html);
    return;
  }

  const { fileType } = props;
  const screenshot = await getScreenshot(html, fileType, {
    width: props.width,
    height: props.height,
  });
  renderScreenshot(res, screenshot, fileType);
};

Configure Docker

There're one tricky part with deployment of this service, especially to DigitalOcean. When developing on a laptop, it's easy because Puppeteer will simply use your installed Chrome instance with admin access and resources attached to it. When deploying to a cloud platform like DigitalOcean, you'll need to install and configure a Chrome instance yourself. So, to make it easier for others, I made a Docker image to prepare everything for you 🥳. Security was also taken care of.

FROM alpine:3.12

# Install dependencies to run Puppeteer in Alpine.
# See https://github.com/puppeteer/puppeteer/blob/main/docs/troubleshooting.md#running-on-alpine.
RUN apk add --no-cache \
        chromium \
        nss \
        freetype \
        freetype-dev \
        harfbuzz \
        ca-certificates \
        ttf-freefont \
        nodejs \
        yarn

# Setup app's dependencies and configure envs.
ENV CONTAINERIZED_BROWSER=/usr/bin/chromium-browser
ADD . /app/
WORKDIR /app/
RUN yarn

# Run everything as non-root user for security.
RUN addgroup -S appuser && adduser -S -g appuser appuser \
 && mkdir -p /home/appuser/Downloads /app/ \
 && chown -R appuser:appuser /home/appuser/ \
 && chown -R appuser:appuser /app/
USER appuser
CMD ["yarn", "start"]

Deploy to DigitalOcean

To make deployment even easier, I also created a Deploy to DO button, which enable you to deploy the service to your account with a single click.

One cool thing about deploying to DigitalOcean App Platform is that it will take care of setting up proxies, port binding, and SSL (HTTPS) certificates for you. It will also redeploy the service when you push changes to master branch.

Additional Resources/Info

Special thanks to Vercel's og-image, this project is heavily inspired by og-image.

Alright, I hope you like it and deploy an instance successfully for you, feel free to DM me on Twitter if you have any questions. Also, if you're interested in my journey building my blog, open-source, and SaaS products, please consider subscribing to my newsletter or following me on Twitter.

I Changed My Mind After 2nd Try Tailwind CSS

Minh-Phuc Tran — Mon, 28 Dec 2020 14:30:48 +0000

TL;DR: Tailwind won't help you write CSS faster or easier, it helps you think less.

Because I wanted to give my plain HTML website a little style, I gave Tailwind CSS a shot yesterday. I spent about an hour to read through its documentation and try it on its playground. The first impression was "meh". Tailwind is essentially a set of CSS classes mapping to a few CSS properties, so, in order to use Tailwind, you basically have to kinda learn CSS again, which I believe very few developers enjoy. Tailwind's creators actually knew that and put a very interesting note:

Now I know what you're thinking, "this is an atrocity, what a horrible mess!" and you're right, it's kind of ugly. In fact it's just about impossible to think this is a good idea the first time you see it — you have to actually try it.

Tailwind's documentation.

I gave it a try, but less than an hour was probably not enough for me to shift my mind from typical CSS properties to Tailwind classes. So, I didn't like it.

Use typcial CSS

Because I didn't like Tailwind, today I decided to style my website using Sass while keeping an eye on what better and worse compared to yesterday experience. And, it took me almost 3 hours to finish simple styles and the experience wasn't fun either.

So, what's wrong? 😠

I spent more than half of the time to think of which CSS properties should be grouped, which selectors I should do, what the class names should be. Although I consciously tried to avoid that, it still consumed a lot of my energy. I couldn't really explain why, the biggest reason is probably because we always have so many options with CSS and they keep growing over time.

Switch back to Tailwind again

So, I switched back to Tailwind again, not that I was convinced that Tailwind will work better, but to see again if Tailwind could solve the problems I mentioned above.

And... yeah... it actually solved the problems:

Tailwind comes with a very complete set of utilities, I've never had to think of grouping styles together. Almost every element can be styled with just Tailwind classes.
I styled directly at element-level, in HTML, so I've rarely had to think of CSS selectors.
Because I've never had to write CSS utilities myself, there wasn't any CSS "codebase" growing. Most importantly, I had nothing about CSS to keep in my mind. Now I knew it! When you write CSS, I believe "remembering its existence" consumes a lot of energy!

Conclusion

I had to say it was oddly interesting. Tailwind appears to be a "CSS framework", so my expectation was "I'll be able to write CSS faster and easier", but when looking at its documentation, it doesn't look faster and easier at all. It turned out, the problem Tailwind solved is somewhat a physiological problem when working with CSS.

So, give it try if you've ever skeptical!