Free close up hand typing
Feb 6 2023
Thinking in TypeScript

Throughout all my time with Angular and Vue, the one constant through both frameworks is TypeScript.

Generally, I always thought I knew TypeScript, but over the last couple of months, it’s clear that there is far more to TypeScript and what you can do with TypeScript than I knew.
After watching more and more videos on TypeScript I see that there is so much more I need and want to know about TS. So I’m starting to really study TS, to get to know it and make sure I’m using the advanced features of TS.

My plan for learning advanced TypeScript is:

  • Watch all the Matt Pocock Advanced TypeScript videos
  • Read through Programming TypeScript by Boris Cherry
  • Read Effective TypeScript by Dan Vanderkam
  • Read TypeScript 4 Design Patterns and Best Practices by Theo Despooudis

My aim is to learn the more advanced features of TS so when I have a new feature to add (using either Angular or Vue) or a bug to fix I start to think about the more advanced features of TypeScript e.g. Generics, Types, patterns etc, to how I approach this new feature or bug.

Stephen Adams 0 Comments
assorted books on shelf
Feb 2 2023
Dealing With CommonJS based dependencies

An Angular quick tip I discovered today was if you have an application with many third-party libraries that use CommonJS instead of ES modules. You can add the names of these libraries to the "allowedCommonJsDependencies" option in the builder settings in Angular.json.
This helps remove all the warnings in your build, it is basically telling Angular that these libraries are ok to use CommonJS for now until they are updated.

This is great if you are updating an Angular app, but don’t want to go through and update all the dependencies that are still using the CommonJS approach. Then over time as you update these libraries they can be removed from the "allowedCommonJsDependencies" array.

Here’s a link to the official Angular docs on this – https://angular.io/guide/build#configuring-commonjs-dependencies

Stephen Adams 0 Comments
Photo by Chris Ried on Unsplash
Jan 31 2023
Using third party libraries are useful as long as they are maintained

There’s no denying that the open-source movement has helped move web development forward. Before open source was so prevalent on the web everything had to be built from scratch, there was no searching on NPM for a library that could help fix an issue you had or a framework to structure your application.
But one of the downsides I see with using third-party libraries in your application is if this library is no longer maintained or updated and your work relies heavily on this library it can easily become a maintenance nightmare.

I’ve worked on a few Angular apps now and many are using third-party libraries every time a new version of Angular is released I have to check if these libraries work with the latest version, which on the whole they do. But if one of these libraries is no longer maintained or worked on, then you are stuck with the choice of either not upgrading your Angular version (something I don’t recommend) or refactoring your code to remove this dependency (something I do recommend).

So when it comes to adding third-party libraries to our codebase we need to make a few decisions. First, is it regularly maintained? Checking the history of the library on GitHub can answer that. If there have been no updates within the last year I get worried. Second, if it is maintained how crucial is this library going to be in my application? If it’s core to how the app works how would I maintain the app if later this library is no longer updated? Will it break my application? Can I easily refactor my code to remove this dependency if I need to? These are all questions that need to be considered before just adding a library.

One tip I have used is if you are using a third-party library or component in your application to wrap it within your own library or component then use this ‘wrapper’ throughout your codebase. So if you need to remove the outdated component/library all you need to do is refactor your ‘wrapper’ to either use another third-party library/component or your own version.

Open source is fantastic, it provides so much but I think that in large-scale applications we need to be defensive in how we use open-source code. Third-party libraries are created by some excellent and hardworking developers, many of whom do this work on top of their own, so I think we should be thankful for their work, but just be aware of how much we are using these libraries.

Stephen Adams 0 Comments
Angular
Jan 29 2023
Back in the Angular World

After a year-long contract with Vue, I’m just starting a new contract working with Angular again.
It’s strange coming back to Angular from Vue, the Angular eco-system is far more mature than Vue. Angular is more of a platform than Vue, so when you start working with Angular, you find that the framework provides you with a lot more ‘out of the box’ than Vue does.
Does this mean that Angular is ‘better’ than Vue? Well no, they offer different things. Angular is ideal for larger-scale applications and teams, while Vue is great for applications that might not need an entire platform to get started.

Stephen Adams 0 Comments
Oct 17 2022
The Being Freelance podcast

A few years ago, after working for myself for a couple of years I found these vlogs by a freelancer called Steve Folland. These vlogs showed his life as a freelancer, and the hard work it involved, not only doing the day-to-day work of his business but also managing his business along with managing his family life. It was a great insight into what life really is like for a single-person business owner.

Along with these vlogs, Steve also has a podcast, the Being Freelance podcast, in which he interviews a different freelancer each week to see what it’s like for them to be freelance. He’s nearly (at the time of writing this) at 300 episodes. There are episodes with copywriters, designers, sound engineers, web developers, and all sorts of jobs, but everyone is a freelancer, someone working hard to make a go at running their own business.

In each episode, Steve discusses with the guest how they got started working for themselves, what it’s been like since they started, how they go about finding work and how they balance the amount of work needed to run their own business with having a life. Each episode is full of fantastic advice and helpful tips from each guest. No matter what they do, even if it’s not what you do, you can still get a piece of helpful advice from each episode.

Not only does Steve run his own business and a podcast, but he also runs the Being Freelance Facebook group, where freelancers can get together to talk about freelancing, ask questions, help one another and occasionally arrange meet-ups with one another. He also runs another podcast called the Doing it for the Kids podcast where he, along with his co-host Frankie, talks about running your own business when you have young children and how to balance the two.

I’ve learnt many things from listening to the podcast, from the importance of being consistent with the message you put out there, to making use of sites like LinkedIn and Twitter to promote yourself and your business. How important it is to connect with others and be as helpful as you can, as you never know what effect that can have in the future. Many times a freelancer has helped on a project, which has led to other work opportunities.

So if you are thinking of working for yourself, going freelance, or just started, or have been freelance for a while I highly recommend the Being Freelance podcast, it’s full of great insight and stories from people who may have just started or been working as a freelance for years. It’s all great advice, as Steve says, it’s not about what they do it’s all about being freelance.

(As a bit of side note I was lucky enough to be a recent guest on the podcast, so if you want to hear me um and ah and learn about how I went freelance, then you can.)

Stephen Adams 0 Comments
the word thoughts on a pin board
Oct 11 2022
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.

Stephen Adams 0 Comments
Aug 10 2022
Time Boxing

I’ve recently started to use Time Boxing for my work. Time boxing is where you take a task or series of common tasks and work on them for a set time period.

For example, answering emails. Instead of answering them throughout the day, you set a time each day to go through all your emails, read them and respond.

Another example is coding tasks. Instead of trying to get all you coding tasks completed throughout the day, but keep on getting interrupted by other things. You can schedule a time box in your day (from 10am – 2pm) to work on your coding tasks.

Well, the first thing is we need to start grouping tasks together by category and having a way of capturing all these things that arise throughout the day. We all love Todo apps, having one of those where we can quickly capture what we have to do is the first thing.
Then we need to start categorising these tasks we have throughout the day, some examples of these categories are:

  • Emails
  • Coding
  • Meeting
  • Research
  • Planning
  • Admin

As something comes up we capture it in our todo app and give it a category. Next we need to set up our ‘time-boxes’.

In your calendar you need to block out time to work on these categories of tasks. For developers we might say, I have my daily standup at 10am, so from 9-10am I’ll do some Admin tasks, update Jira, add estimates to tickets etc. Then from 10-10:30am I have meetings so that leaves me between 11-3 for coding tasks. So you’ll block out between 11-3 as busy so no meetings can be added to you calendar that time, you switch off Slack and notifications and just focus on your coding tasks. (You do have to plan in breaks within that time, but the main focus between these hours is coding). After those hours you can switch to another time-box, say between 3-4pm you answer emails, slack messages and the final hour of your day is spent doing research/study.

These hours aren’t set, it’s up to you to decide how many time-boxes you have and how long they are. The important thing is to have them set up and in your calendar so you can only work on the related tasks at that time. Using this approach will mean you days are no long scattered, you won’t feel like you’ve achieved nothing in the day, as you have set the time to focus on working on something.

Time boxing can also be used outside work

This approach can also be applied to outside work as well. For example, say you want to learn a musical instrument or write a book. Again you can capture your ideas and the tasks for this. Then set time in you calendar to work solely on that. So every Monday evening between 7-9pm you practice the instrument you are learning or write 1000 work every weekday between 9-10pm.

So far this approach has been working for me, it makes planning your work day easier, without feeling to overwhelmed. I’m going to keep trying to implement this approach over the next few weeks see how it goes.

Stephen Adams 0 Comments
Mar 15 2022
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.

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.

Stephen Adams 0 Comments
Mar 22 2021
The Angular Masterclass

I’m pleased to announce that the wonderful people at Educative.io have turned my book, Getting Started With Angular, into a course. The course is called The Angular Masterclass . The course contains 147 lessons and should take 20 hours to complete.

Course Aims

The main aims of the course are to teach you:

  1. The architecture of a typical Angular app and how components and modules are used to build up the sections of an Angular app
  2. Explore Services, Dependency Injection, Observables and RxJs
  3. Learn about NgRx
  4. How to test and package your application ready for production

Course Overview

In this course, you will use Angular to build a fully-functional sales team contacts application.

To start things off, you’ll learn about Angular architecture and how components and modules are used to build sections of your application.

In the second section, you’ll dive into routing and navigation, dependency injection, and observables.

In the last part of this course, you will get hands-on experience managing the state of your app as well as testing and troubleshooting. Throughout the course are three different assessments which will be used to test your understanding of the material. By the end, you will have a great new application for your portfolio, as well as a better understanding of how to design an Angular application from scratch.

The team at Educative have done a great job setting out this course, the illustrations are fantastic and really help convery the points I was trying to make in the book.

Stephen Adams 0 Comments
Feb 22 2021
Writing Maintable Angular

I’ve recently given my first talk on the great NgHuston YouTube channel, the topic of my talk was ‘Writing Maintain Code in Angular’.

The main idea of my talk is how we can structure our Angular code in order to make it maintainable for the long term use of the application. In the talk I go through two example apps, both with the same functionality, a book search app, but in the code I’ve tried to show how you set out your folders and components, lead to more maintainable code. That as the application grows it it easier to add new features and maintain when bugs arise.

If you want to see a video of my talk you can, here’s a link to the recording of my talk .

The main points of my talk

In the talk I tried to put across a series of points that are important in writing maintainable Angular code. These points are:

  • Make use of modules to structure your code into small sections
  • Use descriptive property names and function names
  • Make use of methods to write more descriptive code
  • Use Types to create a domain specific language describing the data of the application
  • Write tests that allow you to refactor your code to make it more maintainable
  • Refactor as you go, keeping the code tidy, manageable and readable

In the talk I expanded on these points and try to show through the code examples how to write the example code so it is more maintainable over time.

Here is a link to my slides from the talk.

Stephen Adams 0 Comments