DEV Community: Yuichi Nabeshima

Building a Full-Stack App with React Router Framework Mode, Batch Jobs, and Email Scheduling

Yuichi Nabeshima — Tue, 13 May 2025 14:30:03 +0000

Introduction

I recently released a personal project: a full-stack restaurant reservation app built using React Router Framework Mode and TypeScript. In this article, I will explain the architecture I used to build the application, including how I implemented batch processing and scheduled email delivery to support real-world operational needs.

🔗 Live Demo: https://my-booking.tech/
📂 Article: https://dev.to/yuichi_nabeshima_canada/bringing-mvc-back-a-full-stack-architecture-with-react-router-frame-work-mode-3c8b

Architecture

For this project, the web server is a full-stack application using React Router. The architecture follows a traditional MVC-like structure, where the front-end and back-end servers are not separated but integrated into one. I implemented a custom batch process for handling data updates and other operations, deploying a dedicated batch server separate from the web server.

Why separate the batch server?

To prevent batch processing from consuming too much memory and impacting the web server's performance.
To create an environment similar to local development for testing batch processes in production.

I deployed the app on fly.io, which offers free-tier instances that fit within the limits for web, batch, and DB servers (three instances). However, please note that keeping the batch server always running may exceed the $5 free credit.

The batch processing logic itself is implemented within the same full-stack application, and executed via command-line scripts like npm run batch.

Here's how I defined the batch script in my package.json

// package.json
  "scripts": {
    "batch": "tsx ./app/.server/batch/runBatch.ts",

For executing batch jobs in production, I access the batch server via fly ssh console and run the job with npm run batch. You can find the source code on GitHub at the link below.
【GitHub】https://github.com/YuichiNabeshima/my-booking

The web server is optimized for performance by using a production build before deployment. In contrast, the batch server is deployed without a build step, since it only needs to run command-line scripts and doesn’t serve client assets.

Implementing Scheduled Tasks

With batch jobs in place, I also needed a way to schedule automatic execution at specific times or intervals. Following the recommended method from fly.io, I installed supercronic in the Dockerfile of the batch server and added the execution logic.

The key advantage here is that by running scheduled tasks at the server level, we avoid accidental execution of unnecessary tasks on development or local servers (such as sending test emails) during testing.

Batch Server for Email Delivery

For example, I designed the email delivery system to not send emails instantly. Instead, email requests are added to a Mail Queue table. A batch job runs every minute to process and send emails from the queue. The batch job processes each record, removes it from the queue, and logs it in the Mail Log table.

Advantages of this Mail Queue Approach:

Handles bulk email deliveries more effectively by distributing the load
Makes it easier to manage email logs
Scalable for larger applications

However, this method does have a downside: the system is not real-time, as the batch job runs only once per minute. For larger-scale systems, a job queue system like BullMQ could be a better choice, as it allows delayed job execution, retries, and parallel processing, making the architecture more scalable.

Conclusion

In this article, I’ve covered the basic architecture of the app I built and discussed the email delivery system powered by batch processing. I hope this gives you some insights into handling background jobs and building full-stack applications with React Router and TypeScript.

I will be posting a more detailed breakdown of the batch implementation in a future article.

If you’re interested in learning more about full-stack architecture, React Router, or background job processing, feel free to reach out!

Thank you for reading! 😊

Bringing MVC Back: A Full-Stack Architecture with React Router Frame Work Mode

Yuichi Nabeshima — Tue, 06 May 2025 15:52:01 +0000

Introduction

Recently, I released a full-stack restaurant reservation web app built using React Router in framework mode. In this post, I’ll introduce the architecture with a focus on the backend setup.

🔗 Live Demo: https://my-booking.tech/
📂 GitHub Repo: https://github.com/YuichiNabeshima/my-booking

Overall Goals for the App

In modern web applications, which require rich user experiences and interactivity, adopting a JavaScript framework for the frontend has become the de facto standard.

Commonly, frontend meta-frameworks (such as Next.js, Nuxt, Remix) are used along with backend frameworks like Express.js, NestJS, or Laravel. Alternatively, serverless backend setups (e.g., AWS Lambda) are also popular.

For this web app, I wanted to find a middle ground between simplicity and scalability, ensuring that the architecture could handle even large-scale development while still being fast and easy to implement.

I focused on monolithic architectures like Rails and Laravel, which are still widely used in many development environments. These architectures follow an MVC-like structure and have a class-based design. Inspired by this, I explored how to implement a similar architecture in a React-based framework that would be both simple and scalable.

Why React Router?

I chose React Router for this project because it was integrated with Remix last year, carrying forward Remix's philosophy of a web-standard SSR-focused framework. I thought it was a great fit for returning to a more traditional architecture.

React Router also offers flexible directory structures, which made it easier to achieve the goals of this project.

Treating the MVC Controller

In React Router, you can write loader functions (responsible for fetching data) and action functions (responsible for updating data) in route files (e.g., route.tsx).

These two server-side functions can be treated as GET and POST requests, with the route.tsx itself acting as the controller in an MVC architecture. Since route.tsx is the entry point, it doesn't include the detailed implementation of the UI but instead imports and returns the base Page component, which serves as the foundation for the UI components.

// routes/top/route.tsx

export function meta() {
  return [
    { title: 'Top Page' },
    { name: 'description', content: 'Main landing page' },
  ];
}

export async function loader() {
  // Fetch server-side data
}

export async function action() {
  // Handle form submissions
}

export default function Route() {
  return <Page />;
}

The directory structure is introduced in this article as well:

How I organized my full-stack React Router project

Architecture Diagram

The following diagram shows how data flows from the UI to the database and back, using React Router’s loader and action functions as entry points to the backend logic.

To illustrate how this MVC-like architecture is implemented within a single repository, here is a directory-level view of the codebase.

This shows how the UI, controller logic, business logic, and data access layers are all clearly separated, yet co-located in a monorepo-style structure.

Explanation of Each Layer

UI Layer

The frontend is designed in a simple React way, with a Page component at the root, from which the components are built in a tree structure.

As shown in the diagram, using useLoaderData() allows components beneath Page.tsx to access pre-fetched server-side data, without needing prop-drilling or a global state management system.

Since useLoaderData() references cached data that has already been fetched, there’s minimal performance overhead.

Controller Layer (route.tsx)

This layer acts as a mediator between the UI layer (pages) and the service layer, responsible for input processing and control logic:

Extracting data sent from the UI layer
Performing general validations such as required field checks and email format validation
Calling the service layer to execute processing with the provided data
Handling errors based on the returned values from the service layer
Returning the result to the UI layer if no errors occur.

These are the main responsibilities of the controller layer.

Service Layer

The service layer contains the actual business logic.

In most cases, a main service class (e.g., LoaderService or ActionService) is called from route.tsx. Within the service class, other repository layers or service classes are combined to handle the business logic.

For example, loader calls the LoaderService, and action calls the ActionService.

Repository Layer

The repository layer wraps ORM, such as Prisma, and is called by the service layer.

The advantages of wrapping Prisma in classes instead of using it directly are:

It makes it easier to switch to another ORM in the future.
Declarative methods specific to the use case can be written in the wrapper class (e.g., getPublishedArticle()).
The class can be easily mocked, making it simpler to test. By using this structure, the service layer can focus on "what to fetch" rather than being coupled to a specific DB implementation, improving maintainability and testability.

Conclusion

This architecture allows me to maintain a modern React UI experience while ensuring a simple, scalable, and robust backend setup.

I hope to dive deeper into topics such as error handling and testing strategies in a future post.

Thank you for reading!
As I am currently exploring new career opportunities in the Vancouver area, If you're looking for someone passionate about modern full-stack development and architecture, I’d love to connect and see how I could contribute to your team. Feel free to contact me if you're looking for a developer with a strong passion for web development!

How I Organized My Fullstack React Router Project Using Page-Based Colocation

Yuichi Nabeshima — Thu, 01 May 2025 18:48:46 +0000

🧩 Organizing Routes with Page-Based Colocation in React Router (Framework Mode)

Introduction

I recently built a fullstack restaurant reservation web app using React Router framework mode. One of the most important design decisions was how to organize the project’s file structure.

React Router allows colocating UI and backend logic per route. I took this idea further by grouping everything related to a single page — components, types, constants, server logic — under one route folder.

This article shows how that structure looks and why it worked well in practice.

🔗 Live Demo: https://my-booking.tech/
📂 GitHub Repo: https://github.com/YuichiNabeshima/my-booking
👉 Previous article: https://dev.to/yuichi_nabeshima_canada/building-a-full-stack-web-app-only-with-react-router-1fah

What Is Colocation?

Colocation means putting related files close together.

Instead of separating files by type (like all components in one folder, all hooks in another), we group files by feature or page. So everything for /top, for example, lives under routes/top/.

This helps keep responsibilities clear and makes the codebase easier to navigate.

Example Directory Structure (with comments)

Here’s an example file structure for a typical page like /top.
(I’m using top/ here just as a placeholder to keep things simple.)

.
└── app/
    ├── routes/
    │   ├── top/                          # Route folder for "/top" page
    │   │   ├── .server/                  # Server-only logic (e.g. DB access, API calls)
    │   │   ├── components/               # Page-local UI components
    │   │   │   ├── Page.tsx             # Top-level page component rendered by route.tsx
    │   │   │   └── articleList/         # Nested component group for article list
    │   │   │       ├── ArticleList.tsx
    │   │   │       ├── useArticles.ts
    │   │   │       └── article/
    │   │   │           └── Article.tsx
    │   │   ├── constants/               # Page-specific constants
    │   │   ├── schemas/                 # Zod schemas for validation
    │   │   ├── types/                   # Type definitions (e.g. props)
    │   │   ├── utils/                   # Pure helper functions
    │   │   └── route.tsx                # Main route file: meta, loader, action
    │   └── about/
    ├── .server/                         # Global server logic
    ├── components/                      # Shared UI components
    ├── constants/                       # Global constants
    ├── types/                           # Global types
    └── utils/                           # Global utilities

How Routing Is Set Up

React Router maps URL paths to files in the routes/ directory. Here's a basic route config:

export default [
  index('routes/top/route.tsx'),
  route('about', 'routes/about/route.tsx'),
];

Each route.tsx file typically exports the following:

meta() — Sets the <title> and description
loader() — Fetches server data
action() — Handles POST or form requests
A default React component — usually rendering Page.tsx

// routes/top/route.tsx

export function meta() {
  return [
    { title: 'Top Page' },
    { name: 'description', content: 'Main landing page' },
  ];
}

export async function loader() {
  // Fetch server-side data
}

export async function action() {
  // Handle form submissions
}

export default function Route() {
  return <Page />;
}

My Implementation Strategy

When building out pages, I colocate everything related to that route inside the same folder: components, hooks, constants, and even backend logic.

Here’s the principle I follow:

“Colocate first. Extract later.”

That means:

If something is only used by one page, it stays in that page’s folder.
If I realize it’s reusable, I promote it to a shared folder like /components or /utils.

This helps me avoid overengineering and lets patterns emerge naturally as the app grows.

Benefits and Tradeoffs

✅ Benefits

Easy to understand — All code for a feature is in one place
Simple to scale — You don’t need complex abstractions early
Great for onboarding — New developers can find everything quickly

⚠ Tradeoffs

Some duplication early on
Requires discipline to refactor and extract shared code

But in my experience, these tradeoffs are worth it. The simplicity and clarity really help on real-world teams.

Conclusion

Using page-based colocation with React Router made development more straightforward and intuitive for me. It helps create a clean, scalable, and understandable project layout.

If you're using React Router for fullstack development, I recommend trying this approach in your next project.

👉 See the full source code on GitHub

Thanks for reading!

Building a Full-Stack Web App Only with React Router

Yuichi Nabeshima — Tue, 29 Apr 2025 22:16:31 +0000

A portfolio project built to land my next software engineering opportunity — and explore how far React Router (Framework Mode) can go.

🚀 Project Overview

I am building a full-stack restaurant reservation platform as a portfolio project. It features both a public-facing reservation site and an admin dashboard — all built on top of React Router Framework Mode, with a PostgreSQL + Prisma backend and a modern UI stack.

Although the app uses dummy data, it’s fully functional and architected like a real-world production system.

🔗 Live Demo: https://my-booking.tech/
📂 GitHub Repo: https://github.com/YuichiNabeshima/my-booking

I’m currently open to software engineering roles — especially full-stack roles involving React, TypeScript, and scalable backend architecture.

🧠 Why React Router?

React Router inherits the Remix philosophy — staying close to web standards, server-side rendering by default, and minimizing client-side overhead.
This mirrors the traditional web model (routing, form submissions, session-based auth) while still leveraging React’s component-driven architecture.

⚙️ The result: a fast, SSR-first app with minimal use of global state or client-side data fetching libraries.

The frontend is built with modern functional React, while the backend follows a more class-based, structured design — a mix that reflects real-world systems I’ve worked on and enjoy building.

🧩 Features

📅 Guests can book without creating an account

🔐 Secure, unique reservation URLs via JWT

🧑‍💼 Admin dashboard to manage bookings and restaurants

⚡️ SSR-first architecture with minimal client-side state

✅ Type-safe forms with full validation

🛠️ Tech Stack

React Router (Framework Mode) + TypeScript
PostgreSQL + Prisma
Redis (Upstash) + Custom session-based auth
JWT for reservation access
Tailwind CSS + shadcn/ui
Zod + Conform for form validation
Amazon S3 / SES for file and email handling
Fly.io for hosting

👋 I'm Open to Work

I'm currently looking for roles focused on full-stack development — particularly with React, TypeScript, and scalable backend architecture.

If you’re hiring (or know someone who is), I’d love to connect!

💬 I’d be happy to answer any questions about the tech choices or structure!
Thanks for reading!

Remix with PostgreSQL and Prisma from Local Environment Setup to Deploy to Fly.io

Yuichi Nabeshima — Sat, 27 Jul 2024 10:23:29 +0000

Hi there😊
I'm Yuichi, a CCTB student and a Frontend developer.

Remix is a great framework and I'm really into it right now.

It is React framework but we can develop backend together, so it is very convenient.

I am going to introduce to create base of full stack app by the Remix with PostgreSQL and Prisma to deploy on Fly.io.
And I also try to reach connecting DBeaver both environment local and production.

Tools

macOS Sonoma 14.1.2
Docker Desktop 4.32.0
Node 20.16.0
DBeaver 24.1.3

Why Fly.io

Fly.io allows you to easily deploy the Remix apps and also provides PostgreSQL.
It has free plan, so it doesn't cost much to deploy a small project.

First, Install Remix

npx create-remix@latest

Where should we create your new project? => ./my-remix-app
Initialize a new git repository? => Yes
Install dependencies with npm? => Yes

cd ./my-remix-app

Create docker-compose.yml

Next, create docker-compose.yml on the project root for creating the PostgreSQL container for the local environment.

touch docker-compose.yml

docker-compose.yml

version: "3.7"
services:
  postgres:
    image: postgres:latest
    restart: always
    environment:
      - POSTGRES_USER=postgres
      - POSTGRES_PASSWORD=postgres
      - POSTGRES_DB=postgres
    ports:
      - "5432:5432"
    volumes:
      - ./postgres-data:/var/lib/postgresql/data

Then, start the container.
Please start the Docker Desktop before.

docker compose up -d

Install Prisma

Install Prisma to manipulate data of the database from the app.

npm install prisma --save-dev

Please initialize prisma.
Executing the command below will create a prisma directory and .env file.

npx prisma init --datasource-provider postgresql

Then, Modify value of DATABASE_URL in .env to like below for connecting prisma to database.

DATABASE_URL="postgresql://postgres:postgres@localhost:5432/postgres?schema=public"

This string will contain the value set in docker-compose.yml.

If the user name or password set in docker-compose.yml are different, please change your DATABASE_URL.

Migrate Database

Now that prism and the database are connected let's add a table to the database for testing.
Please edit schema.prisma under the prisma like below.

// This is your Prisma schema file,
// learn more about it in the docs: https://pris.ly/d/prisma-schema

generator client {
  provider = "prisma-client-js"
}

datasource db {
  provider = "postgresql"
  url      = env("DATABASE_URL")
}

+ model Post {
+   id      Int      @id @default(autoincrement())
+   name    String?
+   body    String   @db.Text

+   @@map("post")
+ }

@@map is the characters you enter here will become the table name.

Then, execute migration.

npx prisma migrate dev --name init

Now you can add the table to the database.

Connect local PostgreSQL to DBeaver

Start DBeaver and click the icon on the top left.

Select PostgreSQL.

Enter postgres in the Password of red circle.
This Database, Username, and Password are set in docker-compose.yml.

It is successful if there are no errors.

Then, you can make sure the tables of database.
It is successful if the post table is displayed as shown in the image.

Create sample Data

Create data directly from DBeaver using SQL.

Right click on the table name post and select Generate SQL then select the INSERT.

Then a modal like the image will open, so please copy the SQL inside.

Click the SQL icon in the top left to open the SQL script and paste the SQL you copied.

Add test text to the copied SQL and execute it using the Execute button on the left.

sql

INSERT INTO public.post
(id, "name", body)
VALUES(nextval('post_id_seq'::regclass), 'Henly', 'I am Henly, it is test post.');

Creating test data is now complete.

Display database data on browser

Let's display the created test data on the screen.

Please install the @prisma/client for client.

npm install @prisma/client

Please rewrite /app/routes/_index.tsx as below.

import { type LoaderFunction, json } from "@remix-run/node";
import { PrismaClient } from "@prisma/client";
import { useLoaderData } from "@remix-run/react";

export const loader: LoaderFunction = async () => {
  const prisma = new PrismaClient();
  const post = await prisma.post.findFirst();

  return json(post);
};

export default function Index() {
  const postData = useLoaderData<typeof loader>();

  return (
    <>
      <h1>My app</h1>
      <h2>{postData?.name ? postData.name : 'loading...'}</h2>
      <h2>{postData?.body ? postData.body : 'loading...'}</h2>
    </>
  );
}

Please start dev server with below command.

npm run dev

It is now displayed on the screen created data.

Deploy app to Fly.io

Now that the setup in the local environment is complete, it's time to deploy it to the Fly.io.

First, register with Fly.io and register your credit card.
Select the $0 plan.

Next, install flyctl to use fly's CLI on your local machine.

brew install flyctl

Let's deploy it!!

fly launch

The following question will be displayed, please select yes.

Do you want to tweak these settings before proceeding? => y

Then, the browser will open, so please configure the app settings.

Please select the lowest CPU and memory for your web server.

Please select development for PostgreSQL as well.

Once the browser settings are complete, the command line will start working again.
The DB information will be displayed during the process, so don't forget to write it down.

The deployment has completed so also connect to the DB with DBeaver same as local.

First, connect to DB by SSH and create new user.

fly postgres connect -a [YOUR_DB_APP_NAME]

Create new role(user).

CREATE ROLE dbeaver_user WITH PASSWORD 'newpassword';

Then, grant privileges to the created user.
This time, we want to edit the database directly from DBeaver, so we will grant SUPERUSER permission.

ALTER ROLE dbeaver_user SUPERUSER LOGIN;

Use the command below to display a list of DBs and check the DB name.

\l

Terminate the DB ssh connection.

exit

When operating from local DBeaver, you need to run a proxy in the terminal.

fly proxy 5432 -a [YOUR_DB_APP_NAME]

Create a new connection in DBeaver using the database name, username, and password from earlier.

Let's create test data from SQL same as local environment.

INSERT INTO public.post
(id, "name", body)
VALUES(nextval('post_id_seq'::regclass), 'Yuichi', 'This is production');

It was displayed successfully!🎉
That's it!

If you want to fix it and deploy it again, you can deploy it with the following command.

fly deploy

Thank you for reading this long article😊
Have a good Remix life!✨

I am looking for a job

As of July 2024, I am looking for a job.
My areas of expertise are React, TypeScript, Remix, Next, PHP, and WordPress.
I'm currently a student, so I'm looking for a part-time position where I can work up to 20 hours a week.
I'm looking for a full-time job starting next August.

My WordPress Template 2024 made from Vite and TypeScript

Yuichi Nabeshima — Sat, 20 Jul 2024 20:30:08 +0000

Hi there😊
I'm Yuichi, a CCTB student and a Frontend developer.

I created new WordPress template for practical work.
It is assumed that making WordPress site from scratch.
I will share the template and its idea.

【Repository】: https://github.com/YuichiNabeshima/my-wordpress-template

Things I want to do on this template

Do not use any JavaScript framework, keeping basic usage as WordPress.
Do not use UI framework for handling various design.
Each pages load CSS and JavaScript scripts as much as the page needs for reducing file size.
I want to use Vite for bundling.
I want to split JavaScript scripts as a file as each feature.

Directory structure

Main directories are these three.

public is put the static files like font or image.
src is put the codes needing build and compile, like CSS using post-css or TypeScript.
wp is put the production codes. When you deploy, you upload only this directory to production server. The assets of public and src will be output under the wp/assets/ after build command.

┣━ public ━ img/
┃        ┗━ fonts/
┃
┣━ src ━━━━ css/
┃        ┗━ ts/
┃
┣━ wp ━━━━━ assets/
┃        ┣━ index.php
┃        ┣━ front-page.php
┃        ┗━ ...

Local environment

It uses wp-env for the local environment.
It is very easy to set up and no configuration.
We can check own site to http://localhost:8888 on web browser.

Strategy of entry point

JS and CSS should be loaded as much as necessary for the page in order to reduce the file size as much as possible.
In other words, it is assumed that every page has its own JS and CSS.
Of course, if you can share files between pages, do so (like common.js)
Each file put under the entry_point directory will be output under /wp/assets/ with the file name unchanged after build.

After build ...

You need to add the arguments of get_header() and get_footer() for loading the each builded file.

<?php
  get_header(null, [
    'css' => 'top',
  ]);
?>

<?php
  get_footer(null, [
    'js' => 'top',
  ]);
?>

Developing

Since I am using Vite, I want to use Vite's extremely fast development server.
Therefore, I have devised tags that load CSS and JS.

/wp/header.php

<?php
  if( WP_DEBUG && IS_DEV ):
?>
  <link rel="stylesheet" href="http://localhost:5173/src/css/entry_point/<?=$css?>.css">
<?php
  else:
?>
  <link rel="stylesheet" href="<?=get_stylesheet_directory_uri()?>/assets/css/<?=$css?>.css">
<?php
  endif;

/wp/footer.php

<?php
  if( WP_DEBUG && IS_DEV ):
?>
  <script type="module" src="http://localhost:5173/@vite/client"></script>
  <script type="module" src="http://localhost:5173/src/ts/entry_point/<?=$js?>.ts"></script>
<?php
  else:
?>
  <script src="<?=get_stylesheet_directory_uri()?>/assets/js/<?=$js?>.js"></script>
<?php
  endif;

During developing, we can benefit from Vite's development server by referencing http://localhost:5137.
When I start the Vite development server, what I see in my browser is http://localhost:8888.
http://localhost:5173 shows nothing

WP_DEBUG variable

The WP_DEBUG variable in if statement is set to true in wp-env.json, so even if you accidentally deploy with IS_DEBUG set to true, it will not enter debug mode.

IS_DEBUG variable

The IS_DEBUG variable is a global variable that you manually set in functions.php.
The default is true, so the local environment refers to the Vite's development server.
If you want to check the built JS and CSS in the local environment, please set it to false.

Styling

CSS concept

The reason of CSS is difficult is because the scope is always global.
Therefore, I want to propose that you don't have to make CSS commonly, put the CSS codes for each pages.
When the number of common CSS increases, in many cases, you will spend a lot of time searching for a class of common style somewhere when you add new page.

CSS directory structure

┣━　CSS　┯━　common　━━━━━┳━　reset.css
┃ 　　　　　　　　┃　　　　　　　　　　　　　　　　　　　　　　　　　　┣━　base.css
┃　　　　　　　　　　┃　　　　　　　　　　　　　　　　　　　　　　　　　　┗━　variable.css
┃　　　　　　　　　　┃
┃　　　　　　　　　　┣━　entry_point　┳━　top.css
┃　　    ┃　　　　　　　　　　　　　　　　　　　　　　　　　　┗━　about.css
┃　　　　　　　　　　┣━　mixin　━━━━━━━━　media.css
┃　　　　　　　　　　┗━　page　━━━━━━━┳━　top.css
┃　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　　┗━　about.css

As mentioned above CSS creates a single file dedicated to each page.
The CSS files under the entry_point gather all the CSS codes like below.

@import '../mixin/media.css';

@import '../common/reset.css';
@import '../common/variable.css';
@import '../common/base.css';

@import '../page/top.css';

The main styles of the page are put in the CSS file under page.

There are some things you really want to commonly, such as common layouts, headings, and buttons.
In that case, please make an appropriate file under the mixin directory and import it to entry_point.

┣━　mixin　┯　button.css
┃       ┗　layout.css

/src/css/entry_point/top.css

@import '../mixin/media.css';
@import '../mixin/button.css'; // import here

@import '../common/reset.css';
@import '../common/variable.css';
@import '../common/base.css';

@import '../page/top.css';

/src/css/page/top.css

.btn {
  @mixin btn;
}

JS

I will explain how to add JS feature in this template.

JS directory structure

┣━　ts　┳━　entry_point/　━━　top.ts
┃　　　　　　　　┣━　modules/　━━━━━━　alert.ts
┃　　　　　　　　┗━　register_module.ts

How to add JS feature

First, add the data-module attribute to a HTML tag, which is the starting point of the event firing.
The value of data-module is assigned the function name which you want to add as JS feature(this will be explained later).

<button
  class="btn"
  data-module="alert"
>alert</button>

Next, create a ts file for the feature you want to add under /src/ts/modules/ and define the function in it, example is below.

/src/ts/modules/alert.ts

export function alert( el: HTMLElement ) {
  el.addEventListener('click', () => {
    alert('click button!');
  });
}

The argument of the function will be passed the DOM which you assigned the data-module attribute before, so you can use the DOM for making feature, like add event.

Finally, register the created function in the file under entry_point

/src/ts/entry_point/top.ts

import { registerModule } from '../register_module';
import { alert } from '../modules/alert';

registerModule({
  alert,
});

That's it! You can use JS feature you created.

Pass the value from html

If you want to pass variables from html, pass them in json format to the data-options attribute.
Anything other than json will result in an error.

/wp/front-page.php

  <button
    class="alert-btn"
    data-module="alert"
    data-options='{
      "alertText": "I am from earth."
    }'
  >
    Alert!
  </button>

/src/ts/modules/alert.ts

type Opts = {
  alertText: string;
}

export function alert( el: HTMLElement, opts: Opts ) {
  const msg = opts.alertText;
  el.addEventListener('click', () => {
    alert(msg);
  });
}

Responsive

If you want to only run the module when device is PC or Smart phone.
You can use data-only attribute, there are 2 options which pc or sp.

Display width

pc >= 768px

sp < 768px

  <button
    class="alert-btn"
    data-module="alert"
    data-options='{
      "alertText": "I am from earth."
    }'
    data-only="pc"
  >
    Alert PC only!
  </button>

When you want to put multiple modules on a tag.

  <button
    class="alert-btn"
    data-module="alert another-alert"
    data-options='{
      "alert": {
        "alertText": "message"
      },
      "another-alert": {
        "afterText": "after message"
      }
    }'
    data-only='{
      "alert": "pc",
      "another-alert": "sp"
    }'
  >
    Multiple module
  </button>

How was my new WordPress template? I would be happy if you could use it and give me feedback if you like!

I am looking for a job

As of July 2024, I am looking for a job.
My areas of expertise are React, TypeScript, Remix, Next, PHP, and WordPress.
I'm currently a student, so I'm looking for a job position which can be a project - based.
I'm looking for a full-time job starting next August.