Tag: Vue

Angular’s new component structure

With all the new features coming in Angular, the structure of the component (which are the building blocks of an Angular app) is, in my opinion, changing from what it use to be.

Before the introduction of standalone components and Signals, a typical Angular component would be made up of:

  • A TypeScript file
  • A HTML template
  • A CSS/SCSS file

Each part of the component, nicely separated in it’s own file and each component belonging to it’s own module. This approach has worked for many projects and is still used in a lot of Angular projects. It’s great, but things have moved on. More modern web frameworks have taken a slightly different route and the Angular team have worked hard on giving Angular developers the option to write their apps using this new, modern approach.

So from Angular 15+ the Standalone component was introduced, allowing us as Angular developers to create components like this: 

import { Component } from '@angular/core';
import { RouterLink } from '@angular/router';

@Component({
  selector: 'app-home-page',
  standalone: true,
  imports: [RouterLink],
  templateUrl: './home-page.component.html',
  styles: ``,
  template: `<h1 class="text-3xl font-bold underline">Hello world!</h1>
    <button
      [routerLink]="['/contact']"
      routerLinkActive="router-link-active"
      class="bg-blue-500 hover:bg-blue-700 text-white font-bold py-2 px-4 rounded"
    >
      Add User
    </button>`,
})
export class HomePageComponent {}

In this example, we have everything in the single file. The TypeScript code, though not much of it here, the HTML template and a place for the styles. Also any imports are clearly listed in the imports array, everything is just there. Easy to see and read what is happening in this component.

Comparing with Vue

Not only have I worked on Angular projects, I’ve also spent sometime working with VueJS which is a fantastic framework, with a lot of great features and support.

One thing I did like about Vue was it’s approach to single file components, which at the time were not part of Angular. This is how a Vue component looks:

<script setup lang="ts">
import { RouterLink, RouterView } from 'vue-router'
import HelloWorld from './components/HelloWorld.vue'
</script>

<template>
  <header>
    <img alt="Vue logo" class="logo" src="@/assets/logo.svg" width="125" height="125" />

    <div class="wrapper">
      <HelloWorld msg="You did it!" />

      <nav>
        <RouterLink to="/">Home</RouterLink>
        <RouterLink to="/about">About</RouterLink>
      </nav>
    </div>
  </header>

  <RouterView />
</template>

<style scoped>
header {
  line-height: 1.5;
  max-height: 100vh;
}
</style>

Again everything is in the single file and clear to see. I like how in the Vue version the parts of the component are separated into <script>, <template> and <style> sections, making it easier to see the different parts of the component (this is great if your component has a lot of HTML or TypeScript code).

After working with Vue for a bit and enjoying the single file component structure, when I came back to working on an Angular project I missed the simplicity of the SFC (single file component) that Vue uses. But now with SFC components part of the new Angular I think we will start to see more and more Angular projects take advantage of the SFC architecture.

What are the advantages of the SFC approach

As I see it there are a few advantages to the SFC approach that as Angular developers we can now take advantage of, they include:

  • Easier to read code – now with everything in one file it’s easier to get a complete picture of what the component does and how it works. Ideal for when you are taking over an existing project.
  • Easier to maintain – the code for the component is there in one file, changes are easier to keep track of and refactor when in one file rather than jumping between multiple files
  • It’s easier to explain the code base to another developer – going through the code component by component makes it easier to explain how an application works, rather than going through multiple files trying to explain how the app works.
  • It is easier to test – with modules not being such a core part of Angular now, testing and the mocking for tests are more straight forward to write. Removing a lot of the negative reasons why tests are not written. With less to mock it’s easier to write tests and so there is no reason not to write them.

SFC allow cross framework understanding

One of the main advantages I see to SFC’s is it allows developers from other frameworks to pick up Angular easier – before SFC if you showed a React developer or a Vue developer the codebase of an Angular application it can be overwhelming with the amount of files and listing that this TypeScript file belongs with that HTML file. Now a developer with experience of either React or Vue can understand and relate to this new approach in an Angular project. Also the opposite applies, as an Angular developer who has worked with this SFC architecture when I see a Vue or React code base I find it far easier to relate back to what I already know when looking at the code. I think this will mean that as web developers we can work on multiple projects no matter what the framework used, with SFC the architecture is similar in all cases and we all know HTML, CSS and JavaScript which are the building blocks for all web frameworks.

Thinking of converting your Angular app to use SFC

If you, or your company needs help converting your Angular project to using the new SFC architecture feel free to contact me I can help upgrade your Angular apps to use this new architecture.

Contractor Chronicles 3

This week was spent working on the maintenance of an existing Angular application, which has been recently updated to Angular 15.

The upgrade was fairly easy, Angular and the Angular CLI make upgrading between versions so easy. It was something I missed when working with Vue. I know that the Vue CLI does have a way of upgrading, but with the Angular CLI being a bit more mature I find the upgrade process far more straightforward.

I also spent a bit of time watching a live Twitch stream of Josh Goldberg (he’s a full-time open-source developer, who specialises in Typescript), in this stream he was reviewing a pull request to a Typescript project Typescript-ESLint, which is a library for adding linting for Typescript to ESLint.

Linting is a way of checking for bad practices in your code, it is a set of rules for JavaScript. This Typescript-ESLint project adds rules for Typescript to ESLint.

As I mentioned in earlier Contractor Chronicles I said I was looking for an open-source Typescript project to get involved in and I started to look more and more into this Typescript ESLint project and get involved in the project.

So this week I spent a bit more time looking at this project and after watching the Twitch Stream of Josh’s I’m starting to understand how the project works and hopefully soon I can start contributing to the project.

Finally, I spent some time going through a plan for the rest of the year, breaking down some goals I have for the years into projects. Then using the PARA method to organise these projects and goals.

Further thoughts on using Vue

I’ve been working exclusively with Vue for the past year, and my thoughts on Vue have changed over that time.

When I started using Vue it was when Vue 3 was beginning to be released and there were many changes to how you should build your Vue3 apps. First, you could use both options API and Composition API, which you still can, but the documentation on how to use the new Composition API was still fresh and there were many questions about this new approach. I found myself refactoring a few components in my application from the Options API approach to the Composition API approach, which while fairly straightforward, was a bit of work to do.

Then there was the introduction of the <script setup> approach within the Composition API, this approach now seems to be the preferred way of creating components in Vue 3, but unfortunately, I’ve used the original approach of the Composition API and refactoring again to the script setup approach isn’t something I can justify. I do think that going forward the script setup approach is the way to go and thankfully Vue allows this mix of approaches.

The second major change in Vue has been Vite and the move to this being the preferred approach to building a Vue app over the Vue CLI. You can still use the CLI, but with Vite and the improvements in its speed of it over the CLI, I think that Vite will soon become the default way to start and run a Vue application. Going forward I will use Vite over the CLi for any new Vue applications I create.

The final change I’ve seen since starting to use Vue is the replacement of Vuex with Pinia as the main state management approach within Vue. The application I’ve been working on does use Vuex and has a few Actions, Mutations and Getters from Vuex, which according to the Pinia documentation can be refactored into a Pinia-based approach, but again like the refactoring work needed to convert my Composition API components to using the Script setup approach, this is a large refactoring piece of work that is difficult to justify to my client at this time. Again thankfully Vue 3 still supports using Vuex even though it is no longer being actively updated and should be replaced by Pinia.

Since starting with Vue, the stack I started with and the stack I would use now has gone from Vue 3, Composition API, Vue CLI and Vuex to Vue 2, Composition API (script setup approach) Vite and Pinia.
This to me, seems the ideal approach for building a Vue app.

Now I’ve been working with Vue for the last few months I’m really enjoying working with it and I think I’ll continue working with it, learning more about using it and the best practices for building Vue apps.

Working with Vue

For the last few months I’ve been working with VueJS instead of Angular and I’ve honestly been enjoying using a new framework.

For the last few months I’ve been working with VueJS instead of Angular and I’ve honestly been enjoying using a new framework.

The things I like about Vue?

Well, there’s the component-based architecture, which I know other frameworks have, but Vue’s approach is very straightforward. There are now modules, Angular had just released a new version which means you don’t need modules, but I haven’t used it yet to compare. So starting with Vue it was nice to see how another framework handles not using modules.

I really like the Composition API pattern for writing components, it is ideal for creating reusable components and writing reusable code through the concept of composables.

The routing library is very good, similar to Angular’s approach, but with the scope to replace it with another version if one comes out ( so far I’ve only seen one library that is for managing the routing in a Vue app).

There is a great ecosystem built around Vue, with a few people in the community doing some fantastic work around Vue. This means if you want to add a new feature, there might be a library or a composable (I recommend looking at the UseVue site for the list of composables that can be helpful in any project).

A couple of things I’m not too keen on

First one is single file components. I prefer the way Angular handles things with the three separate files. If you have a lot of HTML and CSS in your file, along with the Typescript, I find that I am scrolling up and down the file a lot as I work on it. Now that could be because I’ve put a lot in the component and it could be broken down into smaller components, and I know there is a plug-in for VS Code (Volar) that splits the component across two panels making it easier to work with, but I don’t use VS Code I prefer Webstorm. So single file components are not my favourite feature.

Another thing that I’ve found is, that when I started working on this project we were on the beta of Vue 3, and as I continued developing the project Vue 3 was stabilised. As part of this, some of the preferred approaches were set out by the Vue team. For example, the Pinia state management library is the preferred choice, I’m using Vuex. The script set-up tag is preferred to the setup function in Composition API, but I’ve implemented our components using the setup function approach. Now, these aren’t big issues, but it does mean that our application will need to be refactored one day with these changes to match the preferred way of developing Vue apps. That’s not a major problem, just a pain.

Generally, I like Vue, I think I’d like to use it more. I think with Vue 3 you can build really stable enterprise-level applications without having to buy into a large organisation’s way of working. If you want to build an enterprise application but don’t want to use a product owned by either Google or Facebook, then Vue is the framework for you.

Continuing With Vue

I’m looking forward to continuing with Vue, seeing where it goes and using it more in the future. As an approach for building web applications, it’s extremely good, well thought out and supported. As long as there is a community to support Vue I think it will continue to go from strength to strength.