Forem: Radharadhya Dasa

Taming the Mega-Component: My Vue.js Refactoring Adventure

Radharadhya Dasa — Sat, 07 Sep 2024 16:48:24 +0000

We’ve all been there: opening a codebase only to find a massive component, packed with hundreds of lines of code, where bugs seem to hide in every corner. Recently, I found myself staring down this exact challenge in a Vue.js project. A bug report had led me to this hulking component, and it became obvious—this beast needed taming.

As it happens, I was the one who originally wrote this monstrosity, so there was no one to blame but myself.

Although tools like the Vue mess detector provided some insights, the first step was a simple one: breaking the component into smaller, more manageable pieces. In this post, I’ll walk you through how I conquered this enormous component, and how the end result was a codebase that’s cleaner, more maintainable, and far easier to test.

Step 1: Divide and Conquer

The first task was to break the component into smaller, logical parts. I started by examining the template to identify distinct functionalities. I quickly found a few key candidates for extraction: a menu, a search form, a list display, and three tables that were nearly identical. These distinct elements would become separate, dedicated components.

Step 2: Slicing Up the Script

Once the template was divided, the next step was to do the same with the script. I extracted the logic related to each piece of the template and moved it into its own component file. This not only made the code easier to read but also set the stage for independent testing.

During this process, I noticed some utility functions and a new composable that needed to be extracted. This refactoring pushed me to create reusable logic, which further enhanced the modularity and maintainability of the code.

Step 3: Establishing Communication

The next hurdle was to figure out how these new components would talk to each other. I had to carefully identify the props each sub-component needed and decide which actions should stay internal and which should be communicated back to the parent component. This balance helped keep each sub-component focused on its responsibilities while still ensuring smooth communication with the parent.

Step 4: Syncing the Styles

The refactor didn’t stop at logic; the styles had to be split as well. I moved the CSS previously bundled in the mega-component into the appropriate sub-components. This kept the styles close to the elements they were affecting, ensuring that everything stayed organized and localized.

Step 5: Testing the Pieces

Ensuring that everything still worked after the refactor was essential. As I pulled each sub-component out, I immediately wrote component tests and unit tests to verify that it behaved as expected. This "test-as-you-go" method gave me confidence that the refactoring wasn’t introducing new bugs.

Step 6: Rinse and Repeat

Once I found a rhythm, the process became almost mechanical—identify a section in the template, extract the script and logic, set up communication channels, move the styles, and write tests. With each iteration, the once-monolithic component transformed into a well-organized system of smaller, more manageable pieces.

Additional Thoughts

In some cases, you might start by grouping similar elements into a single component. However, if differences between them start to complicate the logic, it might be worth splitting them further. For example, in my case, I initially created a single component for the three similar tables. But eventually, I realized that the slight differences (like one table having four columns while the others had five) justified splitting them into separate components to keep things clean and focused.

The Results

The refactor was a success. What was once an overwhelming, bug-prone component was now a collection of well-defined, well-tested sub-components. The original component was reduced to less than 400 lines, and I created six new sub-components, one composable, and one utility. The total lines of code is only a 100 lines smaller, but the clarity, maintainability, and testability improved dramatically.

This experience reminded me of the importance of breaking down complex structures into smaller, more digestible pieces. Not only does this make the code easier to maintain, but it also sets the stage for better testing and future development.

So, if you ever find yourself facing a Vue.js component that seems to have ballooned out of control, remember that with a thoughtful approach and some strategic refactoring, you can transform that monster into a clean, well-structured part of your application—one that’s a pleasure to work with.

Elevate Your Vue and Nuxt Code Quality with Vue Mess Detector

Radharadhya Dasa — Sat, 24 Aug 2024 14:02:24 +0000

Is code quality really that important? For computers, not so much—but for us, the developers, it absolutely is. Neglecting to maintain clean code not only hampers our efficiency but also risks becoming a habit that could degrade project performance over time.

Whether you're flying solo, working in a tight-knit team, or part of a larger organization, investing in code quality will pay dividends in the long run.

Even though writing pristine code on the first go is tough, seasoned developers still sometimes create code that's less than perfect. They might notice the mess and leave a "TODO: clean this up later" comment, but let’s be honest, that often ends up getting pushed to the bottom of the priority list.

In reality, many of us jump into projects with extensive, existing codebases. And even if you’re the original author, it’s surprisingly easy to lose track of the finer details after a few weeks. That’s where a tool like Vue Mess Detector becomes invaluable.

Why Vue Mess Detector Stands Out

If Vue or Nuxt is your framework of choice, you’re already set up for success with their strong architecture. However, you can take it a step further by utilizing tools that enhance your coding practices.

Vue Mess Detector is a static analysis tool crafted specifically for Vue and Nuxt projects. It scans your code for potential issues—like code smells or best practice violations—and even provides suggestions on how to address them.

As a static code analysis tool, Vue Mess Detector evaluates your code without executing it. It focuses on identifying patterns that could lead to problems down the road.

One of the most useful aspects of Vue Mess Detector is that it can assess the "health" of your codebase. Whether you’re performing self-checks or assessing legacy code, this tool offers a snapshot of your code’s overall condition. It’s particularly handy for tracking improvements as you refactor, allowing you to see the tangible benefits of your efforts over time.

Why You Should Give It a Go

Vue Mess Detector isn’t just another utility—it’s a stepping stone toward writing better code. If maintaining clean, scalable code is important to you, this tool is a must-try. It’s easy to set up, straightforward to use, and provides instant feedback on your code quality.

Regardless of your experience level, Vue Mess Detector is designed to be helpful. Junior developers can use it to learn best practices, while more seasoned pros will appreciate its ability to spot tricky issues in complex codebases.

Incorporating Vue Mess Detector into your routine helps you catch potential problems early on, before they escalate. Whether you’re refining your code or tackling a legacy system, this tool provides a clear path to improvement.

Since Vue Mess Detector runs manually, it won’t disrupt your workflow. You can decide when to analyze your code, allowing you to stay focused while you work and run checks when it's most convenient.

So why not test it out? A quick scan with Vue Mess Detector might reveal insights that save you time and effort in the long run.

How to Get Started

Getting Vue Mess Detector up and running is a breeze. Install it as a development dependency, then analyze your code with the following command:

npx vue-mess-detector analyze src

This will scan your src directory (or another directory of your choosing) against over 30 different rules. The results can be sorted by file or rule, with detailed explanations and links to the Vue Mess Detector documentation to help you fix any issues. The documentation is comprehensive, so you can dig deeper if you need more guidance.

You can also customize the rulesets to focus on specific areas of your code, which is particularly useful if you're dealing with a large number of warnings. Start with the essential rules, and gradually work your way through the rest, such as the strongly recommended rules, and eventually to the more opinionated ones.

Why Contributing Matters

Vue Mess Detector is powered by the community, and like most open-source projects, it thrives on contributions. Whether you can improve documentation, add new rules, or fine-tune existing ones, your contributions can make a significant impact.

If Vue Mess Detector has been beneficial for you, consider giving back by contributing. It’s a great way to help fellow developers and sharpen your skills in the process. Plus, contributing to open-source projects is an excellent way to increase your visibility in the developer community. To make it easier for newcomers, we’ve labeled some issues as "good first issue".

Wrapping Up

Clean code isn’t just about making your current project more manageable—it’s about cultivating a habit that will serve you throughout your career. Vue Mess Detector is a valuable tool that can assist you in achieving this goal within Vue and Nuxt projects. Try it out, observe how it enhances your codebase, and if possible, contribute to make it even better for everyone.

Refactoring Nuxt Token Authentication Module to Use Nitro's Default db0 Layer

Radharadhya Dasa — Sat, 29 Jun 2024 16:31:22 +0000

Recently, I refactored my Nuxt Token Authentication module to utilize Nitro's default db0 layer instead of Prisma. The transition was relatively smooth, though I encountered a few undocumented or not clearly documented aspects along the way. Here's a rundown of my experience to hopefully save you some time.

Initial Struggle

According to the Nitro documentation, you can use an object for the database in the nuxt.config.ts file. However, at the time of writing, this is not fully supported. Only a boolean value is accepted, which took some troubleshooting to uncover.

Configuration Example

Instead of this:

export default defineNuxtConfig({
  nitro: {
    experimental: {
      database: {
        driver: 'sqlite',
        options: {
          // name: 'something', path: '/some/path'
        }
      }
    }
  }
})

You should use:

export default defineNuxtConfig({
  nitro: {
    experimantal: {
      database: true // this is the correct setup currently
    }
  }
})

Database Connection Issues

I initially faced issues with my app not being able to communicate with the prepared database. The error messages were misleading, complaining about a missing users table, what I already created. After some digging, I discovered that if the database does not exist at the default path /.data/db.sqlite3, Nitro silently creates it.

Error: SQLITE_ERROR: no such table: users

This error suggests a missing table, but the root cause was I tried to use a database in a non default path and name.

Auto-import Issues

Another hiccup I encountered was with useDatabase(). While it worked at runtime without issues, TypeScript could not find it, causing type errors. This auto-import problem can be a bit annoying during development.

// UseDatabase usage
const db = useDatabase();

TypeScript error: Cannot find name 'useDatabase'.ts(2304)

I did not found a solution yet to this problem.

A Known Issue with Table Names and Fields

A known issue with db0 is that table names and fields cannot be used without curly braces {}. This is tracked in GitHub issue #77.

// incorrect, errors out
const { rows } =
      await db.sql`SELECT * FROM ${options.authTable} WHERE ${options.tokenField} = ${strippedToken} LIMIT 1`;

// correct
const { rows } =
      await db.sql`SELECT * FROM {${options.authTable}} WHERE {${options.tokenField}} = ${strippedToken} LIMIT 1`;

Conclusion

Switching to Nitro's db0 layer was a valuable learning experience. Despite the challenges with documentation and some minor bugs, the process was fairly straightforward. I hope sharing these insights can help other developers transition smoothly and avoid some of the pitfalls I encountered.

Feel free to leave comments or ask questions if you run into any issues or have further tips to share!

Let's slap into the code!

Defending the Script Length Rule in vue-mess-detector

Radharadhya Dasa — Mon, 10 Jun 2024 18:11:08 +0000

Hey everyone,

I've been receiving a lot of feedback on vue-mess-detector, particularly concerning the rule for script length. I understand this rule is a bit controversial, but I wanted to take a moment to explain why I believe it’s not just valid, but essential for writing maintainable code.

Why Script Length Matters

Readability: Long scripts can be difficult to navigate. When scripts are too lengthy, it becomes harder to find specific pieces of code, understand their context, and figure out how different parts interact. Keeping scripts shorter enhances readability and makes life easier for developers, especially those who are new to the project.

Maintainability: A shorter script is easier to maintain. Changes are less likely to introduce bugs when the codebase is segmented into smaller, more manageable chunks. This is especially important for large projects where multiple developers might be working on different parts of the same file.

Testing: Smaller scripts are easier to test. When functions and components are more concise, unit tests can be more targeted and effective. This leads to more reliable code and a smoother development process.

Separation of Concerns: Enforcing a script length limit encourages developers to break their code into smaller, more focused modules. This aligns with the principle of separation of concerns, making the codebase more modular and reusable. For me this is the main reason.

Addressing the Controversy

I understand that some developers feel restricted by this rule. It can seem like an unnecessary limitation, especially when dealing with complex features that naturally require more lines of code. However, I believe that this rule pushes us to think critically about our code structure and encourages best practices in software development.

Rather than viewing the script length rule as a constraint, I see it as a guideline that promotes better coding habits. It’s about finding the balance between flexibility and structure, ensuring that our projects remain clean, efficient, and easy to work with over time.

Conclusion

While the script length rule in vue-mess-detector might spark debate, I stand by its validity. It's a tool designed to foster maintainable and readable code, which ultimately benefits all developers involved in a project.

I’m always open to feedback and discussions, so feel free to share your thoughts on this. Let's keep improving our code together!

Slap into the code!

vue mess detector

Radharadhya Dasa — Sun, 09 Jun 2024 18:12:34 +0000

I started to put together a static code analysis tool for detecting code smells and best practice violations in Vue.js and Nuxt.js projects.

Vscode extension is coming soon.

https://github.com/rrd108/vue-mess-detector