DEV Community: Blake Anderson

Intelligent JSON Objects in Typescript Using class-transformer

Blake Anderson — Mon, 21 Oct 2024 15:14:49 +0000

In modern front-end development, functional programming has become the dominant paradigm. Frameworks like React and Vue encourage functional patterns to manage UI components, state, and interactions. However, there are situations where an object-oriented approach can be helpful, especially when managing complex data models or encapsulating logic in a more structured way.

This tutorial will show you how to introduce object-oriented programming (OOP) into your front-end projects using TypeScript and the class-transformer module. We’ll walk through how to transform API responses from plain JSON into fully-functional objects with methods and logic, making it easier to work with rich domain models.

Why Use `class-transformer`?

When you receive data from an API, it typically comes in the form of plain JSON objects. These objects carry the data but lack any of the methods or behaviors that you might want to associate with them in your TypeScript classes. For example, a task object fetched from a project management system would contain properties like id, name, and status, but it wouldn’t have any methods to modify that status or perform related operations.

The class-transformer library bridges this gap by converting plain JSON into class instances, allowing you to leverage object-oriented capabilities in your TypeScript code.

Getting Started with `class-transformer`

Let’s start by setting up a simple project that demonstrates how to use class-transformer to add object-oriented behavior to API responses.

Step 1: Install `class-transformer`

First, install class-transformer and its peer dependency reflect-metadata in your project.

npm install class-transformer reflect-metadata

You’ll also need to enable some settings in your tsconfig.json to allow class-transformer to work correctly:

{
  "compilerOptions": {
    "experimentalDecorators": true,
    "emitDecoratorMetadata": true
  }
}

Make sure you also import reflect-metadata at the top of your main entry file (e.g., index.ts or App.tsx).

import 'reflect-metadata';

Step 2: Define Your TypeScript Classes

Let’s define a couple of classes to represent tasks in a project management application. We’ll start with a base Task class and a more specific DevelopmentTask class that extends the base class with additional properties and methods.

class Task {
  id: string;
  name: string;
  description: string;
  status: string;

  constructor(id: string, name: string, description: string, status: string) {
    this.id = id;
    this.name = name;
    this.description = description;
    this.status = status;
  }

  // Method to complete the task
  completeTask(): string {
    this.status = 'completed';
    return `${this.name} is completed.`;
  }
}

class DevelopmentTask extends Task {
  codeRepository: string;

  constructor(id: string, name: string, description: string, status: string, codeRepository: string) {
    super(id, name, description, status);
    this.codeRepository = codeRepository;
  }

  // Method to push code to a repository
  pushCodeToRepository(): string {
    return `Pushed code to ${this.codeRepository}.`;
  }

  // Override completeTask to add code repository logic
  completeTask(): string {
    this.pushCodeToRepository();
    this.status = 'completed';
    return `Development task '${this.name}' is completed. Code pushed to: ${this.codeRepository}`;
  }
}

These classes encapsulate both the data (e.g., id, name, status) and the behavior (e.g., completeTask() and pushCodeToRepository()) of tasks in your project management system.

Step 3: Fetch API Data and Transform It into Class Instances

When you fetch data from an API, you typically get plain JSON responses. Here’s how we can use class-transformer to convert that JSON into fully-functional instances of our Task and DevelopmentTask classes.

import { plainToClass } from 'class-transformer';
import axios from 'axios';

// Example API response for a task
const response = await axios.get('/api/task');

// Transform the plain JSON into a DevelopmentTask instance
const task = plainToClass(DevelopmentTask, response.data);

console.log(task.completeTask()); // Outputs: Development task 'Build feature X' is completed. Code pushed to: github.com/repo
console.log(task.pushCodeToRepository()); // Outputs: Pushed code to github.com/repo.

In this example, the JSON response from the API is automatically transformed into an instance of DevelopmentTask, giving you access to all the methods and behaviors defined in the class.

Step 4: Handling Nested Objects with `@Type` Decorator

In many cases, API responses may contain nested objects. For example, a Project might contain an array of Task objects. You can use the @Type decorator from class-transformer to ensure that nested objects are also properly transformed into class instances.

import { Type } from 'class-transformer';

class Project {
  id: string;
  name: string;

  @Type(() => Task) // Use the @Type decorator to transform nested objects
  tasks: Task[];

  constructor(id: string, name: string, tasks: Task[]) {
    this.id = id;
    this.name = name;
    this.tasks = tasks;
  }
}

// Example API response for a project
const projectResponse = {
  id: '1',
  name: 'Project X',
  tasks: [
    { id: '1', name: 'Task 1', description: 'Task description', status: 'in-progress' },
    { id: '2', name: 'Task 2', description: 'Task description', status: 'completed' },
  ],
};

// Transform the plain JSON into a Project instance, including the nested Task objects
const project = plainToClass(Project, projectResponse);

console.log(project.tasks[0].completeTask()); // Outputs: Task 1 is completed.

In this case, the @Type decorator ensures that each task in the tasks array is transformed into an instance of the Task class, giving you full access to the class’s methods.

When to Use OOP in Front-End Development

Object-oriented programming can be a powerful tool in front-end applications, especially when working with complex data models or when encapsulating behavior directly within objects makes sense. Here are a few situations where OOP might be beneficial:

Encapsulating Business Logic: When working with domain models that require both data and behavior (e.g., tasks, users, orders), encapsulating that logic in classes can simplify your code and improve maintainability.
Handling Complex Data Structures: If your API responses contain nested objects or relationships between entities (e.g., a project containing tasks), OOP can make it easier to manage these relationships through classes and inheritance.
Improving Reusability and Extensibility: Classes allow you to reuse common logic through inheritance or composition. For example, a DevelopmentTask might inherit from a base Task class but add specific functionality for development-related work.

Conclusion

While functional programming is often the go-to paradigm in modern front-end development, there are still many scenarios where object-oriented programming can provide significant benefits. Using TypeScript’s class system, combined with the class-transformer module, allows you to transform plain JSON data into rich, behavior-packed objects. This approach lets you bring the power of OOP to the front end, helping you manage complex data models more effectively.

With the ability to transform API responses into intelligent objects, you can encapsulate both data and logic, making your code more modular, reusable, and easier to maintain. Whether you’re managing tasks, projects, or more intricate domain models, this approach gives you a flexible way to integrate OOP into your front-end applications when it’s most beneficial.

Using a Locally-Installed LLM to Fill in Client Requirement Gaps

Blake Anderson — Sat, 12 Oct 2024 17:36:14 +0000

Challenges in Gathering Requirements

In 200+ websites and mobile apps, I have yet to see a client show up with a full set of requirements for their project. In fact, many of our clients are academics who have limited knowledge of software development. More importantly, they often have domain-specific knowledge that far exceeds our own. This can make it challenging to pin down a solid version 1.0 release.

We rely on an interview process using Scenario-Based Design (SBD) to capture domain-specific details and clarify a Minimum-Viable Product. We have developed a worksheet that steps clients through the process, including project goals, key concepts, stakeholders, and well-defined scenarios. However, the interview process can be cumbersome, often taking hours to complete. It is also sensitive to the level of involvement from the client. To streamline this process, we have integrated LLM into the workflow to generate a baseline and allow the client to provide feedback rather than working from a blank canvas.

More recently, we have released an interactive SBD tool to allow clients to work through the process on their own. Within our project system, clients can work through the steps and develop requirements. Since this involves a number of calls to an LLM API, we wanted to reduce the load and costs on our own systems. Instead, we have the client install an LLM locally and we use this instance to generate our scenarios. This makes for an interesting use case, which I thought I would share.

Installing the LLM

To make the process feasible for clients, we rely on Ollama to download and run a local LLM. The basic model is a ~5GB download, and it is sufficiently powerful for what we are trying to accomplish. Within the SBD tool, we provide instructions to get the LLM up and running.

Once the LLM is installed, we detect the model and present a status indicator that lets them know they are ready to generate a scenario-based design.

const models = ref<llmModel[]>([])
const ollamaRunning = ref(false)
function getModels() {
  return axios.request<tagResponse>({
    url: "http://localhost:11434/api/tags",
  }).then((rsp) => {
    const tags = rsp.data
    models.value = tags.models
  }).catch((err) => {
    ollamaRunning.value = false
    console.error(err)
  })
}

q-btn(label="LLM Online" color="positive" v-if="models.length > 0" icon="sym_o_assistant_on_hub")
q-btn(label="LLM Offline" color="secondary" v-else @click="dlgInstallInstructions=true")

Interacting with the API

Making calls to the local instance is fairly straightforward. We use the ollama NPM package to manage calls to the LLM. This gives us the ability to perform chat completions by prompting the LLM. Here is the basic usage of the ollama plugin.

import ollama from 'ollama/browser'
const response = await ollama.chat({
  model: 'llama3.1',
  messages: [{ role: 'user', content: 'Why is the sky blue?' }],
})
console.log(response.message.content)

We can even support streaming to allow clients to view the results of the LLM in real-time.

const message = { role: 'user', content: 'Why is the sky blue?' }
const response = await ollama.chat({ model: 'llama3.1', messages: [message], stream: true })
for await (const part of response) {
  response.value += part.message.content
}

As a real-world example, here is how we generate a project abstract from a basic description.

async function generateAbstract() {
  loading.value = true
  project.value.abstract = ''
  const messages = [
    { role: 'user', content: 'Given the following project description, write a project abstract in 5-8 sentences which describes the problem the project addresses, nature and aims of the software solution, and the expected outcomes. Provide only the abstract without additional details or commentary.' },
    { role: 'user', content: aims.value }
  ]
  const stream = await ollama.chat({ model: props.model, messages: messages, stream: true })
  for await (const part of stream) {
    project.value.abstract += part.message.content
  }
  loading.value = false
}

Using LLM for Scenario-Based Design

Since our Scenario-Based Design process involves many steps, we need to propagate project information forward as the client develops specifications. While Ollama has a latent memory system that provides context, we inject additional information that is relevant to gain more control of the process.

messages.push({ role: 'user', content: 'Given the following project DESCRIPTION and OUTLINE, List any important tasks that will help to shape the priority and order of deliverables.' })
messages.push({
      role: 'user', content: `
DESCRIPTION:
${project.value.abstract}
`})
messages.push({
      role: 'user', content: `
OUTLINE:
${timeline.value}
`})

We often want to get structured data out of the LLM, which can be challenging with the base Ollama model (llama3.1). Rather than have the client install a syntax-aware model like codellama, we use a prompting technique to elicit correctly-formatted responses.

It can be challenging to get the LLM to cooperate to generate JSON-formatted data, so we provide a template of what we want to get back.

{
      role: 'system', content: `
Provide only a JSON response starting at <BEGIN_JSON> to <END_JSON> with correct syntax strictly adhering to the following structure.

{
  "name":"Jane Doe",
  "gender":"Female",
  "age":"25",
  "race":"",
  "occupation":"student",
  "education":"bachelor's degree",
  "marital_status":"",
  "income_level":"low",
  "background":"[5-8 sentences about the character's background that led them to use the app with a specific purpose or need]",
  "success_story:"Jane was able to use the app successfully to solve her problem.",
  "media":{
    "image_url":"[a sample image url appropriate to the character]"
  }
}
`
},

In our experience, the response can be unpredictable and does not always format the JSON correctly. While codellama provides more consistent results with code syntax, we did not want our users to have to install another model. Instead, we give the LLM a little help by providing the beginning of the assistant prompt.

messages.push({
      role: 'assistant', content: `Sure! here is the character in the JSON format you requested.

<BEGIN_JSON>
{
  "name":"`})

Using the assistant role to direct the format of the response, we get back the continuation of the chat conversation. We then prepend our expected structure and extract the JSON response between the sentinal tokens <BEGIN_JSON> and <END_JSON>. This more reliably gives us a format we can target and extract the relevant sections of structured data.

let content = '<BEGIN_JSON>{"name":"' + rsp.message.content
json = content.substring(content.indexOf("<BEGIN_JSON>") + 12, content.lastIndexOf("<END_JSON>"))
const char = JSON.parse(json)

Here is the complete generateCharacter function.

async function generateCharacter() {
  loading.value = true
  const messages = [
    {
      role: 'system', content: `
Provide only a JSON response starting at <BEGIN_JSON> to <END_JSON> with correct syntax strictly adhering to the following structure.

{
  "name":"Jane Doe",
  "gender":"Female",
  "age":"25",
  "race":"",
  "occupation":"student",
  "education":"bachelor's degree",
  "marital_status":"",
  "income_level":"low",
  "background":"[5-8 sentences about the character's background that led them to use the app with a specific purpose or need]",
  "success_story:"Jane was able to use the app successfully to solve her problem.",
  "media":{
    "image_url":"[a sample image url appropriate to the character]"
  }
}
`
    },
    { role: 'user', content: 'Given the following PROJECT, create a CHARACTER as described below.' },
    { role: 'user', content: 'PROJECT: \n' + project.value.abstract + '\n\n' },
    { role: 'user', content: 'CHARACTER: \n' + character.value },
    {
      role: 'assistant', content: `Sure! here is the character in the JSON format you requested.

<BEGIN_JSON>
{
  "name":"`}
  ]
  const rsp = await ollama.chat({ model: props.model, messages: messages, stream: false, options: { temperature: 1.5 } })
  let json = ""
  let content = '<BEGIN_JSON>{"name":"' + rsp.message.content
  try {
    json = content.substring(content.indexOf("<BEGIN_JSON>") + 12, content.lastIndexOf("<END_JSON>"))
    const char = JSON.parse(json)
    char.stakeholder = characterStakeholder.value
    project.value.characters.push(char)
    charactersError.value = false
    dlgAICharacters.value = false
  } catch (error) {
    charactersError.value = true
    project.value.timeline = []
  }
  loading.value = false
}

As you can see, the tool produces a rich set of requirements which the client can then modify to suit their needs. We have found this to be an effective (and fun) way to gather requirements from even the most reluctant or indecisive client. With a little assistance during the interview process, we have significantly streamlined requirements gathering and produced much more reliable results. Hopefully, these examples can help you create similar solutions that leverage the rapidly-evolving and incredibly powerful AI technologies that are becoming an essential tool for modern software development.

Separation of Concerns: Rethinking the Blend of HTML, JavaScript, and CSS

Blake Anderson — Fri, 11 Oct 2024 16:58:35 +0000

The Evolution of Front-End Development

Once upon a simpler time in the web's history, developers adhered to a design principle that seemed almost sacred: the strict separation of HTML, JavaScript, and CSS. HTML handled structure, CSS took care of styling, and JavaScript was reserved for interactivity and logic. This was the standard architecture—a clear, tidy division where each technology stayed in its lane, making the code more modular and easier to understand.

But then, the world of web development changed. Enter React, a library that threw a wrench into the gears of this tidy approach. React introduced the concept of building interfaces with JavaScript at its core, using JSX (JavaScript XML) to define HTML-like elements right alongside JavaScript logic. This paradigm was radical at the time because it seemed to blend the traditionally separate concerns into one.

React's rationale? The idea that separating HTML, CSS, and JavaScript was an artificial constraint that led to unnecessary complexity. Why split them apart when they were so intimately related in terms of functionality? See the original discussion of this approach from Pete Hunt. This logic resonated with initially-reluctant developers, especially as it allowed the creation of highly interactive, state-driven applications in a more streamlined way. Soon, the concept of "components" became the new lingua franca of front-end development, and frameworks following this approach, like Angular and Vue, quickly adopted similar strategies.

Let’s take a closer look at React’s approach to this blended paradigm.

React in Action: The Blended Approach

Consider a React component that renders a simple user card with a name and some basic styling. Here's a snippet in JSX that mixes HTML-like syntax with JavaScript logic:

import React from 'react';

const UserCard = ({ name }) => {
  const handleClick = () => {
    alert(`Hello, ${name}!`);
  };

  return (
    <div style={{ border: '1px solid #ddd', padding: '10px', borderRadius: '5px' }}>
      <h2>{name}</h2>
      <button onClick={handleClick}>Say Hello</button>
    </div>
  );
};

export default UserCard;

In this example, the HTML structure (<div>, <h2>, and <button>) is directly intertwined with JavaScript functionality (handleClick event handler) and even CSS styling (style prop). React developers would argue that this encapsulation into a single unit (a "component") provides clarity and cohesion because the logic, structure, and style of each component are bundled together.

Questioning the Status Quo: Is This Blending Ideal?

But is this really the best approach? Sure, React's methodology brings convenience and modularity at first glance, but let’s not ignore the underlying trade-offs. When we mix these technologies together, we often create components that are easier to develop but harder to maintain. Changes to the visual layout might now require a full rewrite of the JavaScript code or vice versa, leading to a tightly coupled mess rather than the loosely coupled elegance we originally aimed for.

More importantly, there’s a philosophical question to consider: Should software engineers be in charge of designing the visual components of an application? Even a seasoned coder might struggle to balance clean, maintainable code with the creativity and fluidity required for good UI/UX. The problem is exacerbated for small businesses, independent developers, and startups working on limited budgets. These teams need to iterate fast, pivot quickly, and maintain code that is not just functional but also visually engaging—all without breaking the bank. Are the tools we use today helping them achieve that?

The reality is that while React and its kin have undeniably transformed how we build web apps, they haven’t necessarily made them simpler or cheaper to develop. This complexity poses a valid reason to revisit the idea of separating concerns in a way that leverages modern advancements.

The Case for Reconsideration: Revisiting Separation of Concerns

HTML, JavaScript, and CSS were designed as independent technologies, each with its own purpose. There's an elegance to letting each technology do what it does best, instead of forcing them to play well together in a confined space. In practice, separating concerns allows for specialization—a different mindset is required to write efficient, scalable JavaScript than is needed to craft a visually stunning UI.

For instance, decoupling the logic from presentation allows developers to focus more effectively on clean code without constantly juggling aesthetic concerns. It could also mean that designers can iterate on the UI/UX independently without waiting for a developer to tweak components buried inside layers of JavaScript.

Fortunately, new technologies are emerging that can bridge the gap between the ease of components and the clarity of separation. Let’s explore two notable advancements that encourage a shift back to this design philosophy.

TypeScript: Real-Time Feedback and Flexibility in Contracts

One of the greatest strengths of TypeScript is not just its ability to enforce contracts but also the way it facilitates a seamless evolution of those contracts in real-time. As your application grows and requirements shift, you can modify the interfaces that define the interaction between your visual and functional elements, receiving immediate feedback on how these changes impact the rest of your codebase.

This real-time feedback loop is a game-changer. It means that when you adjust a component's interface, TypeScript's static analysis will highlight every instance in your code where this change affects other parts of your application. Whether you're adding new props, altering existing ones, or completely rethinking how a component should behave, TypeScript ensures that you won't accidentally break functionality without being promptly alerted.

To demonstrate this flexibility, let's expand on the earlier example of the PrimaryButton component. Imagine you decide to add an optional icon prop to the button interface:

interface ButtonProps {
  label: string;
  onClick: () => void;
  icon?: string; // New optional prop for an icon
}

const PrimaryButton: React.FC<ButtonProps> = ({ label, onClick, icon }) => {
  return (
    <button style={{ backgroundColor: 'blue', color: 'white' }} onClick={onClick}>
      {icon && <img src={icon} alt="icon" style={{ marginRight: '5px' }} />}
      {label}
    </button>
  );
};

With this modification, TypeScript immediately checks all the places where PrimaryButton is used. If any instances of the component do not account for the new icon prop, TypeScript will notify you, ensuring that your UI logic remains consistent. This ability to adapt and evolve the contract between visual and functional elements while maintaining instant feedback helps bridge the gap between front-end design and back-end logic in a structured way.

Vue 3 and the Composition API: A Clean Separation in Action

Vue 3's Composition API is another tool that nudges us back toward a clear separation of concerns. It allows developers to organize code by logical feature instead of by lifecycle method, making the code both modular and intuitive. Let’s look at a simple Vue 3 example using the Composition API that keeps visual presentation and functional logic neatly compartmentalized:

<script setup>
import { ref } from 'vue';

const name = ref('Jane Doe');

function greetUser() {
  alert(`Hello, ${name.value}!`);
}
</script>

<template lang="pug">
.user-card
  h2 {{ name }}
  button(@click='greetUser') Say Hello
</template>

<style scoped>
.user-card {
  border: 1px solid #ddd;
  padding: 10px;
  border-radius: 5px;
}
</style>

In this approach, the template is solely concerned with the layout and presentation, while the logic resides in the JavaScript block. The CSS is scoped to the component, keeping the styling distinct and separated from both the template and the logic. This reinforces the idea that Vue’s Composition API is not just about flexibility but also about bringing back some of that much-needed separation between concerns.

Comparing React and Vue 3: Contrasting the Component Implementations

Now that we have a deeper understanding of TypeScript’s capabilities, let’s compare the implementation of a component in React versus Vue 3, focusing on how each framework handles separation of concerns. By contrasting their approaches, we can identify the benefits of using Vue 3, especially in the context of maintaining clear boundaries between the visual presentation and application logic.

React Implementation

In the React example, we create a UserCard component that uses JSX to blend HTML-like syntax with JavaScript logic and inline styling:

import React from 'react';

const UserCard = ({ name }) => {
  const handleClick = () => {
    alert(`Hello, ${name}!`);
  };

  return (
    <div style={{ border: '1px solid #ddd', padding: '10px', borderRadius: '5px' }}>
      <h2>{name}</h2>
      <button onClick={handleClick}>Say Hello</button>
    </div>
  );
};

export default UserCard;

Key Characteristics of the React Approach:

Blended Concerns: The component logic, visual presentation, and styling are tightly integrated within a single file. This can make it easier to understand the component in isolation but also harder to update individual aspects without touching the entire structure.
Inline Styling: Styling is often done inline or through JavaScript-based CSS-in-JS solutions, which can lead to less separation and more difficulty in maintaining a consistent design system.
Tight Coupling: Changes to the visual layout may require updates to the JavaScript code and vice versa, increasing the maintenance complexity.

Vue 3 Implementation with the Composition API

Now let’s revisit the Vue 3 example, which uses the Composition API to achieve a more modular separation:

<script setup>
import { ref } from 'vue';

const name = ref('Jane Doe');

function greetUser() {
  alert(`Hello, ${name.value}!`);
}
</script>

<template lang="pug">
.user-card
  h2 {{ name }}
  button(@click='greetUser') Say Hello
</template>

<style scoped>
.user-card {
  border: 1px solid #ddd;
  padding: 10px;
  border-radius: 5px;
}
</style>

Key Benefits of the Vue 3 Approach:

Clear Separation: The component logic, visual structure, and styles are clearly separated into distinct blocks (<script>, <template>, and <style>). This separation makes it easier to manage each aspect independently, promoting cleaner code organization.
Scoped Styling: Vue's scoped CSS ensures that styles are specific to the component, reducing the risk of global style conflicts and keeping the design modular.
Reactive Data Handling: Vue's reactivity system handles state changes elegantly without coupling it too tightly to the template, which allows developers to focus on updating data without constantly thinking about DOM manipulations.
Flexibility and Readability: The Composition API allows for a more organized and readable code structure, where logic can be easily shared and reused across components without becoming convoluted.

React vs. Vue 3: A Clear Divide in Philosophy

While React's approach focuses on bringing everything into a single, componentized unit, it often results in blending concerns to the point where logic, structure, and styling are entangled. This can lead to complications when the requirements for one aspect change independently of the others.

Vue 3, on the other hand, provides a cleaner separation of these aspects right out of the box. The Composition API enables better-organized logic, while scoped CSS and the template system ensure that each layer of the component remains distinct. This not only makes individual components easier to maintain but also encourages a better separation of developer and designer roles—allowing both to work in harmony without stepping on each other's toes.

An Advanced Scenario: A Dynamic Multi-Section Form with Validation

Imagine we're building a multi-step registration form using React. The form has several sections, each requiring specific validation, visual feedback (like error messages and input highlighting), and conditional rendering based on the user's progress. This kind of setup can quickly become convoluted in a React-based implementation when we try to handle logic, presentation, and styling all within the same component.

React Implementation: The Blending Problem

Here’s a simplified example of a React component that handles a multi-step form, including the logic for validation and styling:

import React, { useState } from 'react';

const MultiStepForm = () => {
  const [step, setStep] = useState(1);
  const [formData, setFormData] = useState({ username: '', email: '', password: '' });
  const [errors, setErrors] = useState({});

  const handleNextStep = () => {
    const validationErrors = validateForm(step);
    if (Object.keys(validationErrors).length === 0) {
      setStep(step + 1);
    } else {
      setErrors(validationErrors);
    }
  };

  const handleChange = (e) => {
    setFormData({ ...formData, [e.target.name]: e.target.value });
  };

  const validateForm = (currentStep) => {
    const errors = {};
    if (currentStep === 1 && !formData.username) {
      errors.username = 'Username is required';
    }
    if (currentStep === 2 && !formData.email) {
      errors.email = 'Email is required';
    }
    if (currentStep === 3 && formData.password.length < 6) {
      errors.password = 'Password must be at least 6 characters';
    }
    return errors;
  };

  return (
    <div style={{ padding: '20px', border: '1px solid #ddd' }}>
      {step === 1 && (
        <div>
          <label>
            Username:
            <input
              type="text"
              name="username"
              value={formData.username}
              onChange={handleChange}
              style={{
                borderColor: errors.username ? 'red' : '#ddd',
              }}
            />
          </label>
          {errors.username && <span style={{ color: 'red' }}>{errors.username}</span>}
        </div>
      )}
      {step === 2 && (
        <div>
          <label>
            Email:
            <input
              type="email"
              name="email"
              value={formData.email}
              onChange={handleChange}
              style={{
                borderColor: errors.email ? 'red' : '#ddd',
              }}
            />
          </label>
          {errors.email && <span style={{ color: 'red' }}>{errors.email}</span>}
        </div>
      )}
      {step === 3 && (
        <div>
          <label>
            Password:
            <input
              type="password"
              name="password"
              value={formData.password}
              onChange={handleChange}
              style={{
                borderColor: errors.password ? 'red' : '#ddd',
              }}
            />
          </label>
          {errors.password && <span style={{ color: 'red' }}>{errors.password}</span>}
        </div>
      )}
      <button onClick={handleNextStep}>Next</button>
    </div>
  );
};

export default MultiStepForm;

Challenges in This React Implementation

Mixed Concerns: This component includes state management, validation logic, UI rendering, and even inline styles—all in the same file. This blending of concerns makes it difficult to reason about the code, especially as the complexity of the form grows.
Scaling Issues: As the form evolves (e.g., more fields, more complex validation rules), it becomes harder to modify one aspect (such as the validation logic) without potentially affecting the others. This tightly coupled code can lead to "spaghetti code," where changes in one area inadvertently impact others.
Styling Maintenance: The inline styles used for error handling and input feedback make it harder to maintain a consistent design system. Inline styling can also negatively impact performance when dealing with larger applications because styles have to be recalculated on each render.
Testability: Testing becomes a nightmare because the validation logic is deeply embedded in the UI component. It’s difficult to isolate the logic for unit testing, making debugging and maintenance challenging.

Vue 3 Implementation: Clean Separation of Concerns

Now, let's compare this with a Vue 3 implementation using the Composition API, which inherently promotes a cleaner separation of concerns.

<script setup>
import { User } from 'types';
import { ref } from 'vue';

const step = ref(1)
const formData = ref < User > ({ username: '', email: '', password: '' })
const errors = ref({})

const validateForm = (currentStep) => {
  const validationErrors = {};
  if (currentStep === 1 && !formData.username) {
    validationErrors.username = 'Username is required';
  }
  if (currentStep === 2 && !formData.email) {
    validationErrors.email = 'Email is required';
  }
  if (currentStep === 3 && formData.password.length < 6) {
    validationErrors.password = 'Password must be at least 6 characters';
  }
  errors.value = validationErrors;
  return Object.keys(validationErrors).length === 0;
};

const handleNextStep = () => {
  if (validateForm(step.value)) {
    step.value += 1;
  }
};
</script>

<template lang="pug">
.form-container
  div(v-if='step === 1')
    label
      | Username:
      input(type='text' v-model='formData.username' :class="{ 'error': errors.username }")
    span.error-message(v-if='errors.username') {{ errors.username }}
  div(v-if='step === 2')
    label
      | Email:
      input(type='email' v-model='formData.email' :class="{ 'error': errors.email }")
    span.error-message(v-if='errors.email') {{ errors.email }}
  div(v-if='step === 3')
    label
      | Password:
      input(type='password' v-model='formData.password' :class="{ 'error': errors.password }")
    span.error-message(v-if='errors.password') {{ errors.password }}
  button(@click='handleNextStep') Next
</template>

<style scoped>
.form-container {
  padding: 20px;
  border: 1px solid #ddd;
}

.error {
  border-color: red;
}

.error-message {
  color: red;
}
</style>

Benefits of the Vue 3 Approach

Logical Separation: Vue 3's Composition API keeps the logic (<script setup>), template (<template>), and styling (<style scoped>) separate, making the code easier to read and maintain. You can adjust the validation rules or update the UI without diving into a single monolithic file.
Scoped Styling: The use of scoped styles ensures that styles defined for this form component do not unintentionally bleed into other parts of the application, maintaining a modular design system.
Reactivity System: Vue’s reactive state handling (ref and reactive) allows for a more intuitive way to manage data and automatically trigger updates in the UI without overly complex state management logic.
Improved Testability: With Vue 3, it's easier to isolate and test the logic independently of the template. The validation logic, for example, can be extracted into standalone functions that can be unit tested separately, enhancing code reliability.
Declarative Syntax: Vue’s template syntax is more declarative, making it clearer to read and understand what the component does. You can easily identify data bindings, event handlers, and state-dependent conditions.

Why Vue 3 Maintains Better Separation of Concerns

Vue 3 shines in situations where separation of concerns is essential because its design naturally encourages developers to keep logic, presentation, and styling in well-defined boundaries. In contrast, React's flexibility and "everything is JavaScript" philosophy can lead to tight coupling between these aspects, making complex components difficult to manage.

React favors integration, often at the cost of entangling code, while Vue encourages clear demarcation between the layers of an application, which ultimately results in code that's easier to understand, debug, and scale.

In the end, the choice between React and Vue 3 comes down to your project’s requirements and your team's preference for code organization. But if maintaining a clean, modular architecture is a priority, Vue 3's structure often leads to a more maintainable and scalable codebase.

Separation Without Compromise

The tools we have today are powerful enough to allow us to revisit the principle of separating HTML, CSS, and JavaScript while still reaping the benefits of a component-based architecture. TypeScript gives us the assurance of strict contracts, reducing the potential for errors, while Vue 3’s Composition API allows us to organize code in a way that respects the boundaries between visual presentation and functional logic.

The modern landscape of web development offers us a chance to blend the best of both worlds: the modular, intuitive nature of components with the clarity and maintainability of separated concerns. We might have embraced blending HTML, JavaScript, and CSS with open arms, but perhaps it’s time to consider stepping back—to let each technology do what it does best, in its own rightful space.

This article represents my personal opinion on the Separation of Concerns and the choice among my teams to use Vue 3 as a framework for more maintainable websites and apps. As this is a controversial topic and React is a popular choice among other dev shops, I would love to hear your thoughts in the comments below.