DEV Community: Jose Coego

TECHNICAL DEBT: BE REALISTIC!! YOU CAN NOT AVOID IT.

Jose Coego — Thu, 09 Jan 2025 17:58:49 +0000

Technical debt itself isn’t inherently bad. It’s a natural part of the development process, especially when deadlines are tight or when the system is evolving rapidly. However, the real problem arises when technical debt is ignored, neglected, or mishandled. If left unmanaged, it accumulates over time and can lead to significant problems that affect the project's long-term health.

Why Does Technical Debt Arise?

1. Deadlines

Every project has deadlines, and more often than not, they are tight. To meet these deadlines, developers are often forced to prioritize speed over quality. This typically means taking shortcuts and skipping best practices, leading to the accumulation of technical debt. While this may be necessary in some cases, it can have long-term consequences if not managed properly.

2. Evolving Knowledge Over Time

When you start working on a new feature or project, your understanding of the problem is limited to the initial requirements. As the project progresses, you may uncover new insights or encounter unexpected challenges that were not part of the original plan. As systems and features evolve, new complexities emerge, and adapting the code to these changes can create technical debt if the code isn't refactored to accommodate the new needs.

3. Developer Expertise

Technical debt doesn’t always stem from a lack of experience, and even senior developers can contribute to it. When faced with unfamiliar challenges or technologies, even skilled developers may resort to quick, imperfect solutions to make progress. While experience certainly helps reduce technical debt by promoting better practices, the complexity of modern systems means that technical debt is often unavoidable, regardless of skill level.

4. Changing Requirements

As projects develop, the original scope often changes. New requirements are added, old ones are modified, or priorities shift, which can lead to rushed changes in the code. These changes might not align with the architecture or best practices, creating technical debt. Managing changing requirements carefully and allowing time for proper adjustments can help minimize this.

5. Lack of Proper Documentation or Knowledge Sharing

Sometimes, technical debt arises not only from writing imperfect code but also from a lack of proper documentation or knowledge transfer within the team. If features or systems are developed without clear documentation or if knowledge is siloed, future developers may struggle to understand the code, leading them to make quick fixes that add to the debt.

6. Legacy Systems or Third-Party Dependencies

In many cases, technical debt accumulates because teams work with legacy systems or third-party libraries that are difficult to modify or upgrade. These systems may have been designed with outdated technology or poor architectural decisions, and the cost of refactoring them can seem too high compared to just adding quick fixes. Over time, this contributes to technical debt.

Why Is It Essential to Address Technical Debt?

1. It Can Cause Slower Development in the Future

As the debt piles up, it can make future development more difficult. New developers may struggle to understand the codebase, and even experienced developers may find it hard to implement new features due to the complexity of the existing code.

2. It Can Impact Performance and Stability

Technical debt can also result in performance issues or bugs that become harder to fix as the system grows. What might have been a small issue can snowball into a major problem, affecting both the user experience and the stability of the application.

3. It Can Increase Costs Over Time

Initially, taking shortcuts may seem like a good idea to meet deadlines, but over time, the cost of managing technical debt increases. Regular maintenance, troubleshooting, and the need for more complex updates can drain resources and delay progress.

Technical debt is inevitable but manageable. Recognizing its causes and consequences can help teams address it proactively, ensuring long-term project health and stability.

For any questions, feel free to contact me on personal website or in X

Setting up Jest and React Testing Library with Webpack

Jose Coego — Sat, 04 Jan 2025 09:59:40 +0000

Although Webpack might not be your preferred bundler, with tools like Vite gaining significant community support, you may still encounter projects where configuring Jest and React Testing Library with Webpack is necessary.

To configure Jest and React Testing Library in this application, follow these steps:

1. Install Jest and React Testing Library

Install Jest and React Testing Library as development dependencies:

npm install --save-dev jest @testing-library/react @testing-library/jest-dom

2. Configure Babel

Ensure Babel is set up correctly to work with Jest. Add or update your babel.config.js or .babelrc file with the following:

{
  "presets": ["@babel/preset-env", "@babel/preset-react", "@babel/preset-typescript"]
}

Install the necessary Babel presets if not already installed:

npm install --save-dev @babel/preset-env @babel/preset-react @babel/preset-typescript

3. Add a Jest Configuration File

Create a jest.config.js file in the root of your project:

module.exports = {
  testEnvironment: "jsdom",
  moduleNameMapper: {
    "\\.(css|scss)$": "identity-obj-proxy"
  },
  transform: {
    "^.+\\.(js|jsx|ts|tsx)$": "babel-jest"
  }
};

4. Install Additional Dependencies

Install the following dependencies for handling CSS modules and Jest transformations:

npm install --save-dev babel-jest identity-obj-proxy

5. Create Test Files

Ensure your test files follow the naming convention *.test.js or *.test.tsx. Place them in the same directories as your components or within a dedicated __tests__ folder.

Example: src/App.test.js

import { render, screen } from "@testing-library/react";
import App from "./App";

test("renders the App component", () => {
  render(<App />);
  const linkElement = screen.getByText(/Task Timer/i);
  expect(linkElement).toBeInTheDocument();
});

6. Update Package.json Scripts

Add a script for running tests in your package.json:

"scripts": {
  "test": "jest"
}

Run your tests with:

npm test

7. Configure Webpack for CSS Modules

Ensure your Webpack configuration supports CSS modules and Jest compatibility:

{
  test: /\.module\.(css|scss)$/,
  use: [
    "style-loader",
    {
      loader: "css-loader",
      options: {
        modules: {
          localIdentName: "[name]__[local]__[hash:base64:5]",
        },
        esModule: true,
      },
    },
    "sass-loader"
  ],
}

8. Verify the Setup

Run your tests to ensure everything is working:

npm test

Fix any issues or errors encountered during this step.

9. Optional: Add a Coverage Report

Enable code coverage by adding the following to your Jest configuration:

module.exports = {
  collectCoverage: true,
  collectCoverageFrom: ["src/**/*.{js,jsx,ts,tsx}", "!src/index.js"],
  coverageReporters: ["html", "text"]
};

Run tests with coverage:

npm test -- --coverage

This will generate a coverage report that you can review for untested parts of your codebase.

Something to Discuss?

Have questions, ideas, or feedback? Let's talk! Visit hoshdev.com/contact and start the conversation.

I'm here to help you tackle challenges and create amazing solutions.

Server side Rendering Vs Server components. Explanation with example.

Jose Coego — Tue, 31 Dec 2024 13:46:15 +0000

Context: Evolution of Rendering Approaches

Client-Side Rendering (CSR)

How it works: Everything is rendered in the browser.
Pros: Fast interactivity.
Cons: Heavy initial load and poor SEO.

Server-Side Rendering (SSR)

How it works: Content is rendered on the server and sent to the client, where hydration enables interactivity.
Pros: Improved SEO.
Cons: Still requires JavaScript in the browser.

Static Site Generation (SSG)

How it works: Content is pre-rendered at build time.
Pros: Fast initial load.
Cons: Limited content flexibility.

Incremental Static Regeneration (ISR)

How it works: Content is rendered statically and revalidated at predefined intervals.
Pros: Combines static performance with periodic updates.
Cons: Updates aren’t real-time.

React Server Components (RSC)

How it works: Content is rendered on the server with no need for JavaScript on the client (except for client components).
Pros:
- Smaller bundle size
- Faster initial load
- Interactivity supported via client components

Comparing SSR and RSC

SSR Example:

In this example, we have an application that displays the title and description of posts.

Clone the repository:

   git clone https://github.com/hoshdev/poc-nextjs-rsc

Install dependencies:

   npm install

Switch to the 1-rcc branch:

   git checkout 1-rcc

Open App.tsx.

You’ll notice it's a client component (using the use client directive at the top).

In this example, we retrieve post content inside a useEffect:

   useEffect(() => {
     console.log("browserUseEffect", typeof window !== "undefined");
     getPosts()
       .then((posts) => setPosts(posts))
       .catch((err) => console.log("err", err));
   }, []);

Observe: All JavaScript is sent to the client.

It’s a simple example with a small amount of data, but imagine this in a real application. Here's the flow:

The content is created on the server (the first console.log is false).
Then, it's sent to the browser (the next console.log is true).
Finally, once hydrated, the component becomes interactive, and the console.log inside the useEffect is displayed in the browser.

RSC Example:

Switch to the 2-rsc branch:

   git checkout 2-rsc

In App.tsx, you’ll see a server component.

It doesn't have the use client directive at the top. Since it's a server component, it runs on the server.

You can use async/await to retrieve data:

   const PostsPage = async () => {
     const posts = await getPosts();
   };

Note: You can access any Node.js feature in server components, like interacting with a database, the file system, or using process.env.
Observe: No JavaScript for server components is sent to the client. Compare this with the SSR example screenshot.

Adding Interactivity in RSC:

If you need interactivity, you can include client components. These are sent to the browser, allowing for dynamic behavior.

Switch to the 3-rsc-rcc branch:

   git checkout 3-rsc-rcc

Here, we added a client component that handles interactivity. So, the JavaScript for this component is sent to the browser,l but just client component.

Some Final Tips

Server Environment:

Leverage Node.js features: You can use Node.js-specific functionality like async/await, process.env, and more.
No hooks in server components: You cannot use React hooks (such as useState or useEffect) in server components since they are meant to be client-side only.

Event Handling:

Use client components for interactivity: Server components are responsible for rendering, but for event handling (like clicks or form submissions), you must use client components to manage the interactivity.

By understanding the evolution of rendering approaches—from CSR to SSR, SSG, ISR, and RSC—you can make more informed decisions about the architecture of your application, improving both performance and SEO.

Something to Discuss?

Have questions, ideas, or feedback? Let's talk! Visit hoshdev.com/contact and start the conversation.