DEV Community: Femi Akinyemi

What usually slows a WordPress site

Femi Akinyemi — Sun, 20 Sep 2026 11:29:18 +0000

Originally published at pafcore.site/what-usually-slows-a-wordpress-site. Prefer the canonical link for sharing and SEO.

Blank screen. Late picture. Taps that feel ignored. Then a long tip list that still does not name the file. Here is the plain version, and a free way to find what to fix first.

WordPress runs a large share of the public web. That success also means a lot of sites feel slow for the same reasons. Owners open Google PageSpeed Insights. They get a score and a scroll of advice. They still leave unsure what to change today.

This piece is not a plugin hall of fame. It is what people usually feel, what a tip list misses, and how a free PafCore report helps you name the slow file when it can.

What people feel first

Before anyone talks about scores, visitors notice the site.

The screen stays blank longer than they expect.
The big picture shows up late.
Buttons and menus ignore the first tap.

Those moments matter more than a grade on a lab report. A score is useful. It is also incomplete on its own. I wrote about that gap in Why a performance score is not enough.

What usually slows WordPress

Every site is different. Still, the same patterns show up again and again.

Large pictures. Hero images, galleries, and blog photos that were never resized for the web. The browser waits. The visitor waits.

Heavy theme and plugin scripts. Themes and plugins often load JavaScript and styles on every page, even when that page does not need them. One quiet plugin can cost more than the rest of the theme.

Fonts. Several font files, or fonts that block text until they finish loading. The page looks empty even when the words are already there.

Ads and embeds. YouTube, maps, chat widgets, and ad scripts pull work from other servers. Your page waits on them.

Weak hosting. Cheap shared hosting can make every request slower. It is real. It is not always the first place to look. Measure the page before you buy a bigger plan.

Keep it honest: none of these is always the villain. A lean plugin can be fine. A big image can be fine if it is the right size. Guessing wastes a week. Measuring names the file.

Why a tip list is hard to use

PageSpeed Insights and Lighthouse are free and useful. The tip list is long on purpose. Many tips do not move the score much. Some are already fine for your page.

People change three things. They run the check again. The number moves. They still cannot tell if the fix worked, or if the page just wobbles from one run to the next. That quiet swing is common. See Why your Lighthouse score changes when you did nothing and Why getting faster barely moves your Lighthouse score.

Left: a scroll of tips. Right: a named file and a clear next step.

What a useful report does

A useful speed report for WordPress should do four simple jobs.

Run the page more than once so you see a middle score, not one lucky screenshot.
Show how far the score moves on its own (the quiet gap).
Say what to fix first by points, not by how scary the tip sounds.
Name the slow file when the measurement can find it.

That is what PafCore is built for. Paste a public WordPress URL. You get a free report. No signup. When we can see the cost, we name the file. When we cannot, we still tell you what to try first.

How to try it on your WordPress site

Pick a real page. The home page, or a busy post or product page.
Paste the full address at pafcore.site.
Read the middle score and the quiet gap first.
Open the top finding. If a file is named, start there.

Use the live public URL. A staging site behind a login will not load the same way for a free public check. Start with what visitors already see.

For freelancers and agencies

You already sell WordPress speed work. Clients ask “did we get faster?” A long tip screenshot is hard to explain. A report that names a file is easier to send.

PafCore can carry your name on the report when white label is on. Share the link. Talk in plain words: what the visitor felt, which file hurt, what you will fix next. Keep one quiet recheck after the fix so you do not celebrate noise.

If you manage many sites and need schedules, that is Pro Watch. The free report stays free for a one off paste.

FAQ

Is PageSpeed Insights enough for a WordPress site?

It is a strong free snapshot of one URL. Use it to learn. When you need a named file, a middle score from a few runs, or a report for a client, add a clear report like PafCore. More on that split in When PageSpeed Insights is enough (and when it is not).

Is slow WordPress always a hosting problem?

No. Weak hosting can hurt. Large pictures, heavy theme and plugin scripts, fonts, and embeds often cost more than people expect. Measure the page before you buy a bigger plan.

Do plugins always make WordPress slow?

Not always. Some plugins add little. Others load big scripts on every page. The honest answer is to measure and see which file costs the most points.

Does PafCore replace WordPress speed plugins?

No. Caching and image plugins can help. PafCore measures the live page, shows how far the score moves on its own, and names the slow file when it can. Use both: measure first, then choose a fix.

Try it: Check my site — paste a public WordPress URL. Free report. No signup.

When PageSpeed Insights is enough (and when it is not)

Femi Akinyemi — Wed, 09 Sep 2026 10:31:43 +0000

Introduction

PageSpeed Insights is free. It is official. For one URL, right now, it is often the right tool.

You paste a link. You wait. You get a Lighthouse performance score, lab timings, and field Core Web Vitals when Google has enough Chrome visits. That is a strong snapshot.

A snapshot is not a watchman.

This guide is for people who ship websites and still live in PageSpeed tabs. It says when that habit is fine, when it starts to fail you, and what to add without turning every check into a science project.

By the end you will know:

when a manual PageSpeed Insights run is enough
why one lucky score is a weak proof of a fix
when scheduled checks and alerts earn their keep
a simple hybrid you can run this week

Chrome and PageSpeed Insights stay in the mix. I also run a free three run check at pafcore.site when you want the quiet swing and what to fix first without babysitting six tabs.

What PageSpeed Insights is good at

Use PageSpeed Insights when:

you are learning Largest Contentful Paint, layout shift, and the performance score
you are checking one page before or after a change
you manage one or two sites and can afford to click by hand
you need field data from the Chrome UX Report on a busy enough URL

For those jobs, do not add a tool for the sake of a tool. Open the page. Read the wait in seconds. Read the grade. Move on.

Where a single run fools you

Even on one site, a single PageSpeed Insights screenshot is a weak proof.

Lab scores move when the code does not. Machine load, third party tags, and plain luck all show up. I have seen a quiet page score 60, then 51, then 57 with nothing deployed. Nine points of weather.

So before you celebrate a fix:

Run three quiet checks with no deploy. Learn the gap between best and worst.
Ship the change. Run three more.
Compare middle scores. Only call it a clear score win when the rise beats that quiet gap.
Write the wait you meant to fix in seconds next to the grade.

That habit works in Chrome DevTools, in PageSpeed Insights, or in a free three run report. Same idea. More than one sample. Seconds and score together.

I wrote the full quiet gap steps in Why your Lighthouse score changes when you did nothing. Read that when the number moves with no deploy.

A real wait can also drop while the Lighthouse performance score barely moves. That is the scoring curve, not a broken tool. See Why getting faster barely moves your Lighthouse score.

Manual checks fail you twice: at scale, and when you trust one lucky run.

When manual checks stop being enough

You have crossed the line when one or more of these are true.

You watch more than a handful of pages

Ten sites, a few key URLs each, mobile and desktop: that is a long afternoon of paste, wait, copy, switch. By the time you finish, the first numbers are stale. Miss a week and you have no recent trail when a client asks why search or speed felt worse.

A deploy can break speed overnight

A new script, a heavier hero image, a font change. With only weekly PageSpeed Insights checks, you may learn on Friday. Or when the client calls. Scheduled lab checks (daily, or hourly on a few critical pages) shorten that blind spot. An alert should find you, not the other way around.

You need history, not only today’s screenshot

PageSpeed Insights does not keep your before and after for you. Trend lines, month to month notes, and “this page got worse after Tuesday’s release” need storage. Screenshots in a folder do not scale.

You need budgets and alerts

“LCP should stay under 2.5 seconds on mobile home” is a budget. PageSpeed Insights will not email you when you cross it. A watch with a threshold will.

You need something a client can read

Raw PageSpeed output is for builders. Clients want a short story: what got better, what still hurts, what you will do next. That story is easier when history and middle scores already exist.

A plain comparison

Need	PageSpeed Insights	Scheduled checks
One URL, right now	Yes	Yes
Mobile and desktop	Yes	Yes
Lab score and timings	Yes	Yes
Field Core Web Vitals when available	Yes	Sometimes (depends on the tool)
Many sites without tab hell	No	Yes
Daily or hourly runs	No	Yes
History and trends	No	Yes
Budgets and alerts	No	Yes
Honest before / after (more than one run)	You must do it by hand	Still your job to demand it

Same Lighthouse family of lab maths in many tools. The workflow is what changes. Scheduling does not make a single run more truthful. It makes misses rarer.

Use both. Split the jobs.

PageSpeed Insights or Chrome for learning, quick peeks, and one off audits.

Three quiet runs (by hand or a free report) whenever you claim a fix worked.

Scheduled Watch when pages matter every week: home, pricing, checkout, key landing pages. Prove you own the domain. Set a budget. Let email or a webhook tap you when the score or a wait crosses the line.

That is the hybrid. Not “throw away PageSpeed Insights.” Not “buy a dashboard and stop thinking.”

A week one checklist

List the pages that would hurt if they got slow (home, money pages, signup).
For each, run three quiet mobile checks once. Write the gap and the middle score.
Keep using PageSpeed Insights for random questions.
Put the money pages on a schedule if you already juggle more than a few sites, or if a bad deploy would cost you a client call.
After the next speed fix, compare middle scores to the quiet gap, and write Largest Contentful Paint (or your target wait) in seconds.

If you want the three run spread and “what to fix first” in one paste, use pafcore.site. If you want daily or hourly checks, history, and alerts on pages you own, that is Pro Watch at $19/mo. Credits on the site buy lab checks on a report. Watch runs are separate.

Conclusion

PageSpeed Insights is enough when you need a clear snapshot of one URL. It is not enough when you manage many pages, when you must catch a bad deploy fast, or when you confuse one lucky grade with proof.

Automate the watch. Keep the honest measure. Talk in seconds and in scores. That mix scales better than living in twenty PageSpeed tabs, and it stays truer than a dashboard that only stores one run a day.

FAQ

When is PageSpeed Insights enough?

One or two sites, learning the metrics, or a one off audit. Once you cannot keep up by hand, or once a missed week would embarrass you, add schedules.

Does a scheduled tool use different maths than PageSpeed Insights?

Many lab tools sit on the same Lighthouse style checks. Field Core Web Vitals still come from real Chrome visits over time. Do not expect one lab run to match Search Console the same afternoon.

Why three runs if I already have daily monitoring?

Daily monitoring catches surprise drops. Three runs answer “did this fix beat the quiet weather?” You still need both ideas.

Can I keep PageSpeed Insights for some clients?

Yes. Low stakes pages stay manual. High stakes pages get schedules, budgets, and a quiet gap written down once.

Why your Lighthouse score changes when you did nothing

Femi Akinyemi — Mon, 07 Sep 2026 06:10:41 +0000

Introduction

If you ship websites for a living, you have seen this.

You change one thing on a page. You open Chrome, run Lighthouse, and the performance score goes up a few points. You take a screenshot. You tell the team the fix worked.

Later the same day you run the same URL again. No new deploy. The score drops. Sometimes it drops below where you started.

That is not you failing at your job. Lab scores move even when the code does not. CPU load, network jitter, third party tags, and plain luck all show up in a single run. One number is a sample. It is not a verdict.

This article gives you a short, repeatable way to read that movement so you stop celebrating noise. By the end you will know:

why a quiet page can still swing several points
how to measure that swing in Chrome in about fifteen minutes
when a fix is real enough to put in a pull request
how to talk about wins without overselling the score

Chrome DevTools is enough for every step. I also built a free three run check at pafcore.site when you want that quiet gap without running Lighthouse by hand. The habit below is the same either way.

Why the number moves

Lighthouse loads your page in a controlled browser with throttling. That setup is useful because it is harsh and repeatable enough to compare days. It is not a perfect copy of every visitor.

Small differences stack up:

the machine was busier on one run
a third party script answered slower
an image raced and won or lost the “largest content” slot
the score itself sits on a curve, so the same time change is worth different points at different speeds

So two runs of an untouched page can land far apart. I have seen a public site score 60, then 51, then 57 with nothing deployed in between. Nine points of weather.

If you only look at the first run after a deploy, you will misread luck as skill.

What you will set up

You need:

Chrome
the live URL (or a stable preview URL)
a note app or the PR description
the same Lighthouse mode every time (mobile or desktop). Pick one and keep it

Turn extensions off, or use a clean window. Do not scroll or click while the audit runs.

Step 1. Measure a quiet page

Run Lighthouse three times on the same URL. Do not deploy between runs. Write down the three performance scores.

Find the highest and the lowest. Subtract. That gap is how far this page already moves when you change nothing.

Example:

Run	Score
1	60
2	51
3	57

Gap: 9 points.

Some pages only move two or three points. Some move more. You cannot guess your gap. You measure it once per important page (home, pricing, checkout) and you refresh it when the page shape changes a lot.

Doing those three quiet runs by hand is boring, which is why people skip it. I got tired of skipping it on client work, so I built a free report at pafcore.site that loads the page three times and shows how far the score moves on its own. Use Chrome if you want full control. Use that report if you want the quiet gap filled in for you. Either way, the idea is the same: learn the swing before you celebrate.

Step 2. Ship the change, then measure again

Deploy your fix. Run Lighthouse three more times with the same settings.

Sort each set of three scores and take the middle one. Compare middle after to middle before.

Clear win: the middle score rose by more than the quiet gap.

Not clear yet: the rise is smaller than the gap.

No win: the middle score did not rise, or it fell.

A four point bump on a page with a nine point quiet gap is not a story. It is still inside the swing you already saw.

Step 3. Write the slow thing in seconds

The score is curved. A real wait can get better while the grade barely moves, especially on a slow page.

In the same note, track the metric you meant to fix:

	Before (middle of 3)	After (middle of 3)
Performance score	56	60
Biggest picture time	4.8s	3.1s

Now you can say something honest: visitors should feel a clearer first picture, and the score is still noisy. That is better than claiming “we gained four points” when those four points never cleared the quiet gap.

If both the score and the target time sit inside the quiet swing, do not call it a performance win. Keep the change if the code is cleaner. Leave the victory lap for later.

Step 4. Do not drown in the tip list

Lighthouse will hand you a long list of opportunities. Most rows are not direct score inputs. The grade comes from a small set of lab metrics (largest content paint, blocking time, layout shift, first content paint, speed index, and similar). Tips about unused script or cache headers can still help people. They only raise the grade if they improve one of those metrics.

Before you put a tip on the sprint board, answer out loud:

“If this works, which score metric gets better?”

No answer means cleanup. Cleanup is fine. Cleanup is not a score promise.

If two tips are the same heavy image with two labels, fix the image once. Do not add imaginary points from both rows.

Step 5. Put numbers in the pull request

Paste something like this so review stays calm:

Lighthouse, same mode, three runs before and three after.
Quiet gap (max minus min, no deploy): 
Middle score before: 
Middle score after: 
Target wait before / after: 
Clear win? yes / not sure / no

One screenshot of a lucky run starts arguments. This block ends most of them.

What you get from this habit

After you use this a few times you will:

Stop treating a single Lighthouse score as proof.
Know your page’s quiet gap, so small bumps stop wasting the team’s week.
Separate score went up from the wait got better, and report both.
Pick tip list work that maps to a real metric, instead of boiling the ocean.
Leave a PR trail other people can trust.

That is the value. Not a new theory. A filter for what you already run.

Conclusion

Your Lighthouse score changes when you did nothing because a lab run is noisy. That is expected.

Measure three quiet runs. Learn the gap. Only call a fix a win when the new middle score beats that gap, and check the wait in seconds too. Treat the long tip list as optional until it names a metric you can move.

Do this on your important pages once, then again after real releases. You will ship fewer fake wins and sleep better after you post the screenshot.

I built pafcore.site for the days when I did not want to babysit six Lighthouse runs myself.

Paste a public URL, get the three run spread, see what to try first by points, and keep the habit from this article either way.

Chrome alone still works. The site is there when you want the quiet check done in one pass.

What AI Still Misses in Production Next.js Apps

Femi Akinyemi — Mon, 22 Jun 2026 07:10:47 +0000

Introduction

You ask AI to fix a fetch. It does. Types pass. The component renders. You push.

Then dev crawls to a stop. Or prod serves a blank page. Or GitHub says conflict on a file you never touched. The model did its job inside the file. It did not see the repo around it.

That gap is where most Next.js pain actually lives. Not broken JSX. Wrong root folder. Wrong env layer. Wrong deploy model. Stale git ref on the remote.

This list is the stuff that keeps surviving AI refactors, green CI, and clean local merges.

1. Next dev watching the whole monorepo

The problem

Your app sits inside a bigger repo. There is another lockfile above it. You run next dev, see a warning about multiple lockfiles, and keep going.

Compile gets slow. CPU stays high. Sometimes the machine feels stuck for no clear reason. AI will suggest faster imports or smaller components. It will not notice Next is indexing the wrong tree.

The fix

Pin Turbopack to the app folder in next.config.ts:


import path from "node:path";
import { fileURLToPath } from "node:url";

const appRoot = path.dirname(fileURLToPath(import.meta.url));

export default {
  turbopack: { root: appRoot },
};

This applies to certain monorepo/workspace setups.
It is not the solution for every slow Next.js dev environment.

If that lockfile warning shows up, treat it as a bug, not noise.

2. Putting server secrets in `NEXT_PUBLIC_*`

The problem

AI puts API URLs and tokens in NEXT_PUBLIC_* because that is what client fetch examples use. Those values ship in the browser bundle. Anyone can read them in the built JS.

Or the opposite: server route handlers need an upstream URL that only exists as a public var pointing somewhere else. Local dev works with a hack. Prod does not.

The fix

Split by runtime:

Browser code → NEXT_PUBLIC_* only
Route handlers / server code → server env vars (no NEXT_PUBLIC_ prefix)

Upstream URLs and service tokens stay on the server. Client calls your BFF or the public API surface. Never both through one env var.

3. API address missing or duplicating `/api/v1`

The problem

One backend expects calls to https://api.example.com. Another expects https://api.example.com/api/v1. Your code adds paths on top of the base address. Get it wrong by one segment and every request 404s.

This often happens when you copy .env.local from another app in the same repo. AI copies the fetch code correctly. It does not check whether the base address matches this app.

The fix

Open that app's .env.example. See exactly how it builds URLs. Match that. Do not assume all apps in one company use the same address format.

4. Adding server API files to an app that deploys as static `HTML`

The problem

Some Next apps are built with output: "export". That means the output is plain HTML, CSS, and JS files uploaded to static hosting (like S3 or Amplify static). There is no Node server running your app in production.

You can add files under app/api/ and they may work in local dev. They will not exist after a static build. The hosting serves files, not your API routes.

AI often suggests "add an API route to hide the token" without checking how the app is deployed.

The fix

If you deploy as static files, the browser calls your backend directly and your backend must allow that origin (CORS).

If you need a server middle layer to hide tokens, you cannot deploy as a pure static export. You need hosting that runs Next.js server code.

Pick one. Mixing both without knowing it is a common break.

5. Local proxy setup that does not exist in production

The problem

In local dev, teams often add a proxy in next.config so calls to /api/v1/... get forwarded to a real server. Same website address, no cross-origin browser errors. Works great on your machine.

A static production build does not include that proxy. The browser still calls /api/v1/... on your static site address. Those requests never reach your backend.

AI adds the proxy config. It rarely asks how you deploy.

The fix

Use different setup for dev and prod:

Dev: proxy in next.config if you want
Prod: full backend URL in env, CORS enabled on the backend

Run next build the same way CI does before you call it done. next dev alone is not enough.

6. Server-only code imported in a client component

The problem

Next has a hard line between server code and client code. Files marked "use client" run in the browser. Things like reading request headers or secret env vars only work on the server.

One shared lib/api.ts file often gets imported everywhere. AI merges duplicate files and accidentally puts server code inside a client component. Build fails or you get strange runtime errors.

The fix

Keep two files:

One for the browser (simple fetch, public env only)
One for the server (secret env, used only in app/api routes or server components)

If it reads cookies, headers, or private env, it never goes in a "use client" file.

7. Login token is valid but for the wrong app

The problem

Some apps check two things: is the user logged in, and does their role match this specific product. You paste a login token into .env.local. It is not expired. The app still sends you back to the login page.

The token belongs to a different dashboard or role. AI tries to fix the redirect logic. The check is working. Your token is for the wrong app.

The fix

Make sure three things match: the role setting in env, the role inside the token, and what the app's auth guard expects. When testing locally, use a token created for this app specifically.

8. Fake login still turned on while shipping real auth

The problem

Many teams add a dev-only flag that skips real login so they can build UI faster. Useful. Easy to forget about.

You say auth is done. But callback, token refresh, sign out, and role redirect were never tested with real login. AI sees a user object in state and assumes auth works.

The fix

Use the skip-login flag only for UI work. Before merging: turn it off, log in for real, open a protected page, sign out.

9. Old dev server still running on the port

The problem

You run pnpm dev again without closing the last one. Port 3000 is busy. Next starts on 3001. You keep refreshing 3000 and see the wrong app or nothing useful.

AI will debug your React code. It will not check which process owns the port.

The fix


lsof -i :3000

Kill the old process. Start fresh. Confirm which port the terminal says before debugging anything else.

10. No conflict on your machine, conflict on GitHub

The problem

You updated your branch with the latest main locally. Merge looks clean. The pull request on GitHub still shows conflicts.

Your local branch and the copy on GitHub are not the same history anymore. GitHub compares the remote branch to main, not your rebased local copy.

AI says "pull main again." You already did. On your machine only.

The fix

After rebasing locally, update GitHub:

git push --force-with-lease origin your-branch

Only use this when you intentionally rebased or rewrote branch history.

Check they match:

git log origin/your-branch..HEAD

No output means local and remote are in sync.

11. Expired login token in your env file

The problem

For local development, some apps read a login token from .env.local and attach it to server-side API calls. Tokens expire. Handlers return 401 Unauthorized. The UI shows empty data or error states.

Looks like the API is broken. AI rewrites error handling. The token is just old.

The fix

Decode the token and check the expiry time. Get a fresh one from a real login. Treat dev tokens like passwords with an expiration date.

12. Public env vars set after the build, not during it

The problem

NEXT_PUBLIC_ values are written into the JavaScript at build time.

If you set them in your hosting dashboard after the build already ran, the live site still has the old values baked in.

Works on your machine with .env.local. Wrong API address or app setting in production.

The fix

Make sure public env vars exist before next build runs in CI. Some teams write a .env.production file in the build step. Check build logs, not just runtime settings in the host UI.

13. Copied env from the wrong app in the same repo

The problem

Two Next apps in one repo look similar. Same folders, same tools. Different env needs. Copy .env.local from one app into another.

The shell loads. The first API call or redirect fails. AI assumes env is fine because the file is there.

The fix

Every app has its own .env.example. Start from that file every time.

Env is per app, not per repo.

14. Login page and dashboard on the same local port

The problem

Login usually lives on one app. The dashboard on another. In local dev that means different ports (for example 3001 for login, 3000 for dashboard).

If both URLs in env point to the same port, redirects get confused. Loops, wrong landing page, sign out going nowhere useful.

The fix

Write down the flow: login address → callback → dashboard address.

Set env to match separate apps, even on localhost.

15. Green code review, nobody ran a production build

The problem

AI fixed the component in the prompt. Types pass. Review looks good. Nobody ran a full production build with real login and a real API call.

The fix

Before merge:

next dev starts without warnings
next build passes with the same config CI uses
One real login (skip-login flag off)
One API call that returns real data

Conclusion

AI is strong inside a single file. It is weak on repo layout, env setup, static vs server deploy, and whether your GitHub branch matches your local branch.

Those live outside the chat window. Check them yourself and a lot of "random" Next.js bugs stop being random.

Need Help With Your Next.js or AWS Project?

Over the last 5+ years, I've helped build and maintain production systems used by businesses across different industries. If you're looking for help with:

Next.js applications
React architecture
AWS deployments
AI integrations
Performance optimization

feel free to reach out.

LinkedIn: Femi Akinyemi
DEV: dev.to/femi_akinyemi
Portfolio: Femi Akinyemi

Wedding Memories: The Collaborative Wedding Album!

Femi Akinyemi — Fri, 11 Oct 2024 15:28:15 +0000

Wedding Memories

This is a submission for the The Pinata Challenge

What I Built

Wedding Memories is an app designed to capture, share, and cherish every unforgettable moment from your special day! It allows wedding guests to easily upload photos, creating a collaborative album that captures the essence of the celebration. By using Pinata's Files API, the app provides a seamless experience for secure and efficient media uploads and storage.

Demo

Check out the live version of the app here: Wedding Memories

Screenshots:

Upload Section - A user-friendly interface for selecting and uploading media files:

Gallery View - Displays all uploaded memories in a responsive layout:

Mobile-Optimized Design - Ensures smooth user experience across all devices:

Download Options - Guests can download their favourite moments to keep memories forever.

My Code

You can explore the full code for this project on GitHub:

More Details

Wedding Memories leverages Pinata’s Files API to build secure and efficient file uploads. Below is a brief breakdown of the integration:

File Uploads: Guests can easily upload images directly from their devices. This is accomplished using the pinata.upload.file, which uses JWT-based authentication to ensure secure file handling. Once uploaded, the files are securely stored, and their unique identifiers (CIDs) are generated for retrieval.
Local Previews Before Upload: To enhance the guest experience, wedding memories generate local previews of images before uploading them. This feature allows guests to confirm their selections and make adjustments, ensuring only their desired image is submitted.

After successful uploads, the files are rendered using the file API. This guarantees rapid access to the content, providing guests with a seamless experience when viewing shared memories.

Download Feature: Guests can now download their favourite photos directly from the app, making it easy to save cherished memories to their devices. The app includes an API route that facilitates the secure downloading of files.

API Integration Breakdown:

The building includes several key API routes, each designed to handle specific functionalities:

File Upload Endpoint

This accepts file uploads and stores them using Pinata’s upload function. It then generates a signed URL for easy access to the uploaded file.

import { NextResponse, NextRequest } from "next/server";
import { pinata } from "../../../../utils/config";


export async function POST(request: NextRequest) {
  try {
    const data = await request.formData();
    const file: File | null = data.get("file") as unknown as File;
    const uploadData = await pinata.upload.file(file)
    const url = await pinata.gateways.createSignedURL({
        cid: uploadData.cid,
        expires: 3600,
    });
    return NextResponse.json(url, { status: 200 });
  } catch (e) {
    console.log(e);
    return NextResponse.json(
      { error: "Internal Server Error" },
      { status: 500 }
    );
  }
}

API Key Generation (/api/key/route.ts):

Creates a temporary API key with permissions to pin files to IPFS.


/* eslint-disable @typescript-eslint/no-unused-vars */
import { NextResponse } from "next/server";
import { pinata } from "../../../../utils/config";

export const dynamic = "force-dynamic";

export async function GET() {
    try {
        const uuid = crypto.randomUUID();
        const keyData = await pinata.keys.create({
            keyName: uuid.toString(),
            permissions: {
                endpoints: {
                    pinning: {
                        pinFileToIPFS: true,
                    },
                },
            },
            maxUses: 1,
        })
        return NextResponse.json(keyData, { status: 200 });
    } catch (error) {
        console.log(error);
        return NextResponse.json({ text: "Error creating API Key:" }, { status: 500 });
    }
}

List Files (/api/listfiles/route.ts):

Retrieves a list of uploaded files from Pinata, allowing users to view all shared content in the gallery

import { NextResponse } from "next/server";
import { env } from "process";


export const dynamic = "force-dynamic";

export async function GET() {
  try {
    const options: RequestInit = {
      method: 'GET',
      headers: {
          Authorization: `Bearer ${process.env.NEXT_PUBLIC_PINATA_JWT}`,
      },
      cache: 'no-cache'
    };

    const response = await fetch('https://api.pinata.cloud/v3/files', options);

    if (!response.ok) {
      return NextResponse.json({ text: "Error listing files" }, { status: response.status });
    }

    const { data } = await response.json();
    return NextResponse.json(data, { status: 200 });
  } catch (error) {
    console.log(error, "Error listing files");
    return NextResponse.json({ text: "Error listing files" }, { status: 500 });
  }
}

Image Proxy (/api/proxy/route.ts):

Acts as a proxy for fetching images from external sources, ensuring users can easily access and download their images.

import { NextResponse } from 'next/server';


export async function GET(request: Request) {
  const { searchParams } = new URL(request.url);
  const imageUrl = searchParams.get('url'); // Get the image URL from the query string

  if (!imageUrl) {
    return NextResponse.json({ error: 'Image URL is required' }, { status: 400 });
  }

  try {
    const response = await fetch(imageUrl);

    if (!response.ok) {
      return NextResponse.json({ error: 'Failed to fetch image' }, { status: response.status });
    }

    const contentType = response.headers.get('content-type') || 'application/octet-stream';
    const imageBuffer = await response.arrayBuffer();

    return new NextResponse(imageBuffer, {
      headers: {
        'Content-Type': contentType,
        'Content-Disposition': 'attachment; filename="downloaded_image"',
      },
    });
  } catch (error) {
    console.error('Error fetching image:', error);
    return NextResponse.json({ error: 'Error fetching image' }, { status: 500 });
  }
}

Signed URL Creation (/api/sign/route.ts):

Generates signed URLs for uploaded files.


import { type NextRequest, NextResponse } from "next/server";
import { pinata } from "../../../../utils/config";

export const dynamic = "force-dynamic";

export async function POST(req: NextRequest) {
  try {
    const data = await req.json();
    const mimeType = data.mime_type;

    let url;

    if (mimeType === 'video/mp4') {
      url = await pinata.gateways.createSignedURL({
        cid: data.cid,
        expires: 7776000,
      })
    } else {
      url = await pinata.gateways.createSignedURL({
        cid: data.cid,
        expires: 7776000,
      }).optimizeImage({
        width: 300,
        height: 300,
        format: "webp",
        fit: "contain",
        quality: 90,
        dpr: 2,
        sharpen: 1,

      });
    }

    return NextResponse.json(url, { status: 200 });
  } catch (error) {
    console.log(error);
    return NextResponse.json({ text: "Error creating signed URL:" }, { status: 500 });
  }
}

The app is built with:

Pinata: File API
Frontend: React, Next.js, Framer Motion
Styling: Tailwind CSS for responsive, beautiful layouts.
Hosting: Amplify for deployment.

Conclusion

Weddings are joyous occasions filled with love, laughter, and countless memorable moments. Capturing these precious memories is essential, and with the Wedding Memories app, it's now easier than ever!

This application allows every guest to take lovely pictures on the event day and share them seamlessly, ensuring that no moment is missed and everyone has access to the collective memories of the celebration.

The app harnesses the power of Pinata's Files API to provide a secure and efficient way for guests to upload and share their photos and videos, creating a collaborative album that beautifully encapsulates the essence of the day.

For more details on how the app integrates with Pinata and to explore its capabilities, please refer to the Pinata documentation.

Thank you.

How to Upload Files to Amazon S3 with React and AWS SDK

Femi Akinyemi — Mon, 04 Mar 2024 15:54:14 +0000

INTRODUCTION

Have you ever needed to upload files from your React application to the cloud?

Amazon S3 (Simple Storage Service) provides a robust and scalable solution for storing and managing various file types.

Using the AWS SDK, this article shows how to build a React application that allows users to upload files to S3.

In the article, you'll learn how to handle file selection, validate file types, and handle the upload process with error handling.

By the end, you'll have a basic understanding of integrating file uploads to S3 with React and AWS.

Prerequisite:

Basic understanding of React and JavaScript.
An AWS account and access credentials to configure the S3 connection.

Getting Started

Creating S3 Bucket

The first thing to do is start by creating an S3 bucket. Log in to the AWS S3 console and follow the instructions to create a new bucket, as shown in the image below.

Making the files publicly accessible

Next is to edit the bucket policy to make the file publicly accessible.

Here's how:

Open the bucket: Go to the AWS S3 console and navigate to your specific bucket.
Access permissions: Click on the 'Permissions' tab.
Edit policy: Locate the 'Bucket policy' section and click the 'Edit Policy' button.
Paste JSON code: Copy and paste the following JSON code into the policy editor.

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "PublicListGet",
            "Effect": "Allow",
            "Principal": "*",
            "Action": [
                "s3:List*",
                "s3:Get*"
            ],
            "Resource": [
                "arn:aws:s3:::YOUR_BUCKET_NAME",
                "arn:aws:s3:::YOUR_BUCKET_NAME/*"
            ]
        }
    ]
}

Save changes: Review the policy and click 'Save'.

The policy above makes all objects in the S3 bucket named YOUR_BUCKET_NAME publicly accessible. Anyone online can list and download all files in the bucket and its subfolders.

The policy should be used cautiously as it can be a security risk.

Editing CORS Policy

Now, you must enable Cross-origin resource sharing (CORS).
The CORS configuration, written in JSON, allows clients to access resources in a different domain from applications within the same domain.

Scroll down a bit more, and you will see a section where you can edit CORS settings.

Paste the below JSON into it to enable the upload of files from the front end, or you will receive a CORS error while uploading files.


[
    {
        "AllowedHeaders": [
            "*"
        ],
        "AllowedMethods": [
            "PUT",
            "POST",
            "DELETE",
            "GET"
        ],
        "AllowedOrigins": [
            "*"
        ],
        "ExposeHeaders": []
    }
]

Uploading files to your AWS S3 bucket is now possible.

Next, we'll talk about the front end.

Run the command below to Scaffold your react application.


npx create-react-app filestorage
cd filestorage
npm start

Installing AWS SDK for JavaScript

You must install the AWS SDK for JavaScript, allowing your React JS application to communicate with S3.

Run the command below to install AWS SDK

npm install aws-sdk

Next is to replace the default code in the App.js file with the code below

import React, { useState } from 'react';
// Uncomment one of the following import options:
import AWS from 'aws-sdk'; // Import entire SDK (optional)
// import AWS from 'aws-sdk/global'; // Import global AWS namespace (recommended)
import S3 from 'aws-sdk/clients/s3'; // Import only the S3 client

import './App.css';

function App() {
  const [file, setFile] = useState(null);
  const [uploading, setUploading] = useState(false)

  const allowedTypes = [
    'image/jpeg',
    'image/png',
    'application/pdf',
    'video/mp4',
    'video/quicktime',
    'audio/mpeg',
    'audio/wav',
    // Add more supported types as needed
  ];

  const handleFileChange = (event) => {
    const selectedFile = event.target.files[0];
    if (allowedTypes.includes(selectedFile.type)) {
      setFile(selectedFile);
    } else {
      alert('Invalid file type. Only images and PDFs are allowed.');
    }
  };

  const uploadFile = async () => {
    setUploading(true)
    const S3_BUCKET = "your_bucket_name"; // Replace with your bucket name
    const REGION = "your_region"; // Replace with your region

    AWS.config.update({
      accessKeyId: "your_accesskeyID",
      secretAccessKey: "your_secretAccessKey",
    });

    const s3 = new S3({
      params: { Bucket: S3_BUCKET },
      region: REGION,
    });

    const params = {
      Bucket: S3_BUCKET,
      Key: file.name,
      Body: file,
    };

    try {
      const upload = await s3.putObject(params).promise();
      console.log(upload);
      setUploading(false)
      alert("File uploaded successfully.");

    } catch (error) {
      console.error(error);
      setUploading(false)
      alert("Error uploading file: " + error.message); // Inform user about the error
    }
  };

  return (
    <>
      <div className="">
        <input type="file" required onChange={handleFileChange} />
        <button onClick={uploadFile}>{uploading ? 'Uploading...' : 'Upload File'}</button>
      </div>
    </>
  );
}

export default App;

The React code above creates a simple file uploader app. Users can select a file that is uploaded to an Amazon S3 bucket.

Here's a brief breakdown:

State Management: It uses React's useState hook to manage the selected file and uploading state.
Allowed File Types: Defines an array of allowed file types.
File Change Handler: When a file is selected, it checks if the file type is allowed and updates the state with the selected file.
Upload Function: Constructs S3 parameters and uploads the file to the specified S3 bucket. It handles success and error cases, providing feedback to the user.
User Interface: Provides a file input field and a button for uploading—the button text changes based on the uploading state.
AWS SDK: Imports necessary modules from the AWS SDK to interact with S3 and configures it with credentials and region.

The code offers a basic file uploading functionality to S3 from a React app.

Conclusion

You've successfully uploaded a file to your S3 bucket with these steps! You can consult the documentation for tailored options that suit your specific requirements.

Build a simple project management app with Neon, PostgREST, and DigitalOcean

Femi Akinyemi — Tue, 27 Feb 2024 16:29:41 +0000

Introduction

Neon s erverless Postgres stands out in the world of databases. It provides a fully managed service for PostgreSQL with unique features like autoscaling, branching, and a great serverless experience. Its architecture makes Neon serverless Postgres different from how users set up Postgres databases by separating storage and compute.

In this guide, we'll leverage the strengths of Neon serverless Postgres to establish a PostgREST API on DigitalOcean. With PostgREST, a PostgreSQL database is turned into a RESTful API.

As a practical illustration, we’ll walk through creating a mini project management application with complete create, read, update, and delete (CRUD) functionality. This application will allow users to create new projects, view existing details, update information, and delete projects as needed.

Ultimately, you’ll have a fully functional PostgREST API powered by Neon serverless Postgres, seamlessly incorporated into your DigitalOcean environment.

Prerequisites

To fully grasp the concepts presented in this tutorial, you’ll need the following:

A Neon account
A DigitalOcean account
A basic understanding of PostgreSQL and REST APIs
Node.js installed on your local machine

Create a Neon project

To set up a Neon project, let’s begin by registering for an account, assuming you don't have one already. With that done, we’ll create a new project by selecting a Project Name. We will use (Project Management), Database name (managementdata), and Postgres version. For this demonstration, we’ll opt for 16 as the Postgres version and choose the region closest to where we would like to deploy our app.

Upon successfully creating the project, we will get a connection string for connecting to our database.

Project directory

To organize our project files and resources, let's create a new project directory using the following terminal command:

    mkdir neonprojectappfolder

Loading demo data into the database

With the project directory in place, follow these steps to load the demo data into the database.

To connect to our database, we will use the connection string provided by Neon and run it in the terminal:

    psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'

The command connects to the database using the provided connection string.

Now that we’re connected to the database, let’s upload our demo data by running the command below in the terminal:

    psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require < projects.sql

The demo data (projects.sql) can be downloaded here.

The demo data must be downloaded in our project directory before running the command above.

Upon successfully loading demo data into the database, we’ll see a response like the image below:

The output CREATE SEQUENCE, CREATE TABLE, and INSERT 0 5 indicate that the sequence, the table, and five rows were inserted into the table, respectively.

Next, we verify the demo data is present using the following steps:

First, connect to the database again by running the command below:

    psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'

(Just a note that we’re connecting to the database again because we exited the database when we loaded the demo data into the database.)

Now, let us run the command below in our terminal:

    select * FROM projects LIMIT 1

The SQL command SELECT * FROM projects LIMIT 1 retrieves data from the "projects" table.

We should get a response like the one in the image below.

As a result, our demo data has been successfully uploaded to our database.

PostgREST setup

Now that we have set up our database, the next step involves setting up PostgREST. First, we install PostgREST by following this installation guide.

After a successful installation, we can confirm everything works perfectly by typing postgrest -e in the terminal. We should see a response similar to the image below, indicating a successful operation.

Granting CRUD access to a database user

Now, we can connect to the database using the connection string above.

(We’re connecting again because checking the PostgREST installation disconnected us from the database.)

After a successful connection, execute the command below:

    GRANT SELECT, INSERT, UPDATE, DELETE ON TABLE public.projects TO femakin

The command grants femakin user permissions for SELECT, INSERT, UPDATE, and DELETE operations (CRUD) on the projects table in the public schema.

PostgREST connection setup

The next step is to establish a PostgREST connection. To do this, exit the database terminal by typing \q and then enter the following command: vi projects.config.

The command vi projects.config opens the projects.config file using the vi text editor.

We then edit the projects.config file by pasting the command below.

    db-uri = psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'
    db-schema = "public"
    db-anon-role = "femakin"

This configuration specifies a PostgreSQL database connection string URI with credentials and connection details. It also defines the default database schema as public and the anonymous role as femakin for authentication purposes.

To ensure the proper setup of the PostgREST connection, we can run postgrest projects.config in the terminal. This command should yield a response similar to the image below.

Testing the API routes

Now, let us employ a tool such as Postman to conduct tests. In the browser, navigate to the URL localhost:3000/projects.

The connection is working if we find something like this in the browser.

Otherwise, we must review all the steps and ensure everything is present.

Bootstrapping VueJS application

The quickest approach to get started with our VueJS application is to clone this Git H ub repository :

    git clone https://github.com/femakin/Neo-Demo-PostgREST-DigitalOcean-App

Follow the instructions in the README file: Run npm install to install dependencies and npm run dev to start the application.

The application will appear like this in the browser:

The code in the src/App.vue is a project management app using VueJS. It handles project data, loading status, and user interactions. It fetches project data and lets users view, add, update, and delete projects. The focus is on simplicity for managing projects in a web app.

Deploying to Digital Ocean

Thus far, we’ve created our database, set up PostgREST, and got our mini-application running in VueJS. Now, we need to deploy everything to DigitalOcean. To do this, log into the DigitalOcean dashboard and create a Droplet by following this guide.

DigitalOcean Droplets are Linux-based virtual machines (VMs) that operate on virtualized hardware.

Now, let’s access our droplet. First, copy the created droplet's IP address, as shown in the image below, and then use it to SSH into the droplet.

Note: Keep this IP address handy; we’ll need it for future steps.

Next, log into the droplet by using the copied droplet's IP and running the command below in the terminal:

    ssh root@copied_droplet_IP

This will prompt us to enter a passphrase for the key.

Next, we will update the apt cache to get the latest packages by running the below command:

    sudo apt update

A runtime library, an essential component of the PostgreSQL database system, must be installed. This library is a connection and communication interface for PostgreSQL database servers.

Let’s run the following command in the terminal to install the PostgreSQL runtime library, libpq5:

    sudo apt install libpq5

This command will ensure that the necessary runtime components for PostgreSQL are installed on the system.

Now, we’ll install PostgREST from the release page available here. Choose a version compatible with your operating system; for example, we will install postgrest-v11.2.0-linux-static-x64.tar.xz.

    wget 'https://github.com/PostgREST/postgrest/releases/download/v11.2.0/postgrest-v11.2.0-linux-static-x64.tar.xz'

Next is to extract the compressed file to obtain the executable. Run the command below in the terminal:

    root@project-management:~# tar vxf postgrest-v11.2.1-linux-static-x64.tar.xz
    postgrest

To ensure everything works, let's run the following command:

    ./postgrest -e

We should expect a response similar to the image below.

Configuring PostgREST on Droplet

Let us configure PostgREST by following the steps below.

Move PostgREST to usr/bin by executing the following command:

    sudo mv postgrest /usr/bin

Navigate to /usr/bin using the command

    cd /usr/bin

Confirm that everything is in order by running

    ./postgrest -e

Now, create a directory using the command

    mkdir projectsmanagement

Let's return to our local machine within the project directory and copy the config file using:

    cat projects.config

We previously created the config file in the section above. We’ll see a configuration similar to the one below:

    db-uri = psql 'postgresql://xxx:xxxx@ep-xxx-xxx-01196450.us-east-2.aws.neon.tech/xxx?sslmode=require'
    db-schema = "public"
    db-anon-role = "femakin"

Then, return to our droplet and create a new config using:

    vi projects.config

Paste the copied projects.config, and save the file.

Now, we can connect to our database using postgrest postgrest.config.

You should now see a response stating that the connection is successful, as shown in the image below:

Now, we can test the API using the command curl localhost:3000/projects, and observe a response from our database, like the illustration below.

Creating systemd

Now, let's create a system service for a PostgREST. We need to go back to PostgREST documentation here.

We can now go back to our droplet and create the system file using the command below:

vi /etc/systemd/system/postgrest.service and paste the code below:

    [Unit]
    Description=REST API for any PostgreSQL database
    After=postgresql.service

    [Service]
    ExecStart=/usr/bin/postgrest /usr/bin/postgrest.config
    ExecReload=/bin/kill -SIGUSR1 $MAINPID
    User=nobody
    Group=nogroup

    [Install]
    WantedBy=multi-user.target

Here, we’ll reload, start, and check the status of the systemd using the command below.

     sudo systemctl daemon-reload
     sudo systemctl start postgrest
     sudo systemctl status postgrest

Testing the API using curl localhost:3000/projects gives us our expected response, as shown below:

Uploading the Vue app into Droplet

It's time to upload our project management application into the droplet. Return to your local machine to upload the application into the droplet and run npm run build inside the project directory.

Now that we have our production Vue App, we can copy it into the droplet using the command below:

    scp -r dist root@copied_droplet_IP:/usr/bin/vueapp

Next is to install a web server to serve the files.

    sudo apt install nginx

Next is to create a virtual host using:

    sudo vi /etc/nginx/sites-available/copied_droplet_IP

Paste the code below and save.

We can now create a link using.

    sudo ln -s /etc/nginx/sites-available/copied_droplet_IP  /etc/nginx/sites-enabled/

Then reload nginx using

    sudo systemctl reload nginx

Testing deployment

We can now go to the browser and paste the copied_droplet_IP. We should see our project management app on the page.

However, we will see an error if we look at the console. This error is there because we have not set up the API server.

To take care of this, we must use nginx to proxy /API to the PostgREST instance running on our droplet, as described in this PostgREST documentation.

We can now edit our nginx configuration using

    sudo vi /etc/nginx/sites-available/Copied_IP

Then, update the configuration with the command below.

     location /api/ {
          default_type  application/json;
          proxy_hide_header Content-Location;
          add_header Content-Location  /api/$upstream_http_content_location;
          proxy_set_header  Connection "";
          proxy_http_version 1.1;
          proxy_pass http://localhost:3000/;
        }

Then reload nginx using:

    sudo systemctl reload nginx

We can now return to the browser and paste the copied Droplet IP. Now, we can see our application without any errors.

Congratulations! You successfully created a mini-project management application by seamlessly integrating PostgREST and DigitalOcean, backed by Neon serverless Postgres.

Here are a few recommendations to take it further.

Add a domain to the Droplet
Configure HTTPS
Add more features to the applications

The possibilities are endless when it comes to Neon serverless Postgres.

Conclusion

We covered a lot in this tutorial. Let’s recap! You accomplished the following:

Leveraged Neon serverless Postgres to establish a PostgREST API on DigitalOcean.
Transformed a PostgreSQL database into a functional RESTful API using PostgREST.
Created a mini-project management application as a practical illustration using VueJS.
Demonstrated seamless integration between Neon serverless Postgres, PostgREST, and DigitalOcean.

References

Understanding AWS Amplify Monitoring Metrics Definitions

Femi Akinyemi — Thu, 08 Feb 2024 12:52:21 +0000

One of the App settings provided by AWS Amplify is Monitoring, which allows us to monitor metrics like site traffic, configure alarms, and access logs for our Amplify applications in nearly real time.

In this article, we will look at the definitions of CloudWatch metrics in the AWS/AmplifyHosting namespace for monitoring our app traffic, errors, data transfer, and latency.

When we decide to monitor our app hosted on AWS Amplify, we navigate to the app settings sidebar and click on the Monitoring tab, which takes us to the monitoring page, as shown in the image below.

So, what do all these terms mean?

According to the Monitoring and CloudWatch section of the AWS Amplify Hosting, Here is what they mean.

Requests: This is the total number of viewer requests Amplify Hosting receives for all HTTP methods and HTTP and HTTPS requests, which means it is how often people visit our website hosted on Amplify, including all types of requests like clicking links or loading pages with HTTP or HTTPS.

Bytes downloaded: The total amount of data transferred out of our app (downloaded) in bytes by viewers for GET, HEAD, and OPTIONS requests, which means it shows the total data sent from our app to users when they download something, like images or files, through actions like clicking links or accessing pages.

BytesUploaded: This is the total amount of data transferred into our app (uploaded) in bytes using POST and PUT requests. Therefore, it represents the complete data our app receives when users upload files or submit forms, typically through actions like posting comments or uploading images.

4XXErrors: The number of requests that returned an error in the HTTP status code 400-499 range. This metric counts the requests that encountered errors on the user's end, like entering incorrect information or trying to access restricted content, resulting in an error response from the server.

5XXErrors: The number of requests that returned an error in the HTTP status code 500-599 range. This metric counts the requests that encountered errors on the user's end, like entering incorrect information or trying to access restricted content, resulting in an error response from the server.

Latency: This metric measures how quickly Amplify Hosting responds to a request, from when it receives it until it sends the first byte of data back to the network. It excludes the time the response travels to the viewer's device.
Key statistics include the average, maximum, minimum, and various percentiles (p10, p50, p90, p95, p100), providing insights into response times across different scenarios.

For more details about the metrics, we can access the CloudWatch metrics in the AWS Management Console here.

How to add Astro social share to your Astro application

Femi Akinyemi — Mon, 08 Jan 2024 05:44:36 +0000

Introduction

Astr o is a modern web framework that combines the best features of static site generators (SSGs) and server-side rendering (SSR) frameworks. It is designed to be fast, flexible, and easy to use, making it an excellent choice for building various websites, including blogs, portfolios, e-commerce sites, and more.

Astro offers several benefits, including:

Speed: Astro websites are typically very fast, thanks to server-side rendering and component islands.
SEO: Astro websites are also well-suited for SEO, as they are static and can be pre-rendered.
Flexibility: Astro is a very flexible framework, and many websites can be built.
User-friendliness: Astro is beginner-friendly and offers a gentle learning curve, making it accessible even for those new to web development.

One of the benefits of using Astro is that it makes it easy to add social sharing buttons to your website. Social sharing is essential because social sharing is a great way to increase traffic to your website and promote your content.

Social sharing is essential for web applications because it can help to:

Boost website traffic
Content promotion
Establish brand presence
Lead generation and sales

This article explains how to add social sharing buttons to your Astro application.

In this article, you will build an application that displays random jokes using the random dad joke API with a social share button using Astro social share.

The source code for the application is readily available here on GitHub.

By the end of this article, you will have a better understanding of:

What is Astro social share?
How to install Astro social share
How to use Astro social share # Understanding Astro social share

Astro social share is your Astro site's social media share button. It's also one of the recently added Astro integrations.

Astro social share comes with some good features, which are:

No dependencies or external scrips
Share buttons for:
- Facebook
- Hacker News
- LinkedIn
- Reddit
- Twitter
Icons included from https://simpleicons.org/ # Prerequisites

To fully grasp the concepts presented in this article, the following are required:

Basic understanding of JavaScript
Node.js installed, version v18.14.1 or later.
Code Editor - Preferably VS Code or another code editor. # Bootstrapping Astro application

To bootstrap your Astro application, you will use the create astro setup wizard following the steps below:

Install Astro by running the following command in your terminal:

npm create astro@latest

Confirm your choice by typing 'y' to install the create-astro package.
When prompted to specify the location for your new project, enter the folder name where you'd like to create a new project directory. For example, you can type. /Astro-Social-Share.
You'll be presented with a list of starter templates. Use the arrow keys (up and down) to navigate to the "Empty" template, and then press the Return or Enter key to select it.
When asked if you want to install project dependencies, type y.
If you are asked whether you plan on using TypeScript, type n.
When prompted about initializing a new git repository, type y.

Now, you can navigate to your Astro-Social-Share directory to begin and preview your application by running the command below in your terminal:

cd cd Astro-Social-Share

npm run dev

Click the localhost link within your terminal window to view a real-time preview of your brand-new Astro website!

This is how the browser preview of the Astro 'Empty Project' starter website should appear:

Setting up API page

Now, you need to set up the Home Page. The home page will be the entry point for your application's home page. In the src/pages/index.astro, paste the code below:


    ---
    import {GET} from "../pages/api/fetchdata";

    import { TwitterShareButton, SocialShare } from "astro-social-share";
    const TwitterBUTTON = [TwitterShareButton];

    let response = await GET();
    const data = await response.json();
    ---

    <html lang="en">
      <body>
        <div class="h-screen flex flex-col items-center">
          <h1 class="text-3xl font-bold mt-12 mb-12">Share Your Daily Joke on X</h1>

          <p
            id="joke-btn"
            class="bg-blue-500 hover-bg-blue-700 text-white font-bold py-2 px-4 rounded">
            Click on the X icon below to share your daily joke
          </p>

          <div class="mt-12" id="joke-container">{data.joke}</div>

          <SocialShare
            buttons={TwitterBUTTON}
            description={data?.joke}
            via="akinyemi_t"
            title={data.joke}
          />
        </div>
      </body>
    </html>

Here is the explanation of the code provided above:

The first line imports the GET function from a file at ../pages/api/fetchdata. It suggests that you are making a GET request to fetch some data.
Next, you import components related to social sharing using Astro. Specifically, you import the TwitterShareButton and SocialShare components from the astro-social-share library.
You define TwitterBUTTON as an array containing the TwitterShareButton. This variable plays a role later when configuring social sharing.
The code then awaits the result of the GET request, assigns it to the response variable, and parses the JSON content from the response into the data variable.
The HTML section starts with the opening <html> tag and defines the web page's structure.
Inside the <body> tag, the content of the web page looks as follows:
- A <div> element with the class h-screen flex flex-col items-center is used to center the content vertically in the viewport.
- An <h1> element with the text Share Your Daily Joke on X is displayed at the top of the page.
- A <p> element with the ID joke-btn displays a message encouraging the user to click an X icon below to share a daily joke.
- Another <div> element with the ID joke-container displays the content of the data.joke property, which contains the daily joke fetched from the API.
- The <SocialShare> component enables sharing on social media. Configured with the buttons prop set to TwitterBUTTON (likely to display a Twitter share button), the description assigned to the data.joke set to akinyemi_t (the Twitter username), and the joke's title. Text.

Testing and debugging

Follow the steps below to test your application:

Navigate into your directory and run

npm run dev

Your application is now running at localhost:4321

To view your homepage, visit localhost:4321 in your browser. You should see the homepage.

Now, you can share your joke on social media by clicking the X icon.

What's next?

There are so many other things you can do with Astro social share. You can integrate other social buttons, like

Facebook
Hacker News
LinkedIn
Reddit
Twitter

Also, you can make the application more interactive by adding more features like changing the jokes.

Conclusion

Astro is a fast and flexible web framework suitable for various website types. Adding social sharing buttons to your Astro application enhances traffic, content promotion, brand presence, and lead generation.

This article has shown how to integrate social sharing buttons using the Astro social share component, using a random joke application as an example.

The provided GitHub source code serves as a practical reference.

By following the article, you've gained the ability to empower your web applications with Astro social share, making your content more shareable and engaging.

How to Prevent Unnecessary React Component Re-Rendering

Femi Akinyemi — Sat, 08 Jul 2023 05:48:48 +0000

Understanding how React renders components is essential for building efficient and performant applications. When a component’s state or props change, React automatically updates the User Interface(UI) to reflect those changes. As a result, React calls the component's render method again to generate the updated UI representation.

In this article, we will explore three React Hooks and how they prevent unnecessary renderings in React

These tools allow us to optimize our code by avoiding unnecessary re-renders, improving performance, and storing values efficiently.

By the end of this article, we'll better understand how to make our React applications faster and more responsive using these handy React hooks.

Using React's useMemo

In React, useMemo can prevent unnecessary re-renderings and optimize performance.

Let's explore how the useMemo hook can prevent unnecessary re-renders in our React components.

By memorizing the result of a function and tracking its dependencies, useMemo ensures that the process is recomputed only when necessary.

Consider the following example:

    import { useMemo, useState } from 'react';

    function Page() {
      const [count, setCount] = useState(0);
      const [items] = useState(generateItems(300));

      const selectedItem = useMemo(() => items.find((item) => item.id === count), [
        count,
        items,
      ]);

      function generateItems(count) {
        const items = [];
        for (let i = 0; i < count; i++) {
          items.push({
            id: i,
            isSelected: i === count - 1,
          });
        }
        return items;
      }

      return (
        <div className="tutorial">
          <h1>Count: {count}</h1>
          <h1>Selected Item: {selectedItem?.id}</h1>
          <button onClick={() => setCount(count + 1)}>Increment</button>
        </div>
      );
    }

    export default Page;

The code above is a React component called Page that uses useMemo to optimize the selectedItem calculation.

Here's the explanation:

The component maintains a state variable count using the useState hook.
The items state is initialized using the useState hook with the result of the generateItemsfunction.
The selectedItem is calculated using useMemo, which memorizes the result of the items.find operation. It only re-calculates when either count or items change.
The generateItems function generates an array of items based on the given count.
The component renders the current **count** value, the selectedItem id, and a button to increment the count.

Using useMemo optimizes performance by memoizing the result of the items.find operation. It ensures that the calculation of selectedItem is only performed when the dependencies (count or items) change, preventing unnecessary re-calculations on subsequent renders.

Memoization should be employed selectively for computationally intensive operations, as it introduces additional overhead to the rendering process.

Using React's useCallback

The useCallback hook in React allows for the memoization of functions, preventing them from being recreated during each component render. By utilizing useCallback. a part is created only once and reused in subsequent renders as long as its dependencies remain unchanged.

Consider the following example:

    import React, { useState, useCallback, memo } from 'react';

    const allColors = ['red', 'green', 'blue', 'yellow', 'orange'];

    const shuffle = (array) => {
      const shuffledArray = [...array];
      for (let i = shuffledArray.length - 1; i > 0; i--) {
        const j = Math.floor(Math.random() * (i + 1));
        [shuffledArray[i], shuffledArray[j]] = [shuffledArray[j], shuffledArray[i]];
      }
      return shuffledArray;
    };

    const Filter = memo(({ onChange }) => {
      console.log('Filter rendered!');

      return (
        <input
          type='text'
          placeholder='Filter colors...'
          onChange={(e) => onChange(e.target.value)}
        />
      );
    });

    function Page() {
      const [colors, setColors] = useState(allColors);
      console.log(colors[0])

      const handleFilter = useCallback((text) => {
        const filteredColors = allColors.filter((color) =>
          color.includes(text.toLowerCase())
        );
        setColors(filteredColors);
      }, [colors]);


      return (
        <div className='tutorial'>
        <div className='align-center mb-2 flex'>
          <button onClick={() => setColors(shuffle(allColors))}>
            Shuffle
          </button>
          <Filter onChange={handleFilter} />
        </div>
        <ul>
          {colors.map((color) => (
            <li key={color}>{color}</li>
          ))}
        </ul>
      </div>
      );
    }

    export default Page;

The code above demonstrates a simple color filtering and shuffling functionality in a React component. Let's go through it step by step:

The initial array of colors is defined as allColors.
The shuffle function takes an array and shuffles its elements randomly. It uses the Fisher-Yates algorithm to achieve shuffling.
The Filter component is a memoized functional component that renders an input element. It receives an onChange prop and triggers the callback function when the input value changes.
The Page component is the main component that renders the color filtering and shuffling functionality.
The state variable colors are initialized using the useState hook, with the initial value set to allColors. It represents the filtered list of colors.
The handleFilter function is created using the useCallback hook. It takes a text parameter and filters the allColors array based on the provided text. The filtered colors are then set using the setColors function from the useState hook. The dependency array [colors] ensures that the handleFilter function is only recreated if the colors state changes, optimizing performance by preventing unnecessary re-renders.
Inside the Page component is a button for shuffling the colors. When the button clicks, it calls the setColors function with the shuffled array of allColors.
The Filter component is rendered with the onChange prop set to the handleFilter function.
Finally, the colors array is mapped to render the list of color items as <li> elements.

The useCallback hook is used to memoize the handleFilter function, which means the function is only created once and reused on subsequent renders if the dependencies (in this case, the colors state) remain the same.

This optimization prevents unnecessary re-renders of child components that receive the handleFilter function as a prop, such as the Filter component.
It ensures that the Filter component is not re-rendered if the colors state hasn't changed, improving performance.

Using React's useRef

Another approach to enhance performance in React applications and avoid unnecessary re-renders is using the useRef hook. Using useRef, we can store a mutable value that persists across renders, effectively preventing unnecessary re-renders.

This technique allows us to maintain a reference to a value without triggering component updates when that value changes. By leveraging the mutability of the reference, we can optimize performance in specific scenarios.

Consider the following example:

    import React, { useRef, useState } from 'react';

    function App() {
      const [name, setName] = useState('');
      const inputRef = useRef(null);

      function handleClick() {
        inputRef.current.focus();
      }

      return (
        <div>
          <input
            type="text"
            value={name}
            onChange={(e) => setName(e.target.value)}
            ref={inputRef}
          />
          <button onClick={handleClick}>Focus</button>
        </div>
      );
    }

The example above has a simple input field and a button. The useRef hook creates a ref called inputRef. As soon as the button is clicked, the handleClick function is called, which focuses on the input element by accessing the current property of the inputRef ref object. As such, it prevents unnecessary rerendering of the component when the input value changes.

To ensure optimal use of `useRef,` reserve it solely for mutable values that do not impact the component's rendering. If a mutable value influences the component's rendering, it should be stored within its state instead.

Conclusion

Throughout this tutorial, we explored the concept of React re-rendering and its potential impact on the performance of our applications. We delved into the optimization techniques that can help mitigate unnecessary re-renders. React offers a variety of hooks that enable us to enhance the performance of our applications. We can effectively store values and functions between renders by leveraging these hooks, significantly boosting React application performance.

References

How To Stop React Components From Re-Rendering
Methods Of Improving And Optimizing Performance In React Apps

Build A Reusable Carousel With React And Splide.js

Femi Akinyemi — Tue, 13 Jun 2023 22:23:42 +0000

In today's rapidly evolving web development landscape, the importance of creating reusable components cannot be overstated. These components play a vital role in enhancing efficiency and ensuring maintainability. Carousels are a popular choice among the widely utilized components in web design. A carousel enables users to navigate seamlessly through a collection of images or items in a sliding manner.

In this article, you will build a reusable carousel component using React and Splide.Js — a lightweight and versatile slider library.

By following a systematic approach, you will cover the installation of necessary dependencies and the implementation of fundamental functionalities. Upon concluding this article, you will comprehensively understand crafting a fully functional and reusable carousel component with React and Splide.js.

This accomplishment will equip you to integrate the carousel into your future web projects effortlessly.

Why Splide?

Splide.js is a lightweight, flexible, and accessible slider and carousel library for creating web-based sliders and carousels.

It’s written in TypeScript and supports various features, such as:

Autoplay with a progress bar and a play-pause toggle button
Multiple slides
Slide or fade transition by CSS
Flexible and extensible
Protected by 400+ test cases
Lightweight, 29kB (12kB gzipped)
No dependencies

And many others.

Splide installation

To install Splide into your project, you can choose one of the four options listed below:

NPM

It is recommended to install Splide using NPM. To install the latest version, use the following command to do so:

npm install @splidejs/splide

Hosting Files

You can download the Splide package from the following link:
Download

Then, Go to the dist/js directory, and import the splide.min.js file by the <script> tag:

<script src="path-to-the-file/splide.min.js"></script>

CDN

You can also include this library from CDN:

jsDelivr

It is recommended to use a specific version number instead of the "latest" keyword for production to avoid unexpected breakage from the further update.

Integration

Integration packages are available for React, Vue and Svelte.

React Splide
Vue Splide
Svelte Splide

Integrating Splide with React

To Integrate Splide with React, you will use the recommended installation method, NPM, to install React Splide, a React component for a Splide slider/carousel.

Installation

First, you must create a React.js starter project by navigating to your desired directory and running the command below in your terminal.

npx create-react-app splidereacttutorial && cd splidereacttutorial

The command creates a React.js project called splidereacttutorial and navigates into the project directory.

Next, you need to Install Splide by running the following command in your terminal:

$ npm install @splidejs/splide

Usage

In the src directory, create a folder with the name components. The directory will contain all the reusable components for the carousel.

Carousel Component

In the src directory, create the file src/components/Carousel and add the following code:

import React from "react";
import { Splide, SplideSlide } from "@splidejs/react-splide";
import "@splidejs/react-splide/css";

function Carousel({ props }) {
  return (
    <div
      style={{
        display: "flex",
        justifyContent: "center",
        alignItems: "center",
      }}
    >
      <Splide
        aria-label="My Favorite Images"
        style={{
          display: "flex",
          justifyContent: "center",
          alignItems: "center",
        }}
        options={{
          width: "50%",
        }}
      >
        <SplideSlide>
          <img src={props.img_one} alt={props.img_alt} style={props.style} />
        </SplideSlide>
        <SplideSlide>
          <img src={props.img_two} alt={props.img_alt} style={props.style} />
        </SplideSlide>
      </Splide>
    </div>
  );
}

export default Carousel;

The code above implements a React functional component called Carousel. It uses the Splide and SplideSlide components from the @splidejs/react-splide library to render a carousel with two slides that contain images. The component accepts image URLs, alternate text, and styling as props and displays the images within the carousel.

Also, In the src/App.css file, replace the code with the following code:

.App {
  display: flex;
  justify-content: center;
  align-items: center;
}

The code above uses CSS to style the .App class, making it a flex container that horizontally and vertically centers its child elements.

Now, n the src/App.js replace the code with the following code:


import "./App.css";
import Carousel from "./components/Carousel";

function App() {

const props = {

  img_one: 'https://images.creativefabrica.com/products/previews/2023/05/11/zZEZKFvQo/2Pdr8is8AS0vymhPaFPB1WOZ7DF-desktop.jpg',
  img_two: 'https://iso.500px.com/wp-content/uploads/2016/03/stock-photo-142984111-1500x1000.jpg',
  img_alt: 'image_alt',
  style: {
    width: "100%",
    height: "400px",
    objectFit: 'cover',


  }
}

  return (
    <>
      <h1
        style={{
          textAlign: "center",
        }}
      >
        Basic Carousel
      </h1>

      <div className="App">
        <Carousel props={props} />
      </div>
    </>
  );
}

export default App;

The code above imports a CSS file named App.css and a component called Carousel from ./components/Carousel.
Inside the App function component, an object named props is defined, which contains properties for two images (img_one and img_two), an alternate text for the images (img_alt), and styling information.

The component returns JSX elements, including a <h1> heading with the text Basic Carousel centered using inline styles.
Within an <div> element with the class App, the Carousel component is rendered with the props object passed as a prop.

Testing the Carousel component

To test the Carousel component, Navigate into your splidereacttutorial directory and run:

npm start

Your Carousel component is now running at localhost:3000
To view the Carousel, visit localhost:3000 in your browser. You should see the component rendered.

Creating Auto-scroll Carousel

To create an auto-scroll carousel, you will use The Auto Scroll extension that continuously scrolls the carousel, which goes well with "Drag Free" mode.

To Install The Auto Scroll extension, run the command below in your terminal:

npm install @splidejs/splide-extension-auto-scroll

Now, In the src/components/Carousel file, Replace the code with the following code:

import React from "react";
import { Splide, SplideSlide } from "@splidejs/react-splide";
import { AutoScroll } from "@splidejs/splide-extension-auto-scroll";
import "@splidejs/react-splide/css";

function Carousel({ props }) {
  return (
    <div>
      <Splide

        // ...

        options={{
          width: "100%",
          rewind: true,
          autoplay: "true",
          perPage: 2,
          perMove: "1",
          gap: "2rem",
          height: "15rem",
          type: "loop",
          rewindSpeed: "3000",
          arrows: "true",
          pagination: "false",
          extensions: { AutoScroll },
          autoScroll: {
            speed: 3,
            pauseOnHover: true,
            pauseOnFocus: false,
          },
          breakpoints: {
            1000: {
              perPage: 1,
            },
          },
        }}

        // ...

      >

        {/* ... */}

      </Splide>
    </div>
  );
}

export default Carousel;

The code above sets various options for the Splide carousel component. It configures properties such as width, rewind behavior, autoplay, slide count, spacing, height, looping, rewind speed, navigation arrows, pagination, extensions, auto-scrolling behavior, and responsive breakpoints. These options define the carousel's appearance, behavior, and responsiveness.

To test the Auto Scroll extension, visit localhost:3000 in your browser. You should see the component rendered below the Basic Carousel.

Creating a Thumbnail Carousel

To create a Thumbnail Carousel, In the src directory, create a file with the name Thumbnail.js and paste the following code:

import "../App.css";
import { Splide, SplideSlide } from "@splidejs/react-splide";
import "@splidejs/react-splide/css";
import p1 from "./firstimage.jpeg";
import p2 from "./secondimage.jpeg";
import p3 from './thirdimage.jpeg';
import p4 from './fourthimage.jpeg'
import { useRef } from "react";

export default function Thumbnail() {
  const thumbsImages = [p1, p2, p3, p4];

  const mainOptions = {
    type: "loop",
    perPage: 1,
    perMove: 1,
    gap: "1rem",
    pagination: false,
    height: "27.8125rem",
  };

  const style = {
    width: "100%",
    height: "400px",
    objectFit: "cover",
  };

  const generalStyle = {
    margin: '0 auto',
    width: '50%'
  }

  const btn_img = {
      width: "70px",
      height: "70px",
      overflow: "hidden",
      listStyle: "none",
      margin: "0 0.2rem",
      cursor: "pointer"
  }

const thumbnailsstyle = {
  display: "flex",
  justifyContent: "center",
  alignItems: "center",
  listStyle: "none"
}

  const mainRef = useRef(null);

  const handleThumbs = (id) => {
    if (mainRef.current) {
      mainRef.current.go(id);
    }
  };

  return (
    <>
      <div className="App_" style={generalStyle}  >
        <div>
          <Splide options={mainOptions} ref={mainRef} style={{}}>
            <SplideSlide>
              <img src={p1} alt="product imag 1" style={style} />
            </SplideSlide>
            <SplideSlide>
              <img src={p2} alt="product imag 2" style={style} />
            </SplideSlide>

            <SplideSlide>
              <img src={p3} alt="product imag 2" style={style} />
            </SplideSlide>

            <SplideSlide>
              <img src={p4} alt="product imag 2" style={style} />
            </SplideSlide>
          </Splide>

          <ul style={thumbnailsstyle } >
            {thumbsImages?.map((thumbnail, index) => (
              <li key={thumbnail}>
                <button onClick={() => handleThumbs(index)}>
                  <img
                    src={thumbnail}
                    alt="product thumbnail"
                    style={btn_img}
                  />
                </button>
              </li>
            ))}
          </ul>
        </div>
      </div>
    </>
  );
}

The code above is a React component that displays a main image carousel/slider and thumbnail images. It uses the Splide component from @splidejs/react-splide to create the carousel and handles thumbnail clicks to update the main carousel. The component defines image paths, carousel options, and styling objects. It renders the main carousel and thumbnail buttons using the map function.

Now, In the src/App.js file, Replace the code with the following code:

import "./App.css";
import Thumbnail from "./components/Thumbnail";

function App() {

  return (
    <>
      <h1
        style={{
          textAlign: "center",
        }}
      >
        Thumbnail Carousel
      </h1>
      <div className="App">
        <Thumbnail />
      </div>
    </>
  );
}

export default App;

This code above is a component that serves as the application's main entry point. It imports the Thumbnail component and the App.css file for styling.

Inside the App component, it renders a heading with the text Thumbnail Carousel centered using inline styling. It also renders a <div> with the class name App and includes the Thumbnail component.

To test the Thumbnail Carousel, visit localhost:3000 in your browser.

Creating a Video Carousel

To create the Video Carousel, you will use The Video extension

To Install The Video Carousel extension, run the command below in your terminal:

npm install @splidejs/splide-extension-video

Now, In the src directory, create a file with the name VideoCarousel.js and paste the following code:


import React, { useRef } from "react";
import { Splide, SplideSlide } from "@splidejs/react-splide";
import { Video } from "@splidejs/splide-extension-video";
import "@splidejs/splide-extension-video/dist/css/splide-extension-video.min.css";

const VideoCarousel = () => {
  const options = {
    rewind: true,
    autoPlay: true,
    perPage: 2,
    gap: 10,
  };

  const videos = ["iRmx-btWrFk", "liJVSwOiiwg", "hAAZx5fHMZY"];

  const slideImageStyle = {
    maxWidth: "100%",
    height: "auto",
  };

  const mainRef = useRef(null);

  return (
    <div>
      <Splide options={options} extensions={Video} ref={mainRef}>
        {videos.map((id, index) => (
          <SplideSlide key={id} data-splide-youtube={id}>
            <iframe
              style={slideImageStyle}
              width="900"
              title={`YouTube Sample ${index + 1}`}
              src={`https://www.youtube.com/embed/${id}`}
            ></iframe>
          </SplideSlide>
        ))}
      </Splide>
    </div>
  );
};

export default VideoCarousel;

The code above uses the Splide library and the Splide Video extension in React to set up a video carousel. It defines the VideoCarousel component, configures the carousel options, and specifies an array of video IDs. The component renders a Splide component with SplideSlide components inside, each containing an embedded iframe with a YouTube video. The ref attribute is used to access the Splide instance. It creates a functional video carousel component using Splide and Splide Video extensions.

Now, In the src/App.js file, Replace the code with the following code:

import "./App.css";
import VideoCarousel from "./components/VideoCarousel";

function App() {

  return (
    <>
      <h1
        style={{
          textAlign: "center",
        }}
      >
      Video Carousel
      </h1>
      <div >
        <VideoCarousel/>
      </div>
    </>
  );
}

export default App;

This code above is a component that serves as the application's main entry point. It imports the VideoCarousel component and the App.css file for styling.

To test the Video Carousel, visit localhost:3000 in your browser.

Conclusion

Creating reusable components is vital to web development. A reusable carousel component can significantly enhance web projects' efficiency and maintainability. You used React and Splide.js in the article to construct a versatile and adaptable carousel component that seamlessly integrates into any web project.

Following a systematic approach, you demonstrated how to implement fundamental functionality, customize the styling, and incorporate additional features like autoplay and navigation. The result is a dynamic and flexible carousel component that enhances the user experience and adds visual appeal to web projects.

With the knowledge gained from this article, you can now create your reusable carousel component using React and Splide.js, elevating your web development skills to the next level.

References

How to Build and Publish Your First React NPM Package

Femi Akinyemi — Fri, 09 Jun 2023 18:47:29 +0000

Building and publishing your first Node Package Manager(NPM) is an exciting milestone in your journey as a developer. NPM has revolutionized how you share and reuse code in the JavaScript ecosystem, empowering developers to contribute to the open-source community and enhance the efficiency of their projects.

Whether you want to create a reusable library, a command-line tool, or any other piece of code that can be easily installed and integrated into projects, this article will guide you through the essential steps of building and publishing your first NPM package.

Prerequisites

To fully grasp the concepts presented in this tutorial, the following are required:

A GitHub account
Node.js ( v10+) installed
NPM account created
Basic understanding of JavaScript

What is NPM

NPM is a powerful tool transforming how developers share and manage JavaScript code. It is the default package manager for Node .js, a popular runtime environment for executing JavaScript code outside a web browser. NPM is a vast repository of over a million packages, offering developers access to a wide range of open-source libraries, frameworks, and tools.

With NPM, developers can easily install, update, and manage dependencies for their projects, streamlining the development process and saving valuable time. Whether you need to integrate third-party libraries or share your code with the community, NPM provides a centralized platform for discovering, distributing, and collaborating on JavaScript packages.

What are you building

This article explains the process of building and publishing a React NPM package rather than creating an elaborate or complex package. Following the steps outlined in a simple example like the one you'll build, you'll develop a solid foundation to apply the same principles to more advanced packages.

In this article, you will build a package called capitalizefirstletterofastring. As the name suggests, this package capitalizes the first letter in a string. It is an excellent place to understand the essential steps in building and publishing an NPM package. So let's dive in and explore the process of creating and publishing your capitalizefirstletterofastring package.

Getting Started

To begin, you need to prepare your environment. A few ways to build a React package include tools like Bit, Storybook, Lerna, and TSDX. However, for this tutorial, you will use a zero-configuration bundler for tiny modules called Microbundle.

Why microbundle?

With Microbundle, tiny modules can be bundled without any configuration, and it offers the following features:

Single dependency for bundling with just a package.json
ESnext & async/await support through Babel and async-promises
Produce highly optimized code for all inputs
Zero-configuration TypeScript support
Includes built-in Terser compression and tracks gzipped bundle size
Creates multiple output formats for each entry (CJS, UMD & ESM)
Supports multiple entry modules (*cli.js* + *index.js*, etc) # Building the package ## Install microbundle

To use microbundle, run the command below in your terminal.

npm i -D microbundle

The command generates a node_modules folder in your terminal and a package.json file.

In the package.json, replace the existing code with the code below.

    {
      "name": "capitalizefirstletterofastringpkg",
      "version": "1.0.0",                     
      "type": "module",
      "source": "src/index.js",            
      "main": "dist/index.js",
      "module": "dist/index.module.js",
      "unpkg": "dist/index.umd.js",
      "scripts": {
        "build": "microbundle",           
        "dev": "microbundle watch"        
      },
      "devDependencies": {
        "microbundle": "^0.15.1"
      },
      "repository": {
        "type": "git",
        "url": "git+https://github.com/femakin01/CapitalizeFirstLetterofaString.git"
      }
    }

The provided package.json code is a configuration file used in Node.js projects. Here's an explanation of each key-value pair in the code:

"name": "capitalizefirstletterofastringpkg" Specifies the name of the package
"version": "1.0.0": Indicates the version of the package
"type": "module": Indicates that the project uses ECMAScript modules
"source": "src/index.js": Specifies the entry file for the source code
"main": "dist/index.js": Indicates the main file that will be used when importing the package
"module": "dist/index.module.js": Specifies the module file that will be used in ECMAScript module systems
"unpkg": "dist/index.umd.js": Specifies the file to be used in the UMD (Universal Module Definition) format
"scripts"
- "build": "microbundle": Executes the microbundle command to build the package.
- "dev": "microbundle watch": Executes the microbundle watch command to start a development server that watches for changes
"devDependencies": Lists the development dependencies required for the project. In this case, it includes "microbundle": "^0.15.1"
"repository": Specifies the repository type and URL of the project

This package.json file is specifically configured for the capitalizefirstletterofastring package, utilizing the microbundle package for building and watching the code.

At this point, your new package.json file should resemble this screenshot and is all set up for local development.

Package Development

To create the package that capitalizes the first letter of a string, In the src/index.js file, paste the code below:

    export const Capitalize = ({ str }) => {
      return str.charAt(0).toUpperCase() + str.slice(1)
    }

The code above exports a concise function named Capitalize that takes a string input and returns the same string with the first character capitalized. It achieves this by using str.charAt(0).toUpperCase() + str.slice(1)

Next, try it out and build the package by running

    npm run build

Microbundle produces esm, cjs, umd bundles with your code compiled to syntax that works everywhere.

Publishing the package

To publish your package, run the following command to authenticate yourself:

    npm login

You will be prompted to provide your details, provide the required details and hit enter. To test the login's success, enter the command:

    npm whoami

Your username should be logged into the CLI.

Now, you can proceed to publish your package by running the command below:

    npm publish

Note that you may not be able to publish the random-number-package if someone else already has a package with the same name in the registry. You can change the package's name to something unique to make it publishable. Check here for guides on naming a package.

After the publication is done without error, you can visit your account in the NPM registry to see the package.

Testing the Package

To test the package, bootstrap a Next.js application by running the command below:

    npx create-next-app@latest

On installation, you'll see the following prompts:

    What is your project named? my-app
    Would you like to use TypeScript with this project? No / Yes
    Would you like to use ESLint with this project? No / Yes
    Would you like to use Tailwind CSS with this project? No / Yes
    Would you like to use `src/` directory with this project? No / Yes
    Use App Router (recommended)? No / Yes
    Would you like to customize the default import alias? No / Yes

After the prompts, create-next-app will create a folder with your project name and install the required dependencies. Next, navigate to the project directory and install the published package by running the command below:

    npm i capitalizefirstletterofastringpkg

Next, in the src/app/page.js replace the content with the following code:

    import React from 'react'
    import { Capitalize } from 'capitalizefirstletterofastringpkg'
    function    page() {
      return (
        <div>  `This is  a Sample Usuage {<Capitalize str={'example'} />}`</div>
      )
    }
    export default page

If you navigate to localhost:3000, you will see the first letter of the string in your package capitalized.

Congratulations! You have just successfully created your first React NPM package professionally.

Conclusion

Creating your React component library is a valuable investment for teams or individuals seeking to streamline their development process and ensure project consistency. Following the steps detailed in this guide, you can effortlessly build a library of reusable components that can be shared and utilized across various projects.
Leveraging the capabilities of React and the flexibility of custom components, the possibilities are endless in terms of what you can create and achieve.
Begin constructing your component library today and experience its positive influence on your development workflow!

DEV Community: Femi Akinyemi

What usually slows a WordPress site

What people feel first

What usually slows WordPress

Why a tip list is hard to use

What a useful report does

How to try it on your WordPress site

For freelancers and agencies

FAQ

Is PageSpeed Insights enough for a WordPress site?

Is slow WordPress always a hosting problem?

Do plugins always make WordPress slow?

Does PafCore replace WordPress speed plugins?

When PageSpeed Insights is enough (and when it is not)

Introduction

What PageSpeed Insights is good at

Where a single run fools you

When manual checks stop being enough

You watch more than a handful of pages

A deploy can break speed overnight

You need history, not only today’s screenshot

You need budgets and alerts

You need something a client can read

A plain comparison

Use both. Split the jobs.

A week one checklist

Conclusion

FAQ

Why your Lighthouse score changes when you did nothing

Introduction

Why the number moves

What you will set up

Step 1. Measure a quiet page

Step 2. Ship the change, then measure again

Step 3. Write the slow thing in seconds

Step 4. Do not drown in the tip list

Step 5. Put numbers in the pull request

What you get from this habit

Conclusion

What AI Still Misses in Production Next.js Apps

Introduction

1. Next dev watching the whole monorepo

2. Putting server secrets in NEXT_PUBLIC_*

3. API address missing or duplicating /api/v1

4. Adding server API files to an app that deploys as static HTML

5. Local proxy setup that does not exist in production

6. Server-only code imported in a client component

7. Login token is valid but for the wrong app

8. Fake login still turned on while shipping real auth

9. Old dev server still running on the port

10. No conflict on your machine, conflict on GitHub

11. Expired login token in your env file

12. Public env vars set after the build, not during it

14. Login page and dashboard on the same local port

15. Green code review, nobody ran a production build

Conclusion

Need Help With Your Next.js or AWS Project?

Wedding Memories: The Collaborative Wedding Album!

Wedding Memories

What I Built

Demo

My Code

More Details

API Integration Breakdown:

Conclusion

How to Upload Files to Amazon S3 with React and AWS SDK

INTRODUCTION

Prerequisite:

Getting Started

Creating S3 Bucket

Making the files publicly accessible

Editing CORS Policy

Installing AWS SDK for JavaScript

Conclusion

Build a simple project management app with Neon, PostgREST, and DigitalOcean

Introduction

Prerequisites

Create a Neon project

Project directory

Loading demo data into the database

2. Putting server secrets in `NEXT_PUBLIC_*`

3. API address missing or duplicating `/api/v1`

4. Adding server API files to an app that deploys as static `HTML`