Notes management

A big part of being a developer is being able to keep good notes because being a developer is a constant process of learning.

So you need to keep notes of what you’ve learnt, what you want to learn or keep track of. Also notes on your understanding of a topic or technology.

Notes management is now a big topic on social media and on YouTube. Search for ‘how to manage notes’ and you’ll get hundreds of videos where someone talks through their notes ‘setup’.

Recently I watched one by a developer, who makes great videos, and he went through his process of creating notes and how they are organised. What followed was a 15 min video, where he listed over seven different apps he uses for creating notes, from articles, Tweets, handwritten notes, capturing notes in various apps. One app for work notes, one for personal, and a paper based note book. It was a lot, and far over complicated. Just use one thing, pen and paper plus an app to store some notes, you don’t need 7 different apps.

I think the issue is really these notes apps, as they are all competing with one another with new features, plus now the use of AI, these apps are trying to do everything and give the user new features all the time in order to keep the user tied in with their platform.

Notes management is a crazy topic, but really it should be simple. Find a way to write some notes on a topic, and be able to find it again quickly and easily letter when you need to have a refresher.

Comparing output

I recently looked at someone’s GitHub account because I saw that they had recently been sponsored by someone I follow on BlueSky.

Their GitHub account (https://github.com/shuuji3) is very impressive, and I believe that this developer is worthy of the sponsorship they receive. They have been working on documentation for several large projects, made over 1,475 commits in the past year, and contributed to Elk, the Mastodon client.

It’s all really impressive and did make me think: how do they find the time to do all this? Then I easily fall into the trap of comparing my GitHub output with theirs.

It’s easily done, especially now with GitHub being such a big part of the web industry. But does it show a true picture of how someone works or the type of work they have done? And should we really compare our output with someone else’s?

Is working from home working

Today, I came across a news story that caught my attention. It mentioned the ex-head of ASDA claiming that working from home isn’t “proper” working and is causing a decline in productivity. I have to say, I strongly disagree with this perspective.

For me, working from home has been a game-changer in terms of productivity. Let me paint you a picture: Instead of standing on a freezing cold train platform for 15 minutes (or longer if the train is delayed), I can start my day feeling fresh and ready to tackle my tasks. Train operators, who certainly don’t work from home, often fail to deliver on time, which in itself contradicts the argument that physical presence equals productivity. And the experience doesn’t get better once the train arrives. Imagine standing in a packed train, overheating from the stifling heat, only to rush onto the tube and squeeze into another packed train for another 30 minutes. By the time I would reach the office, my energy is already drained—and I haven’t even started working yet.

This isn’t just about convenience; it’s about efficiency. The time saved on commuting can be invested in meaningful work or even in personal well-being, which ultimately boosts productivity. I believe the issue here isn’t that working from home isn’t working. Rather, it’s that some people are still clinging to outdated ideas of what “work” should look like. For decades, we’ve been conditioned to believe that being productive means traveling into the same building, having endless meetings about work, and then heading home only to repeat the cycle the next day. But the world is changing, and so are the ways we work.

I’d be willing to bet that the ex-boss of ASDA never had to endure the kind of commutes I’ve described or tried to code an application while six colleagues stood nearby having an unrelated meeting. If they had, they might see the value in remote work. Working from home is new for many people, but that doesn’t mean it’s ineffective. In fact, it works remarkably well for certain types of jobs and individuals.

The key takeaway here is that we shouldn’t dismiss working from home just because it’s different from traditional office work. Instead, we should embrace this shift and recognize that productivity isn’t about where you work but how you work. Remote work isn’t a one-size-fits-all solution, but for many people and industries, it’s a powerful way to achieve better results and a healthier work-life balance. The real challenge is for leaders to adapt to this new normal and support their teams in finding what works best for them.

AI and the web developer

With AI becoming more and more prevalent in the world, as web developers we need to think about the effect it has on our work.

How the type of projects we will be working on going forward will incorporate AI, not only in the tools we use (things like CoPilot) but also the new projects we build will probably have some aspect of AI in them.

This means as front end developers we need to start understanding AI, how it works, the available APIs out there that we might need to implement within a new project.

So will AI take over all front end development roles? Probably not, but will we need to know how to work with it? Yes.

For me I’m excited about the opportunity. APIs like Googles Gemini look good and there’s plenty more out there. I’ve been lucky enough to work on a couple of projects that use AI in some capacity, and I’m looking forward to doing more projects like this.

Trying microblogging

I’ve been reading a few sites where they use Microblogging (which is short form blog posts). The main sites I’ve been checking out are https://softwarecrafts.co.uk/100-words and Andy’s 100 words a day challenge that he set himself last year, and the other site is https://dbushell.com/blog/ where David has both long form notes and also micro blogging.

I’m not sure I’ll be able to stick to writing 100 words a day like Andy, but short blog posts about Angular, web development and freelancing seems like a good idea.

Use of Mapping Types in TypeScript

I’ve been reading up on my #Typescript and one feature that is under used is mapping types and using them to create new types. 

On some codebases I’ve worked on I’ve seen, and have been guilty of myself, creating new type definitions that maybe extend another Type or are extremely close. For example, a User type and a Staff type both have similar properties (firstname, lastname, email, id etc)

type User = { id,firstname, lastname, email};
type Staff = {id, firstname, lastname, email, jobtitle);

In the need to get a new feature completed it can be quiet easy to create a new Type definition without checking to see if there is something that is already within the code that can be used or extended. Creating new types as we go can lead to cases like above where two types have been created, the original User type and the quickly written Staff type that is needed in a function of a component I’m developing as part of that feature that needs to be done, and I know that I will go back and refactor the code to use an extended or mapped type when I have time (which we all know, we never do).

This is where I feel in my own code mapping types should be used. With a mapping I can create my new type, and if for some reason (API changes or another developer changes the original definition) the remapping of my new type is updated if the original type is changed. So in the case of our User and Staff types if there is a change to the API and title is added as a property which needs to also be displayed in a screen that is making use of the Staff type. By using a Mapped type, this new property is automatically available.

I feel this makes the code more robust and flexible to change, the issue with mapping types is that the syntax is not as clear as using the extends keyword, but really all we are doing in a mapped type is looping over another key and picking what we want from it to create a new type and if that original type changes our derived mapped type can be amended too without to much work.

I think the main aim for how I should write my TypeScript code is to think what are the main data structures in an app, maybe defined by what an API is returning me or what I’m asking for if using GraphQL, and how can set up all the other Types in my application to be created or inferred from these base Types. So my code is both type safe but also flexible enough to handle changes over time. (I think this is the main message Matt Pocock has been trying to get across in his courses and book).

React logo
Notes on NextJS: Routing in NextJS

Over the last few weeks, I’ve been delving deeper into Next.js, the React meta-framework. One of the initial hurdles when acquainting oneself with a new framework is understanding its routing mechanism, a fundamental feature of any web application.

Next.js takes a unique folder-based approach, distinguishing itself from other frameworks I’ve worked with. Unlike Angular and Vue, which utilise a component-based router system detached from the application’s source folder structure, Next.js integrates routing seamlessly into its architecture, building upon React’s inherent lack of a default routing system. It’s fascinating to observe how Vercel has seamlessly integrated this functionality into the Next.js framework.

The folder-based routing system in Next.js is remarkably straightforward. Each route within your application corresponds to a sub-folder in your source directory, with each sub-folder containing a page.tsx file representing the destination of that route.

While this approach is innovative, it’s not entirely novel. In the early days of web development, before the advent of JavaScript frameworks and server-side rendering, we employed a similar folder-based routing system, where each route corresponded to an index.html file within its respective folder. For example, the homepage’s route would be http://www.mysite.com/index.html, while a separate route would be http://www.mysite.com/news/index.html. This historical perspective underscores the cyclical nature of ideas in the web industry.

It’s heartening to witness the simplification of routing, particularly with Next.js’s support for dynamic routes. Moreover, it’s intriguing to note that other frameworks, such as Nuxt for Vue and AngularJS for Angular, are also adopting folder-based approaches. This resurgence of an old concept underscores the enduring nature of certain ideas within the ever-evolving landscape of web development.

Demo app

https://github.com/Stephenradams/star-wars-search

To learn a bit about the routing and how to call external APIs in Next I created a small demo app using the Star Wars API to get lists of Films, People and Planets. Its a very simple app, but these small demo apps are a great way of learning new concepts.

In this demo app you can see that the folder structure uses a folder for each sub-section (films, planets, species, starships):

Inside each folder is a page.tsx file which is the ‘homepage’ of the route, these sub-folders can also have a layout.tsx file which defines the layout of the page, by overriding the main layout.tsx layout.

To support dynamic routes, NextJS uses a special sub-folder named [id] where the dynamic property, in this case an id number used to direct the user to another page.tsx file inside this special sub-folder:

This dynamic parameter is accessible within the page.tsx file via the component params:

export default async function Page({ params }: { params: { id: string } }) {
    const filmId = params.id;
    const filmDetails: FilmDetails = await getFilm(params.id);
    console.log(filmDetails.title);

So in this example code I’m getting the ID from the params and then passing it to my API call. It’s so simple and straight forward, I’m not adding anything to a routes file, or setting up routes and getting the URL params is extremely easy.

I really like the approach Next has taken with routing, now I’m going to take a look at handling forms and form data which is another common function of web apps.

NextJS, a new journey

Over the past few weeks, I’ve been diving into #NextJS and #React for a couple of reasons. Firstly, I’m a firm believer in continually learning new things, whether it’s a different framework or a fresh language. Plus, let’s face it, React is a big deal in the business of frontend development. As a freelancer or contractor, having some React know-how opens up a wider range of projects to dive into.

My initial impression of React is pretty positive. It’s a lightweight library that’s perfect for whipping up frontend apps, especially ones that need to hook into hefty APIs like those powered by Node.js or .NET. If your team is all about the frontend/UI side of things, React is definitely worth considering.

Comparing it to Angular, React is a whole different beast. It doesn’t come packed with all the bells and whistles Angular does out of the box (think routing, testing, RxJS, Services, etc.). But hey, Angular’s been making strides to simplify things lately, which is great news for its future.

Now, onto NextJS. It’s like the Swiss Army knife of application frameworks. It gives you all the tools you need to build a top-notch app right out of the gate. I’ll admit, the concept of Server components and Client components threw me off a bit coming from an Angular background. But hey, in NextJS, everything’s a Server component unless you say otherwise. Plus, having server-side rendering baked in is a nice touch.

I’m also digging NextJS’s App Router and file-based routing. Compared to Angular’s routing, it’s way more straightforward. Sure, other frameworks like AnalogJS are jumping on the file-based routing train too, but I haven’t gotten my hands dirty with AnalogJS just yet.

So, my plan? Stick with NextJS and see where it takes me. I’ll be putting my name out there for contracts and projects that are NextJS-friendly.

One thing I firmly believe is that no matter which framework you’re into, a good web developer can adapt to any of the big ones out there (Angular, React, Vue). It’s not just about how many years you’ve racked up using a framework—it’s about being a team player, understanding what the client needs, communicating effectively, staying open to learning from others, and bouncing ideas around.

Anyway, I’m excited to see where this NextJS journey leads me!

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.

Update your package.json file for better tests

By default Angular gives you a couple of commands to run:

npm run start
npm run build
npm run watch
npm run test

These commands get you up and running, you can run the app in the browser, build the final version and run tests in run once.

I like to add a few more commands to my package.json file, these extra ones are:

npm run test:watch
npm run test:coverage
npm run test:ci
npm run lint

These commands give me more options for running my tests, in watch mode, with code coverage and in both watch mode with code coverage. There is also a linting check, which is always helpful for code quality checks.

The full commands in package.json look like this:

"test:watch": "ng test --watch",
"test:coverage": "ng test --code-coverage",
"lint": "ng lint",
"test:ci": "ng test --watch=true --browsers=ChromeHeadless --code-coverage"

Out of all four new commands the most essential one is the test:ci one, which runs my tests in headless mode (which is great as I don’t want to have the Karma runner opening the browser all the time) gives me an overview of all the code covered by tests.

While something like NX will give you more options and use Jest, being able to run these commands in a Angular CLI based project does make running tests easier leaving no reason not to write tests.