DEV Community: fujiwara.cj

TIL: How to use the require syntax in .mjs files

fujiwara.cj — Tue, 12 Sep 2023 00:54:35 +0000

I'm looking for time part time work by the way! Email me at cpe.austria.johncarlo@gmail.com

In a tweet about kentcdodds, someone tweeted out that you can use the require syntax by importing the createRequire from the node:module API, the snippet and the tweet below is how the function is used:

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

But do note that it does need "module": "NodeNext" in your tsconfig.json for it to work.

Next.js 13 Data Fetching with App Router

fujiwara.cj — Tue, 05 Sep 2023 02:25:39 +0000

I'm looking for part time work! check out my portfolio on how to contact me

With the new release of Next.js 13 came with new paradigms and concepts. One prevalent concept that react and next.js introduced
are server components, which are components that are rendered on the server. This allows for faster page loads and better SEO.

This is a great concept where you can do asynchronous tasks on a react component such as data fetching. This means you won't need
useEffect to get data from an API; it is considered an anti-pattern in react when it comes to fetching data on the client with
useEffect because it can cause some expensive problems on the long run if you are not careful with it.

One of the problems that the react documentation explained are race conditions which are explained on the link.

It is much better for SEO and performance to fetch data on the server, and Next.js 13 makes it easier to do so. In this article
we will be going over how to fetch data with the new Next.js 13 App Router, and some tips and tricks.

Solution 1: Fetching data with `fetch` and React Server Components

This is as simple as it gets, create an async component, fetch data with fetch on the top level then access the data on the
template.

// app/page.jsx

export default async function Page() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts");
  const posts = await res.json();

  return (
    <div>
      <h1>Posts</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

That's it! It will fetch the data on the server and serve an html page with the data already fetched. If you want to revalidate or refetch
the data, Next.js extends the fetch where the framework allows you to configure the caching and revalidation behavior for each request
on the server.

In the previous example, we can further improve the fetch api by adding the revalidate property to the response object and doing error handling.

Let's say we want to revalidate the data every 1 hour.

// app/page.jsx

export default async function Page() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts", {
    next: { revalidate: 3600 }, // Will revalidate every 1 hour
  });
  const posts = await res.json();

  return (
    <div>
      <h1>Posts</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  );
}

After that, we can add a throw statement to throw an error if the response status is not 200.

// app/page.jsx

export default async function Page() {
  const res = await fetch("https://jsonplaceholder.typicode.com/posts", {
    next: { revalidate: 3600 }, // Will revalidate every 1 hour
  });

  if (!res.ok) {
    // This will activate the closest `error.js` Error Boundary.
    throw new Error(`Failed to fetch the data`)
  }
  const posts = await res.json();

  return (
    <div>
      <h1>Posts</h1>
      <ul>
        {posts.map((post) => (
          <li key={post.id}>{post.title}</li>
        ))}
      </ul>
    </div>
  )
}

But what if you really need to fetch data on the client? This is where the second solution comes in.

Solution 2: Fetching data in the client with third party libraries

Like I said, it is better to fetch data on the server for SEO and performance because the data that will be fetched will also be included in the HTML.

But if client side data fetching is needed, consider using a third party library first like SWR and React Query to avoid using useEffect

This is because of the edge cases that these library have are already included like deduplicating requests, caching responses,
avoiding network waterfalls, refetching, mutation, etc.

Let's take a look on what it looks like when you want to fetch
data with SWR

SWR is a data fetching library created by vercel which is a much
more simpler solution compared to react query.

Let's say we want to fetch data in a client component.

// components/profile.tsx
import { getProfileById } from '@/lib/actions'; // Example import

export function Profile({id}: {id: string}) {
     const { data, error, isLoading } = useSWR([`/api/profile/`, id], ([url, userId]) => getProfileById(url, userId))

    if (error) return <div>failed to load</div>

    if (isLoading) return <div>Loading...</div>

    return <div>hello, {data?.name}</name>
}

It looks similar, but the difference is that it is fetching directly in the browser. If you look at the difference between the network requests in your devtools you would see the request
being made.

Improving Data Fetching with Suspense

This can be further improved by using the Suspense component. Suspense in react is a component that replaces a fallback component until the children that is wrapped around it has finished loading.

We can do this by the following example:

// components/profile.tsx
'use client'

import { getProfileById } from '@/lib/actions'; // Example import


export function Profile({ id }: { id: string }) {
    const { data, error, isLoading } = useSWR([`/api/profile/`, id], ([url, userId]) => getProfileById(url, userId), { suspense: true })

    return <div>hello, {data.name}</name>
}

then on, app/page.tsx:

// app/page.tsx
'use client'

import { Suspense } from 'react'
import { Skeleton } from '@/components/ui/skeleton' // Example
import { Profile } from '@/components/profile'
import { ErrorBoundary } from 'react-error-boundary' // npm install react-error-boundary

export default function Page() {
  return (
    <ErrorBoundary fallback={<h2>Could not fetch profile</h2>}>
      <Suspense fallback={<Skeleton />}>
        <Profile />
      </Suspense>
    </ErrorBoundary>
  )
}

It looks much cleaner and doesn't actually need to use optional chaining operator and conditional checks.

IMPORTANT NOTE

React Suspense is still in experimental when it comes to data
fetching but the react team is working on how to properly
handle suspense when it comes to data fetching.

React Suspense does not detect when data is fetched inside > an Effect or event handler.

Tips and Tricks

Here are some good tips and tricks when it comes to data fetching in react.

Avoid data fetching in the client as much as possible.
Avoid using useEffect for data fetching, use an opinionated data fetching library to use the full potential of what react can offer when handling async data.
In my opinion it is considered bad practice to add 'use client' in page.tsx or layout.tsx because ideally these should be rendered on the server.
When dealing with search fields or input data, it is good to consider using debounce or throttling techniques to reduce the amount of requests and to avoid api abuse.

Conclusion

In this article, we learned how we can fetch data in the new
Next.js App Router in the server and the client. We also had
some quick discussion react suspense and how we can use it to
display loading data.

I hope you learned something on this article and apply it on
your current and new projects.

Follow me on social media!

I am active on the following social media platforms.

References

What's new in Astro 3.0

fujiwara.cj — Thu, 31 Aug 2023 03:39:21 +0000

Astro just released another major version supporting the most
anticipated feature called the View Transitions API and the
Image Optimization API previously introduced as the assets
directory back in its experimental stage.

Let's take a look at what these new API can offer.

View Transitions

View Transitions are not specifically created for Astro but
they are a web standard feature that Astro just so happens
to be the first major web framework to support it.

The concept is that it unlocks native browser transition
effects between pages.

Here's an example that is taken on how I implemented it
on my personal portfolio.

On src/components/BaseSEO.astro:

---
// src/components/BaseSEO.astro
// Added it to the common head tags so that it
// can be reused throughout the layouts
import {ViewTransitions} from 'astro:transitions';
---

<meta charset="utf-8" />
<meta name="viewport" content="width=device-width, initial-scale=1.0" />
<link rel="apple-touch-icon" sizes="180x180" href="/apple-touch-icon.png" />
<link rel="icon" type="image/png" sizes="32x32" href="/favicon-32x32.png" />
<link rel="icon" type="image/png" sizes="16x16" href="/favicon-16x16.png" />
<link rel="shortcut icon" href="/favicon.ico" type="image/x-icon" />
<ViewTransitions />

Then, I added it to the src/layouts/BaseLayout.astro

---
// src/layouts/BaseLayout.astro
// Add the BaseSEO components to the top level <head> tag
import BaseSEO from '~/components/BaseSEO.astro'
---

<html dir="ltr" lang="en">
  <head>
    <BaseHead />
    <!-- Rest of the head tags... -->
  </head>
  <body>
    <slot />
  </body>
</html>

This resulted in smooth transition between pages, and the best part
is that the HTML is still rendered on the server.

Oh, and if you are wondering if it will support other browsers, the
team also added a small ~3kb fallback script that is added to your
page automatically.

Faster Rendering Performance

This is an internal change where the team removed as much unnecessary
code as much as possible from hot paths in the build pipeline and
optimized what remained. The team said that:

Unnecessary generators and async code were two of the biggest culprits.

It resulted to 30% faster component renders. In complex benchmarks
the speed improvement can become as high as 75%!

Which is amazing because the team did it really quickly because the optimization
started in Astro 2.10 which they shipped all of it in Astro 3.0.

Image Optimization

As a user who has been using Astro since 1.0, this feature has been
the most worked on and the longest API to hit stable. But it is now
stable in 3.0.

It now uses sharp as the default optimization library because
@squoosh/lib is no longer maintained.

It adds the Image component and the getImage function which can
be imported in astro:assets

Example for the Image component:

---
import { Image } from 'astro:assets';
import myImage from '../assets/image.png';
---

<Image src={myImage} alt="A really cool looking image!" />

For the getImage function, I use it to optimize OpenGraph images:

---
import { getImage } from "astro:assets";
import myBackground from "../background.png"

const optimizedOGImage = await getImage({
  src: myBackground,
  width: 1200,
  height: 630,
  format: "jpeg",
});
const OGImageURL = new URL(optimizedOGImage.src, Astro.url.href);
---

<html>
  <head>
    <meta property="og:image" content={OGImageURL} />
  </head>
  <body>
    <!-- content... -->
  </body>
</html>

The images that were imported will automatically detect and
get optimized in the Astro build pipeline. The final rendered
image tag will be a native img tag with an inferred width
height added to prevent layout shift with automatic
Cumulative Layout Shift (CLS) protection.

It can also optimize remote images if needed.

Astro 🤝 Vercel

Astro just partnered with Vercel as their hosting partner!
Honestly, I am not surprised, Vercel has always had keen eyes
for spotting good technology (buying Svelte, Turbo, SWC, etc.).

Although they didn't buy Astro, they did help out with enhancing
the SSR experience for the framework.

If you host your Astro site on Vercel today,
you will enjoy these benefits:

Serverless Code Splitting
Vercel's Image Optimization Service
Edge Middleware

Make sure to add the @astrojs/vercel adapter to you
astro.config.ts to be able to use it.

import { defineConfig } from 'astro/config';
import vercel from '@astrojs/vercel/serverless';
// Import `@astrojs/vercel/static` if SSG is only used.
// import vercel from '@astrojs/vercel/static';

// Remember to use output: 'static'
// if you are not using SSR
export default defineConfig({
  // output: 'static',
  output: 'server',
  adapter: vercel({
    edgeMiddleware: true,
    imagesConfig: {
      sizes: [320, 640, 1280]
      // rest of image config...
    }
    imageService: true
  }),
})

HMR Enhancements for JSX

React Fast Refresh now works in Astro 3.0 because of an
internal refactoring of the JSX build support. This means
that framework integrations like React, Preact, Solid.js
users will see a significant improvement to Hot Module Reloading (HMR)
and overall dev server stability in Astro 3.0.

Optimized Build Output

Small but very good improvements when your site is built are added
in this version:

HTML Minification: Automatic HTML minification for smaller payload and faster response time.
Component IDs: astro-XXXXXX class names have been replaced with a new, dedicated data-astro-cid-hash HTML attribute. Leaving the class="" attribute having a more readable, organized HTML output.
CSS Inlining: Astro will now automatically inline small chunks of CSS into the HTML. This will improve page load performance compared to older versions where a page might load many smaller CSS files as separate requests from the browser.

What do you think? Have you upgraded to the latest version of Astro yet?
Let me know in the comment section below on your experience with Astro 3.0!

Follow me on X for more content about web development

I'm open for part time work! Send me an email at cpe.austria.johncarlo@gmail.com

References

Why you probably can't finish a frontend project

fujiwara.cj — Wed, 16 Aug 2023 02:42:11 +0000

In a paper written by Donald Knuth, there is a famous quote that says:

"Programmers waste enormous amounts of time thinking about, or > worrying about, the speed of noncritical parts of their programs, and these attempts at efficiency actually have a strong negative impact when debugging and maintenance are considered. We should forget about small efficiencies, say about 97% of the time: premature optimization is the root of all evil. Yet we should not pass up our opportunities in that critical 3%"

This is something that I have fallen victim to too many times when I am writing frontend, for some reason javascript frontend tooling has gotten too complex and people that are newer to frontend are most likely will be confused. Where do they start?

Let's say for example that you are a person who wants to learn web development, cool. You watch a 1-hour video on HTML, learn the basics of HTML, and create a text-based webpage and maybe even some forms and some built-in interactive elements (Modern HTML has some interactive elements that once needed a component library to create, the best example is the dialog component).

Then you learn all about CSS, you also watch a 1-hour video of it. After watching it, you realized that you can make your webpage prettier! You're impressed about it and decided to add colors to your text and use your favorite font that you use in your graphic design app, it's impressive and you never thought that you can make something, now you are hyped that you can make the next Facebook, the next Google, Twitter, etc.

But you realized something...

The webpage that you created is missing actual functionality, what you just created is a simple but colorful text with some interaction in it, but nothing is happening. You're not uploading anything, you're not adding text dynamically. It's missing dynamic data!

So you find out how it works, investigate it then you found out every interaction that occurs in modern web applications is all written in JavaScript!

You look up a YouTube course about JavaScript, then you're surprised that the difference in the length between a full tutorial, and a deep dive of a JavaScript tutorial contains about more than 1-hour, and if there is an exact 1-hour tutorial about JavaScript, it wouldn't suffice on how much it could cover the language because there is so much to learn first.

You think to yourself:

"This is boring, and I haven't even created something cool yet!"

Then you learn all about frontend frameworks.

So you now chose a frontend framework to learn and build your application, but you didn't learn much about HTML, CSS and JavaScript or enough to competently know what is being added by your frontend framework and what is vanilla JavaScript.

You go ahead and build, and add more packages that glue together your application, then you benchmark it using lighthouse then lo and behold.

Your lighthouse scores are all red.

Why did this happen? I thought [Frontend Framework of Choice] will make my app run fast?

The app that you were building is a weather app.

You realize you can just fetch the data from your weather api and display the data using the DOM api in plain javascript.

In conclusion, what did we learn today? Premature Optimization.

How to fix the @apply and @tailwind warning in VSCode when using TailwindCSS

fujiwara.cj — Tue, 15 Aug 2023 00:34:33 +0000

You bootstrap a new project with TailwindCSS and VSCode hits you with the line saying that the @apply and @tailwind rule doesn't exist.

There are two ways to fix this warning.

You can associate the global stylesheet that contains the @apply and @tailwind rule with tailwindcss using the files.associations property in your settings.json

{
    // ... Rest of your config
    "files.associations": {
        "*.css": "tailwindcss"
    }
    // ... Rest of your config
}

This was a solution provided by a discussion in the tailwindcss repository

Add this to your .vscode/settings.json:

{
  "css.customData": [".vscode/tailwind.json"]
}

Paste this in .vscode/tailwind.json:

{
  "version": 1.1,
  "atDirectives": [
    {
      "name": "@tailwind",
      "description": "Use the `@tailwind` directive to insert Tailwind's `base`, `components`, `utilities` and `screens` styles into your CSS.",
      "references": [
        {
          "name": "Tailwind Documentation",
          "url": "https://tailwindcss.com/docs/functions-and-directives#tailwind"
        }
      ]
    },
    {
      "name": "@apply",
      "description": "Use the `@apply` directive to inline any existing utility classes into your own custom CSS. This is useful when you find a common utility pattern in your HTML that you’d like to extract to a new component.",
      "references": [
        {
          "name": "Tailwind Documentation",
          "url": "https://tailwindcss.com/docs/functions-and-directives#apply"
        }
      ]
    },
    {
      "name": "@responsive",
      "description": "You can generate responsive variants of your own classes by wrapping their definitions in the `@responsive` directive:\n```

css\n@responsive {\n  .alert {\n    background-color: #E53E3E;\n  }\n}\n

```\n",
      "references": [
        {
          "name": "Tailwind Documentation",
          "url": "https://tailwindcss.com/docs/functions-and-directives#responsive"
        }
      ]
    },
    {
      "name": "@screen",
      "description": "The `@screen` directive allows you to create media queries that reference your breakpoints by **name** instead of duplicating their values in your own CSS:\n```

css\n@screen sm {\n  /* ... */\n}\n

```\n…gets transformed into this:\n```

css\n@media (min-width: 640px) {\n  /* ... */\n}\n

```\n",
      "references": [
        {
          "name": "Tailwind Documentation",
          "url": "https://tailwindcss.com/docs/functions-and-directives#screen"
        }
      ]
    },
    {
      "name": "@variants",
      "description": "Generate `hover`, `focus`, `active` and other **variants** of your own utilities by wrapping their definitions in the `@variants` directive:\n```

css\n@variants hover, focus {\n   .btn-brand {\n    background-color: #3182CE;\n  }\n}\n

```\n",
      "references": [
        {
          "name": "Tailwind Documentation",
          "url": "https://tailwindcss.com/docs/functions-and-directives#variants"
        }
      ]
    }
  ]
}

Thats it! Those were the two ways to fix the unknown rule when using TailwindCSS, hope it helped!

DEV Community: fujiwara.cj

TIL: How to use the require syntax in .mjs files

Next.js 13 Data Fetching with App Router

Solution 1: Fetching data with fetch and React Server Components

Solution 2: Fetching data in the client with third party libraries

Improving Data Fetching with Suspense

Tips and Tricks

Conclusion

Follow me on social media!

References

What's new in Astro 3.0

View Transitions

Faster Rendering Performance

Image Optimization

Astro 🤝 Vercel

HMR Enhancements for JSX

Optimized Build Output

References

Why you probably can't finish a frontend project

How to fix the @apply and @tailwind warning in VSCode when using TailwindCSS

Solution 1: Fetching data with `fetch` and React Server Components