René Kulik - Freelance Software Developer

Beyond the API: How I Structure the Backend Logic of My Applications

Tue, 22 Apr 2025 00:00:00 +0000

Introduction
Controllers: Keep Them Focused
My Preferred Controller Methods
Actions Over Services
Real Example: Blog System Routing
Conclusion

Introduction

In my previous blog post, I shared my approach to structuring REST APIs effectively, focusing on clarity, convention, and scalability. That post emphasized how to keep API surface areas predictable and maintainable. Now, I want to take you a layer deeper into what happens behind the API.

In this post, I will break down how I structure the backend logic that powers my APIs, drawing from 14+ years of experience building backend applications in Node.js and PHP. The goal? Keep things simple, explicit, and future-proof.

Controllers: Keep Them Focused

Taylor Otwell, the creator of Laravel, has a rule I fully embrace: controllers should stick to the 7 standard RESTful methods. If you need to handle more complex or domain-specific behavior, you do not expand the controller. You create a new one.

One of my Laravel ✨ best practices ✨ is only using the 7 "restful" methods in my controllers.

Controllers only have: index, show, create, store, edit, update, delete.

Think you need another method? You really need another controller. Built *all* of Vapor like this.
— Taylor Otwell (@taylorotwell) April 27, 2023

This philosophy aligns perfectly with a principle I have come to live by in object-oriented environments:

You can’t have too many classes.

It might feel like overkill at first, but clear separation of concerns pays dividends as your codebase grows. By using smaller, well-named classes, you make the system easier to reason about, test, and evolve.

My Preferred Controller Methods

When I am not using a framework like NestJS or Laravel, which often scaffold controllers for you, I still stick to a minimal set of controller methods. Here is what I use by default:

create
read
readAll
update
delete

These method names map closely to the intentions of a typical RESTful resource.

If my applications should also provide routes for create and edit views, I include two preparatory methods that do not mutate data but instead return the necessary data for the UI:

prepareCreate
prepareUpdate

These two methods make it clear when a controller is only preparing a form or UI versus actually performing a data-changing operation. This keeps responsibilities clean and intuitive, while maintaining a consistent verb-based naming style across all actions.

Actions Over Services

One pattern I have moved toward is using action classes instead of large service classes. Services tend to grow unchecked, morphing into god-objects that do way too much. Actions, on the other hand, are lean, purpose-driven, and easy to test.

Each controller method delegates to a single action class that handles the actual business logic. This makes responsibilities explicit and avoids bloated controllers or service layers.

Real Example: Blog System Routing

Let us revisit the blog system I used in my last post. Here is how I would structure the backend logic using my approach:

HTTP Route	Controller	Method	Action Class
GET /posts/create	PostsController	prepareCreate	PrepareCreatePostAction
POST /posts	PostsController	create	CreatePostAction
GET /posts	PostsController	readAll	ReadPostsAction
GET /posts/:id	PostsController	read	ReadPostAction
GET /posts/:id/edit	PostsController	prepareUpdate	PrepareUpdatePostAction
PATCH /posts/:id	PostsController	update	UpdatePostAction
PUT /posts/:id/title	PostTitleController	update	UpdatePostTitleAction
DELETE /posts/:id	PostsController	delete	DeletePostAction
POST /published-posts	PublishedPostsController	create	PublishPostAction
DELETE /published-posts/:id	PublishedPostsController	delete	UnpublishPostAction
POST /posts/:id/comments	PostCommentsController	create	CreatePostCommentAction
GET /posts/:id/comments	PostCommentsController	readAll	ReadPostCommentsAction
GET /comments/:id	CommentsController	read	ReadCommentAction
PATCH /comments/:id	CommentsController	update	UpdateCommentAction
DELETE /comments/:id	CommentsController	delete	DeleteCommentAction

Notice how:

Each action is named after exactly what it does.
Controllers remain lean and follow a consistent pattern.
Even sub-resources like comments of a post, the title of a post, and operations like publish/unpublish are given their own controllers.

This structure makes it easy to trace behavior, enforce boundaries, and introduce changes without fear of breaking unrelated parts of the app.

If you would like to see the blog system example in action, I have published the code on GitHub.

Conclusion

Backends grow. It is inevitable. But complexity does not have to be messy. By leaning into object-oriented principles, limiting controller scope, and favoring single-purpose action classes, you can build backends that are as robust and scalable as the APIs they serve.

If you liked this post, check out my previous one on designing REST APIs.

REST API Design: Best Practices and Lessons Learned

Wed, 09 Apr 2025 00:00:00 +0000

Introduction
HTTP Request Methods
URL Structure and Naming Conventions
- Posts
- Comments
Response Structure
Communication Between Backend and Frontend Teams
Conclusion

Introduction

With over 14 years of experience in designing REST APIs, I have learned quite a bit about what works and what does not. This blog post is a collection of those lessons, distilled into best practices that I have developed over time. It focuses exclusively on RESTful API design, not GraphQL or other paradigms. These are the bread and butter of solid REST API design and represent the fundamentals that every developer should know. Whether you are building APIs for internal applications or public consumption, these principles will help you create a clean, consistent, and maintainable API.

HTTP Request Methods

A well-designed API makes proper use of HTTP methods. Here is a breakdown of each method and how it should be used:

GET: Used to retrieve resources. GET requests are designed to be safe and idempotent. A successful GET request usually returns a 200 OK status code.
POST: Used to create new resources. This method is not idempotent, meaning multiple identical requests could create multiple resources. A successful POST request typically returns a 201 Created status code along with the newly created resource.
PUT: Used to fully replace a resource. This method expects the complete resource representation, and anything missing from the request might be deleted. Even if certain fields (like id) are not meant to be updated, it is still common practice to include the entire resource object in a PUT request, including those unchangeable fields. A successful PUT request returns a 201 Created status code if a new resource is created, and a 200 OK status code if an existing resource is updated, along with the created/updated resource in the response.
PATCH: Used for partial updates. Unlike PUT, PATCH allows updating only specific fields without sending the entire resource. A successful PATCH request should return a 200 OK status code along with the updated resource.
DELETE: Used to remove a resource. If the deletion is successful, the response should reflect that by returning a 204 No Content status code.

Methods that are designed to transport data, such as POST, PUT, and PATCH, should use the request body to send data instead of relying on query parameters. Query parameters are typically reserved for filtering or specifying resources in the URL, while the body is the proper place for submitting data, especially when dealing with complex or large payloads. Using the body ensures better organization, clarity, and adherence to HTTP semantics.

While GET technically supports a request body, this is not considered best practice. GET is designed to be a safe, idempotent method primarily used for retrieving resources. Including a body with a GET request is unconventional and can lead to confusion about the request’s intent. Additionally, GET requests are often cached, and including a body could break caching mechanisms, leading to inconsistent results or performance issues. For this reason, it is best to pass parameters via the URL (i.e., query parameters) in GET requests.

URL Structure and Naming Conventions

When designing URLs, follow conventions that enhance clarity and scalability. The following examples are based on a blog system. Here are a few practical tips to keep in mind:

Ensure each URL uniquely identifies a resource: A well-structured REST API uses URLs that clearly and uniquely reference a specific resource or collection. For example, GET /posts/1 should return to the post with ID 1, whereas GET /posts refers to the entire collection of posts. This improves clarity, consistency, and enables more predictable caching.
Reflect nested resources in the route: This makes the parent-child relationship explicit. For example, instead of using POST /comments, prefer POST /posts/:id/comments to make it clear that the comment belongs to a specific post.
Isolate properties that should be edited independently: If a certain property of a resource is commonly updated on its own, consider making it a sub-resource. For example, to update only the title of a post, use PUT /posts/:id/title. Since you are replacing the entire title, PUT is the appropriate HTTP method here.
Treat different states of a resource as separate resources: State transitions can be modeled with separate endpoints. For instance, POST /published-posts is used to publish a post. Although this is an update action and PATCH /posts/:id would also work, it is cleaner and more expressive to give this new state (a “published” post) its own resource and URL. To unpublish a post, use DELETE /published-posts/:id.
Use pluralized endpoints: Pluralized endpoints make sense because they represent collections of resources, ensuring consistency across the API.

Posts

POST /posts: Create a post
GET /posts: Retrieve all posts
GET /posts/:id: Retrieve a specific post by ID
PATCH /posts/:id: Update a specific post
PUT /posts/:id/title: Update the title of a post (Isolated property that can be edited independently)
DELETE /posts/:id: Delete a specific post
POST /published-posts: Publish a post (Different state is treated as a separate resource)
DELETE /published-posts/:id: Unpublish a post

Comments

POST /posts/:id/comments: Create a comment (This is a nested resource belonging to the post, so the URL reflects that relationship)
GET /posts/:id/comments: Retrieve all comments for a post
GET /comments/:id: Retrieve a specific comment
PATCH /comments/:id: Update a comment
DELETE /comments/:id: Delete a comment

Response Structure

Consistency in API responses makes integration easier for frontend developers. Here are some best practices for API responses:

This API’s response structure is based on the JSend specification, which promotes a consistent format for successful, failed, and error responses.
Every response includes a top-level status field indicating the outcome:
- "success" for successful requests, typically including a data object with the resource(s).
- "fail" for client-side input validation failures, with a data object describing the problems.
- "error" for unexpected server-side issues, including a human-readable message and optional code and data fields.
Always return the full resource representation, including null values.
- Even null values provide meaningful information. For example, a publishedAt field being null signals that a post has not been published, and a verifiedAt field being null indicates that a user has not verified their email yet.
Avoid redundant prefixes in property names. Instead of using postId, simply use id when inside a post resource.
Ensure that the data types in your API responses match their expected types, such as using numbers for numerical values and strings for text, to maintain consistency and avoid errors.
Wrap successful responses in a data object, as this allows easy extension with additional information, such as a meta object for pagination.
I prefer using camelCase for property names because it aligns with the way most of my application code is written. This consistency makes it easier to map data between backend and frontend without any transformation. It also improves readability and reduces friction during integration, especially in JavaScript-heavy environments.

Data Types

It is important to ensure that the types in your API responses match the expected data types. For example, if a value is a number in your system, it should be returned as a number in the response, not as a string. This helps maintain consistency and prevents type mismatches during integration.

For dates, always use the ISO 8601 format (YYYY-MM-DDTHH:MM:SSZ). This format is widely accepted and helps avoid confusion, as it clearly represents both the date and the time, along with time zone information.

In JavaScript, you can easily generate this ISO 8601 format with new Date().toISOString().

Using the correct types and formats ensures clarity, better interoperability, and a more predictable API.

Single Resource Response

This is an example of a response when retrieving a single resource. The resource is wrapped in a data object.

{
  "status": "success",
  "data": {
    "id": 1,
    "title": "First post",
    "content": "This is the content of the first post.",
    "createdAt": "2025-04-08T13:00:00Z",
    "updatedAt": null,
    "publishedAt": null
 }
}

Multiple Resources Response with Pagination

This is an example of a response when retrieving multiple resources. The resources are wrapped in a data array, and additional metadata, such as pagination information, is included under the meta object.

{
  "status": "success",
  "data": [
    {
      "id": 1,
      "title": "First post",
      "content": "This is the content of the first post.",
      "createdAt": "2025-04-08T13:00:00Z",
      "updatedAt": null,
      "publishedAt": null
    },
    {
      "id": 2,
      "title": "Second post",
      "content": "This is the content of the second post.",
      "createdAt": "2025-04-09T12:34:56Z",
      "updatedAt": null,
      "publishedAt": null
    }
  ],
  "meta": {
    "currentPage": 1,
    "perPage": 2,
    "totalPages": 5,
    "totalItems": 10
  }
}

Fail Response

This is an example of a response when the request fails due to invalid input. The response contains a status of "fail" and a data object with field-specific error messages.

{
  "status": "fail",
  "data": {
    "title": "Title is required."
  }
}

Error Response

This is an example of a response when an unexpected server error occurs. The response contains a status of "error" and a human-readable message explaining the problem.

{
  "status": "error",
  "message": "Internal server error. Please try again later."
}

Communication Between Backend and Frontend Teams

One of the biggest API design pitfalls happens when backend and frontend teams communicate in example requests and responses rather than schemas. Define clear JSON schemas that outline the exact structure of requests and responses. This eliminates ambiguity and ensures smooth collaboration.

Tools like Swagger can be extremely helpful in this regard. Swagger allows both backend and frontend teams to work from a common definition, providing an interactive documentation interface. It ensures that both teams are on the same page regarding the structure of the API and makes it easy to update documentation as the API evolves. Swagger even allows automatic generation of client libraries and server stubs, further simplifying the development process.

Conclusion

Designing a well-structured REST API requires attention to detail, adherence to best practices, and clear communication between teams. By following these principles, you can build APIs that are intuitive, maintainable, and easy to work with. Whether you are a seasoned developer or just starting, these guidelines will help you create APIs that stand the test of time.

Building a loading button in React with TypeScript, shadcn/ui and Tailwind CSS v2

Mon, 13 Jan 2025 00:00:00 +0000

Introduction
Understanding the problem
The plan
The code
Key concepts
Advantages of this approach
Tailwind CSS breakdown
Comparison with the previous approach
Conclusion

Introduction

In a previous post, I demonstrated how to build a loading button in React using useLayoutEffect to calculate and preserve the button’s width while displaying a loading spinner. While that approach works well, it relies on JavaScript for layout calculations. In this post, I’ll show you an alternative technique using pure CSS for the loading indicator, leveraging Tailwind CSS’s group and group-data utilities to style elements based on the parent’s state. This solution was inspired by a post from jordi on X.

Understanding the problem

When building a loading button, one common issue is the button’s content changing width when the loading indicator is displayed. In the first version, we solved this by dynamically calculating the button’s width with JavaScript. However, this approach can be avoided by creatively using CSS opacity and Tailwind’s state-based utilities.

The plan

In this version, we’ll:

Use Tailwind CSS classes to style the button and loading indicator.
Use the data-loading attribute on the button to toggle styles.
Ensure smooth transitions between the button’s normal state and its loading state without any JavaScript-based width calculations.

The code

import { LoaderCircleIcon } from 'lucide-react';
import { FC } from 'react';
import { Button, ButtonProps } from '@/components/ui/button';
import { cn } from '@/utils/shadcn';

interface LoadingButtonProps extends ButtonProps {
  isLoading?: boolean;
}

export const LoadingButton: FC<LoadingButtonProps> = (props) => {
  const {
    isLoading = false,
    disabled,
    className,
    children,
    ...restOfProps
  } = props;

  return (
    <Button
      {...restOfProps}
      data-loading={isLoading}
      className={cn(className, 'group')}
      disabled={disabled ?? isLoading}>
      <LoaderCircleIcon className="absolute animate-spin opacity-0 group-data-[loading=true]:opacity-100" />
      <span className="flex size-full items-center justify-center group-data-[loading=true]:opacity-0">
        {children}
      </span>
    </Button>
  );
};

Key concepts

The data-loading attribute

Instead of using JavaScript to manipulate styles directly, we’re adding a data-loading attribute to the button. This attribute acts as a hook for styling elements inside the button.

Tailwind CSS group utilities

We use the group class on the button and the group-data-[loading=true] utility to style child elements based on the button’s data-loading state. For example:

The loading spinner (a <LoaderCircleIcon> component from Lucide) is normally hidden (opacity-0) and becomes visible (opacity-100) when the data-loading attribute is true.
The button’s content (<span>) is visible by default but hidden (opacity-0) in the loading state.

Absolute positioning

The loading spinner is absolutely positioned within the button, ensuring it remains centered regardless of the button’s content.

Advantages of this approach

No JavaScript layout calculations: By using CSS for state-based styling, we avoid unnecessary JavaScript logic.
Simpler state management: The isLoading prop directly maps to the data-loading attribute, making it easier to manage.
Improved performance: CSS transitions are typically more performant than JavaScript-based DOM manipulations.

Tailwind CSS breakdown

Here’s a breakdown of the key Tailwind classes used:

group: Enables state-based styling for child elements.
group-data-[loading=true]: Targets elements when the data-loading attribute is set to true.
absolute: Positions the spinner in the center of the button.
animate-spin: Adds a spinning animation to the loading icon.
opacity-0 and opacity-100: Toggles visibility of elements.

Comparison with the previous approach

Feature	Previous version	Current version
Width management	JavaScript (`useLayoutEffect`)	Pure CSS with opacity
Styling	Inline and Tailwind CSS	Tailwind CSS group utilities
Dependencies	Required DOM measurements	No additional dependencies

Conclusion

This CSS-based approach simplifies the implementation of a loading button, avoiding JavaScript-based layout calculations while leveraging the power of Tailwind CSS. By using group and group-data, we achieve a clean and maintainable solution.

Try this technique in your next project and see how it compares to the JavaScript-based approach!

Solving 404 errors with client-side routing in React applications on Netlify

Thu, 19 Sep 2024 00:00:00 +0000

Introduction
The problem: 404 errors on page reload
Why this happens in client-side routing
The solution: Using the netlify.toml file
- How the redirect rule works
Conclusion

Introduction

Deploying a React application is usually straightforward, especially when using modern platforms like Netlify. However, there are common routing issues you might face after deployment, especially when using client-side routers such as TanStack Router, React Router, or others.

One such issue is navigating to a subpage and then refreshing the browser, only to be greeted by a 404 page. If you’re experiencing this issue, you’re not alone! In this blog post, I’ll explain how you can solved this issue when deploying your site on Netlify.

The problem: 404 errors on page reload

If you’re working with a Single Page Application (SPA) using client-side routing, like React paired with TanStack Router, you’ll notice that everything works perfectly during local development. You can navigate to different pages without encountering any issues. However, once deployed to Netlify, a strange problem might occur:

When you navigate to a page (e.g., /about) and reload the page, Netlify serves its default 404 error page:

This can be frustrating, especially when the routes work just fine while using internal links to navigate between pages.

Why this happens in client-side routing

This issue arises because of how SPAs handle routing. In an SPA, routes are managed on the client-side (in your browser) rather than on the server. When you navigate to /about, for example, the browser doesn’t request /about from the server. Instead, your React application intercepts the request and dynamically renders the appropriate component for that route.

But when you refresh the page or directly visit a route like /about, the browser makes a direct request to the server for /about. Without the proper configuration, Netlify doesn’t know how to serve that route and instead throws a 404 error because it expects that route to exist on the server (but it doesn’t, since it’s a client-side route).

The solution: Using the netlify.toml file

The solution is simple: we need to tell Netlify to serve our index.html file for every route. This ensures that Netlify serves our application no matter what route is requested, allowing the client-side router to take over and display the correct content.

Enter the netlify.toml file

To fix this issue, you can create a configuration file called netlify.toml at the root of your project. This file is used to configure various settings for your Netlify site, including redirect rules.

Here’s the content of the netlify.toml file to solve this problem:

[[redirects]]
  from = "/*"
  to = "/index.html"
  status = 200

How the redirect rule works

[[redirects]]: This defines a new redirect rule.
from = "/*": This wildcard means “catch all routes,” so any URL path (e.g., /about, /contact, /dashboard) will match this rule.
to = "/index.html": This tells Netlify to serve the index.html file, regardless of the route.
status = 200: This indicates that the request should be treated as successful, not a redirect.

With this in place, when you reload a page like /about, Netlify will serve the index.html file, and your application (and your client-side router of choice) will take care of loading the correct page dynamically.

Conclusion

Handling routing in a Single Page Application deployed on Netlify can be tricky, especially if you’re using client-side routing libraries. The key is to configure Netlify properly to serve the index.html file for all routes, allowing your React applicaton to manage the routing internally.

By adding a netlify.toml file with a redirect rule, you can ensure that your routing works as expected even when users refresh a page or directly visit a specific route.

Building a loading button in React with TypeScript, shadcn/ui and Tailwind CSS

Wed, 18 Sep 2024 00:00:00 +0000

Introduction
Understanding the problem
The LoadingButton component
Why use useLayoutEffect?
Conclusion

Introduction

When building modern user interfaces, it’s common to implement buttons with loading states to indicate that an operation is in progress. A typical approach is to replace the button’s content with a spinner. However, this substitution can cause the button to shrink or change size, resulting in a jumpy or uneven user experience. To address this, it’s important to ensure that the button maintains its size during loading.

In this blog post, I’ll walk you through building a LoadingButton component in React with TypeScript, using shadcn/ui for the button and Tailwind CSS for styling. We’ll ensure that the button width remains consistent even when displaying a loading spinner.

Understanding the problem

Imagine a button that normally displays text like “Submit”, but when a loading action begins, the text is replaced with a loading spinner. If the spinner is smaller than the text, the button will shrink when the spinner is shown. This size change can be visually disruptive and create a jarring user experience.

To address this, we need to capture the button’s width before the loading starts and apply that width during the loading state. This approach prevents any visual shrinking and maintains a consistent user experience.

The LoadingButton component

Let’s start by looking at the complete implementation of the LoadingButton component:

import { LoaderCircleIcon } from 'lucide-react';
import { FC, useRef, useState, useLayoutEffect } from 'react';
import { Button, ButtonProps } from '@/components/ui/button';

interface LoadingButtonProps extends ButtonProps {
  isLoading?: boolean;
}

export const LoadingButton: FC<LoadingButtonProps> = (props) => {
  const { isLoading, disabled, style, children, ...restOfProps } = props;
  const [buttonWidth, setButtonWidth] = useState<number | undefined>(undefined);
  const buttonRef = useRef<HTMLButtonElement>(null);
  const buttonWidthStyle =
    isLoading && buttonWidth ? { minWidth: buttonWidth } : undefined;

  useLayoutEffect(() => {
    if (buttonRef.current) {
      setButtonWidth(buttonRef.current.offsetWidth);
    }
  }, []);

  return (
    <Button
      {...restOfProps}
      ref={buttonRef}
      style={{ ...style, ...buttonWidthStyle }}
      disabled={disabled ?? isLoading}>
      {isLoading ? <LoaderCircleIcon className="animate-spin" /> : children}
    </Button>
  );
};

Component props

The LoadingButton accepts a few key props:

isLoading: A boolean to indicate whether the button is in a loading state.
disabled: Whether the button is disabled. If isLoading is true, the button will automatically be disabled to prevent multiple submissions.
style: Custom styles to be applied to the button. These styles are merged with the buttonWidthStyle to ensure the button retains its width.
children: The normal content of the button, such as text like “Submit”.

The LoadingButtonProps interface extends the button props from shadcn/ui so the component can be used just like any standard button, but with the added loading functionality.

Managing button width with useState and useRef

We initialize two hooks:

buttonWidth: A state variable (useState) that stores the current width of the button. This width will later be used to prevent the button from shrinking when loading.
buttonRef: A reference to the button element (useRef), which allows us to access the button’s DOM properties.

const [buttonWidth, setButtonWidth] = useState<number | undefined>(undefined);
const buttonRef = useRef<HTMLButtonElement>(null);

Using useLayoutEffect to capture button width

useLayoutEffect is similar to useEffect, but it fires synchronously after all DOM mutations. This is important because it allows us to capture the button’s size before any visual changes (like switching to the spinner) are rendered on the screen.

useLayoutEffect(() => {
  if (buttonRef.current) {
    setButtonWidth(buttonRef.current.offsetWidth);
  }
}, []);

The useLayoutEffect runs only once (due to the empty dependency array []), setting the buttonWidth state to the button’s offsetWidth — the full width of the button including padding and borders.

Applying the captured width

When the isLoading prop is true, the button content changes to a spinner. To prevent the button from shrinking, we conditionally apply a style to the button that sets its minWidth to the previously captured buttonWidth.

When the isLoading prop is true, the button content changes to a spinner. To prevent the button from shrinking, we apply a style that sets its minWidth to the previously captured buttonWidth.

const buttonWidthStyle = isLoading && buttonWidth ? { minWidth: buttonWidth } : undefined;

This ensures that the button retains its original width, no matter how small the spinner is. The buttonWidthStyle is merged with any custom style passed as a prop when rendering the button.

Rendering the button

Finally, we render the button from shadcn/ui with either the spinner or its normal content depending on the isLoading state:

return (
  <Button
    {...restOfProps}
    ref={buttonRef}
    style={{ ...style, ...buttonWidthStyle }}
    disabled={disabled ?? isLoading}>
    {isLoading ? <LoaderCircleIcon className="animate-spin" /> : children}
  </Button>
);

The LoaderCircleIcon from the lucide-react library displays a loading spinner with an animate-spin class from Tailwind CSS to add the spinning animation. The disabled prop is set to true when the button is loading to prevent user interaction, unless it is explicitly specified otherwise.

Why use useLayoutEffect?

You might wonder why we use useLayoutEffect instead of useEffect. The key difference is that useEffect runs after the browser has painted the screen, which could lead to a visible “flash” where the button size changes before the effect runs.

useLayoutEffect, on the other hand, runs synchronously before the browser paints, ensuring that the size is set before the user sees anything. This guarantees a smooth user experience without any visual jumps or glitches.

Conclusion

The LoadingButton component is an effective solution for handling loading states while maintaining a consistent button size. By leveraging React’s useRef, useState, and useLayoutEffect, and using shadcn/ui for the button component along with Tailwind CSS for styling, we can prevent UI jumps and ensure a seamless experience for users.

This pattern is particularly useful for managing button states (such as loading, success, or failure) without causing visual disruption.

How to disable new user sign-ups in your Supabase project

Thu, 29 Aug 2024 00:00:00 +0000

Introduction
Access the supabase dashboard
Navigate to the authentication settings
Disable new user sign-ups
Save changes
Test the configuration
Re-enable sign-ups (when needed)
Conclusion

Introduction

Sometimes you might want to prevent new user sign-ups for your Supabase project. This could be during a beta test, maintenance period, or simply to control user flow. Disabling new user sign-ups is a straightforward process and can be done directly from the Supabase dashboard. Here is a step-by-step guide to help you through it.

Access the Supabase dashboard

First, log in to your Supabase account. Once logged in, you will see the dashboard with a list of your projects. Select the project where you want to manage sign-ups.

Navigate to the authentication settings

On the project page, locate the “Project Settings” option in the left sidebar. Clicking it to open the project settings page, then find and click “Authentication” in the menu on the left.

Disable new user sign-ups

In the “User Signups” section, look for the toggle labeled “Allow new users to sign up”. Switch off the toggle.

Save changes

After disabling the sign-ups, make sure to apply the changes by clicking the “Save” button. A toast message saying “Successfully updated settings” will appear to confirm that the settings have been updated.

Test the configuration

Test the sign-up process to confirm that new users are indeed unable to register. This step can help ensure that everything is functioning as expected.

Re-enable sign-ups (when needed)

When you are ready to re-enable new users to sign up, simply switch the toggle back on and save the settings.

Conclusion

Disabling new user sign-ups in Supabase is a simple yet powerful feature for managing your project’s user flow. By following the steps in this blog post, you can easily control who has access to your application, whether it is for testing, maintenance, or other reasons.

Avoid re-render loops in React: The importance of wrapping custom Hook functions with useCallback

Mon, 19 Aug 2024 00:00:00 +0000

Introduction
The problem: Re-render loops without useCallback
- Example without useCallback
- Explanation
The solution: Prevent re-render loops with useCallback
- Example with useCallback
- Explanation
Conclusion

Introduction

In React, custom Hooks are a powerful way to encapsulate logic and make it reusable throughout different components. However, if not used carefully, custom Hooks can cause unintended re-render loops — situations where components keep re-rendering unnecessarily, leading to performance degradation or even crashing the application. In this blog post, we’ll explore how this problem can occur, particularly in custom Hooks, and how useCallback can prevent it.

The problem: Re-render loops without useCallback

Re-render loops occur when components keep re-rendering unnecessarily because one ore more dependencies are changing on every render. Common causes of such issues include passing functions down as props or using them as dependencies in useEffect, useMemo, or similar Hooks. In React, whenever a component re-renders, functions inside the component are re-created. If these functions are used as dependencies in other hooks (e.g. useEffect), it can initiate a re-render loop. This can result in a stalled and unusable application.

Example without useCallback

As mentioned before, custom Hooks in particular can cause this problem. Here is an example where a re-render loop occurs because the log function, returned from useLogger, is not wrapped in useCallback:

import { useEffect, useState } from 'react';

const useLogger = () => {
  const [logCount, setLogCount] = useState(0);

  const log = () => {
    console.log('Logging...');
    setLogCount(logCount => logCount + 1);
  };

  return [logCount, log];
}

const App = () => {
  const [count, setCount] = useState(0);
  const [logCount, log] = useLogger();

  useEffect(() => {
    if (count > 5) {
      log();
    }
  }, [count, log])

  return (
    <div>
      <button onClick={() => setCount(count => count + 1)}>
        Increment (count is {count})
      </button>
      <div>{logCount} logs generated</div>
    </div>
  )
}

export default App

Explanation

In the example above, we have a custom hook useLogger that returns:

A logCount state, indicating how many logs were produced in total
A log function that logs to the browser console

The App is a simple component demonstrating the use of the useLogger Hook. It maintains a count state that increments each time a button is clicked. When count increases, the useEffect executes and checks if count is greater than 5. If this is the case, the log function is called. The total number of logs generated is also displayed.

Here is the problem: The log function gets re-created every time App re-renders. As the useEffect depends on log, this triggers the effect on every render. If count is greater than 5, this creates a loop where the component continually re-renders, causing unnecessary execution of the effect and potentially leading to performance issues. The following warning is displayed in the browser console:

Warning: Maximum update depth exceeded. This can happen when a component calls setState inside useEffect, but useEffect either doesn't have a dependency array, or one of the dependencies changes on every render.

The solution: Prevent re-render loops with useCallback

To solve this issue, we can use the useCallback Hook. useCallback allows us to memoize a function so that it only changes when its dependencies change. This prevents the creation on every render and thus stops the loop.

Example with useCallback

Here is the adjusted example with useCallback:

import { useCallback, useEffect, useState } from 'react';

const useLogger = () => {
  const [logCount, setLogCount] = useState(0);

  const log = useCallback(() => {
    console.log('Logging...');
    setLogCount(logCount => logCount + 1);
  }, []);

  return [logCount, log];
}

const App = () => {
  const [count, setCount] = useState(0);
  const [logCount, log] = useLogger();

  useEffect(() => {
    if (count > 5) {
      log();
    }
  }, [count, log])

  return (
    <div>
      <button onClick={() => setCount(count => count + 1)}>
        Increment (count is {count})
      </button>
      <div>{logCount} logs generated</div>
    </div>
  )
}

export default App

Explanation

The log function is now wrapped with useCallback, and we have provided an empty dependency array. Therefore, the function will only be created once when the component first renders.

Conclusion

Re-render loops can be a subtle yet significant problem in React applications, particularly when working with custom Hooks. Not properly memoizing functions with useCallback can cause your components to re-render more often than needed, leading to performance issues or even application crashes. The solution is to wrap your custom Hook functions in useCallback to ensure they are only re-created when necessary. Keep this in mind the next time you are writing custom Hooks to keep your components running smoothly.

Enhancing PHP code quality: Integrating php-cs-fixer with GitHub Actions

Tue, 06 Aug 2024 00:00:00 +0000

Introduction
Set up the GitHub Actions workflow
Configure the workflow file
Checkout the repository
Set up the PHP environment
Run the linting
Complete workflow file
Conclusion

Introduction

A high quality and consistency of your code is crucial to ensure a robust and maintainable codebase. An efficient way to achieve this is code linting, which helps identifying/fixing code standard violations and standardizes the formatting across multiple developers. For PHP projects, php-cs-fixer is a powerful tool that not only checks the code but also automatically fixes it according to predefined coding standards. By integrating php-cs-fixer with GitHub Actions, we can automate the linting process, ensuring that every pull request adheres to our rules before being merged. In this blog post, I am going to describe how to set up the GitHub Actions worklow to automatically lint your PHP application.

Set up the GitHub Actions workflow

The following steps are necessary to run automatic workflows on GitHub. The obvious one is, that your repository has to be on GitHub. Make sure your repository contains a .github/workflows directory, as YAML files in this directory will be considered as potential workflows for GitHub. Create a lint.yml file in this directory. Below, I will focus on the contents of this file.

Configure the workflow file

Start the file by naming the workflow:

name: Lint

Next, specify the events that trigger the workflow. In our case, we want to lint our application on each pull request to develop and release/** branches:

on:
  pull_request:
    branches:
      - develop
      - "release/**"

Afterwards, set up the jobs that are part of the workflow. As we just want to run the linting, there is only one lint-applications job. This job uses the latest stable version of the Ubuntu operating system (ubuntu-latest) as a virtual environment:

jobs:
  lint-application:
    name: Lint application
    runs-on: ubuntu-latest

Checkout the repository

The job itself contains multiple steps. The first step checks out the repository, so the workflow can access it:

steps:
  - name: Checkout repository
    uses: actions/checkout@v4

Set up the PHP environment

As the next step, use the shivammathur/setup-php@v2 action to set up PHP and install php-cs-fixer:

- name: Set up PHP
  uses: shivammathur/setup-php@v2
  with:
    php-version: "8.1"
    tools: php-cs-fixer

Run the linting

To perform the actual linting, add a step to run php-cs-fixer. By providing the --dry-run flag, this will just identify code standard violations without fixing them. --config allows the code to be validated against a custom configuration file (php-cs-fixer.php) with custom code rules. If you want to know more about this configuration and available rules, check out the official documentation:

- name: Run linting
  run: php-cs-fixer fix --dry-run --config=./.php-cs-fixer.php

Complete workflow file

By combining the snippets listed above, you get the complete workflow file:

name: Lint
on:
  pull_request:
    branches:
      - develop
      - "release/**"
jobs:
  lint-application:
    name: Lint application
    runs-on: ubuntu-latest
    steps:
      - name: Checkout repository
        uses: actions/checkout@v4
      - name: Set up PHP
        uses: shivammathur/setup-php@v2
        with:
          php-version: "8.1"
          tools: php-cs-fixer
      - name: Run linting
        run: php-cs-fixer fix --dry-run --config=./.php-cs-fixer.php

Conclusion

Integrating linting tools, such as php-cs-fixer, with GitHub Actions, can significantly improve your codebase to be more robust and maintainable. If you do not have an automatic linting process in place yet, this blog post will help you set up a workflow on GitHub.

Unlock the power of Vim in Visual Studio Code

Mon, 05 Aug 2024 00:00:00 +0000

Introduction
Extension
General settings
Keybindings
Conclusion

Introduction

Visual Studio Code is a popular code editor and my go-to tool for daily programming tasks. In addition to the standard keybindings, I am also using the Vim extension to use its commands. In this blog post, I will share my Visual Studio Code settings including Vim specific adjustments. Whether you are a seasoned Vim user or just starting out, this blog post will help you configure your Visual Studio Code setup to leverage the best of both worlds. Note that I will not cover standard Vim commands. Instead, my focus will be on the specific configurations I use to integrate Vim functionalities.

Extension

The Visual Studio Marketplace offers a wide range of extensions to enhance your editor’s functionalities and experience. Vim is one of them and a must-have for integrating Vim keybindings and commands within Visual Studio Code. The extension can be installed from the extensions sidebar in Visual Studio Code or by following the instructions from the marketplace page.

General settings

To get the most out of the Vim extension, I adjusted a few key settings. I set the spacebar as my vim.leader, which acts as a prefix key to trigger custom commands. Another useful setting is vim.useSystemClipboard, which enables clipboard integration between Visual Studio Code and your system. This means you can easily copy and paste text between the editor and other applications. To configure these settings, open the settings.json file and add the following:

{
  "vim.leader": "<space>",
  "vim.useSystemClipboard": true
}

Keybindings

Customized keybindings are essential to tailor Visual Studio Code to your exact needs. By defining your own keybindings, you can enhance productivity and ensure that the most frequently used commands are easily accessible. In this section, I will share the specific keybindings I have introduced for the different Vim modes. The following configurations should be added to the settings.json file.

Normal mode

The following keybindings are configured for the normal mode:

Comment out the current line or a selection of lines
Uncomment the current line or a selection of lines
Focus the group on the right when using multiple groups splitted horizontally
Focus the group on the left when using multiple groups splitted horizontally
Focus the group below when using multiple groups splitted vertically
Focus the group above when using multiple groups splitted vertically
Split the editor vertically
Split the editor horizontally
Close the active editor
Close all other editors except the active one
Jump to the next editor on the right
Jump to the previous editor on the left
Show/hide the sidebar
Undo the latest change
Redo the latest change

Comment out the current line or a selection of lines

{
  "before": [
    "g",
    "c",
    "c"
  ],
  "commands": [
    "editor.action.addCommentLine"
  ]
}

Uncomment the current line or a selection of lines

{
  "before": [
    "g",
    "c",
    "u"
  ],
  "commands": [
    "editor.action.removeCommentLine"
  ]
}

Focus the group on the right when using multiple groups splitted horizontally

{
  "before": [
    "<C-l>"
  ],
  "commands": [
    "workbench.action.focusRightGroup"
  ]
}

Focus the group on the left when using multiple groups splitted horizontally

{
  "before": [
    "<C-h>"
  ],
  "commands": [
    "workbench.action.focusLeftGroup"
  ]
}

Focus the group below when using multiple groups splitted vertically

{
  "before": [
    "<C-j>"
  ],
  "commands": [
    "workbench.action.focusBelowGroup"
  ]
}

Focus the group above when using multiple groups splitted vertically

 {
  "before": [
    "<C-k>"
  ],
  "commands": [
    "workbench.action.focusAboveGroup"
  ]
}

Split the editor vertically

 {
  "before": [
    "<leader>",
    "-"
  ],
  "commands": [
    "workbench.action.splitEditorDown"
  ]
}

Split the editor horizontally

 {
  "before": [
    "<leader>",
    "|"
  ],
  "commands": [
    "workbench.action.splitEditorRight"
  ]
}

Close the active editor

 {
  "before": [
    "<leader>",
    "b",
    "c"
  ],
  "commands": [
    "workbench.action.closeActiveEditor"
  ]
}

Close all other editors except the active one

 {
  "before": [
    "<leader>",
    "b",
    "C"
  ],
  "commands": [
    "workbench.action.closeOtherEditors"
  ]
}

Jump to the next editor on the right

 {
  "before": [
    "<tab>"
  ],
  "commands": [
    "workbench.action.nextEditor"
  ]
}

Jump to the previous editor on the left

{
  "before": [
    "<S-tab>"
  ],
  "commands": [
    "workbench.action.previousEditor"
  ]
}

{
  "before": [
    "<C-n>"
  ],
  "commands": [
    "workbench.action.toggleSidebarVisibility",
  ]
}

Undo the latest change

 {
  "before": [
    "u"
  ],
  "after": [],
  "commands": [
    {
      "command": "undo",
      "args": []
    }
  ]
}

Redo the latest change

 {
  "before": [
    "<C-r>"
  ],
  "after": [],
  "commands": [
    {
      "command": "redo",
      "args": []
    }
  ]
}

Visual mode

The following keybindings are configured for the visual mode:

Comment out the current line or a selection of lines
Uncomment the current line or a selection of lines
Move the selected text to the next tab stop on the right
Move the selected text to the previous tab stop on the left

Comment out the current line or a selection of lines

{
  "before": [
    "g",
    "c",
    "c"
  ],
  "commands": [
    "editor.action.addCommentLine"
  ]
}

Uncomment the current line or a selection of lines

 {
  "before": [
    "g",
    "c",
    "u"
  ],
  "commands": [
    "editor.action.removeCommentLine"
  ]
}

Move the selected text to the next tab stop on the right

{
  "before": [
    ">"
  ],
  "after": [
    ">",
    "g",
    "v"
  ]
}

Move the selected text to the previous tab stop on the left

 {
  "before": [
    "<"
  ],
  "after": [
    "<",
    "g",
    "v"
  ]
}

Other

The following keybindings are part of the general keybindings.json. They were configured with Vim in mind, but are not limited to it:

Move the active editor to the group on the left
Move the active editor to the group below
Move the active editor to the group above
Move the active editor to the group on the right

Move the active editor to the group on the left

{
  "key": "ctrl+shift+h",
  "command": "workbench.action.moveEditorToLeftGroup"
}

Move the active editor to the group below

{
  "key": "ctrl+shift+j",
  "command": "workbench.action.moveEditorToBelowGroup"
}

Move the active editor to the group above

{
  "key": "ctrl+shift+k",
  "command": "workbench.action.moveEditorToAboveGroup"
}

Move the active editor to the group on the right

{
  "key": "ctrl+shift+l",
  "command": "workbench.action.moveEditorToRightGroup"
}

Conclusion

Integrating Vim into Visual Studio Code can significantly enhance your coding workflow. By customizing you settings and keybindings, you can tailor your editor to your specific needs. The adjustments shared in this blog post are designed to help you steamline your workflow and get the most out of Visual Studio Code. Experiment with these settings to find what works best for you.

Choosing the right type: Unraveling the difference between JSX.Element and React.FC in React components

Sun, 28 Jan 2024 00:00:00 +0000

Introduction
JSX.Element
React.FC
Conclusion

Introduction

I really like explicit return types as you see what will be the result of a function at the first glance. That is why, when I work with TypeScript, I enforce return types by using the "@typescript-eslint/explicit-function-return-type": "error" rule from @typescript-eslint/eslint-plugin in my ESLint configuration. With that ESLint complains when the return type is not explicitly set:

const foo = () => { // Missing return type on function.eslint@typescript-eslint/explicit-function-return-type
  return 'bar';
}

Defining general types is straight forward, but when it comes to React there are two potential types you can use for components, JSX.Element and React.FC. In this blog post I am going to explain both types, talks about their pros and cons, and tell you which one I am using.

JSX.Element

JSX.Element defines a representation of a DOM element. In the following example the returned element is a div:

const Example = (): JSX.Element => {
  return <div>Hello, world!</div>;
}

Using JSX.Element as the type for React components works in most use-cases, but sometimes components should also be able return null or a simple string. As JSX.Element does represents those types there will be an error:

const Example = (): JSX.Element => {
  return null; // Type 'null' is not assignable to type 'Element'.
}

To make the code work the return type has to be extended:

const Example = (): JSX.Element | null => {
  return null;
}

React.FC

React.FC on the other hand defines a functional component that returns a JSX element. It is also a generic that can be used to specify component props:

const Example: React.FC<{ name: string }> = (props) => {
  return <div>Hello, {props.name}!</div>;
}

Compared to JSX.Element also null and string are represented:

const Example: React.FC = () => {
  return null;
}

In former React versions React.FC was avoided as it opened up components with an implicit children prop. Since React 18 this is not the case anymore.

Conclusion

In this blog post I described JSX.ELement and React.FC as types for React components and outlined their pros and cons. Personally I use React.FC over JSX.Element because it does not limit the return type to DOM element representations. Furthermore its generic functionality can be used to define props.