I’ve been using NgRx for a short while now and I thought I’d write up some of my initial thoughts on it.
Getting started can be tricky, it is a steep learning curve, but once you understand what each part of the framework is for and the underlying approach NgRx is taking a then it’s easy to get going.
One complaint about NgRx is the amount of code you have to write, the number of files you have to generate in order to get something working. For me I don’t think this is such a problem with file is designed to do one thing and one thing only. This separation of concerns makes reading through an NgRx based code base easy to understand. When you open one of these files, a reducer for example, you know exactly what that files role is, what is does and how it works. It’s just concerned with the one thing and shouldn’t have any other unrelated functionality in that file.
With today’s modern editors it makes switching between files so much easier and faster. If you had to use Eclipse to write NgRx you would definitely have a case to complain about the number of files.
One of the things I really like about using NgRx is this prescriptive approach it takes. As a contractor I have to work with a new code base every few months and being able to ‘get up to speed’ with how an application works can take a while. Even though they are all Angular applications, I find that there are 100s of ways an Angular application can be structured, based on the needs of the business or the experience of the developers who have worked on the app.
If an application has a good developer, who thinks about and plans how to write their code, and a business who are concerned with the quality of the product over just getting things done. A applications codevase can be well structured without NgRx, but through using a framework like this means that the code is well written and based on good practices.
So when someone like me starts working on the project I can go through the application and see how data is passed through the app, how actions are being used and when and how the application flows.
So I’m enjoying using NgRx , it definitely has its place, in developing large scale applications, with a team of developers working on the application for other projects NgRx isn’t the best approach, but for a large application it’s a great choice of framework.
Recently I’ve started a new project where we plan to restructure a large application into smaller, more manageable individual projects.
As well as dividing the application into small modules we want to set out a way that all the developers on the team can write each part of the application in a consistent way.
One approach we’re looking at in using Angular Elements with NgRx. Each individual sub-section of the application is loaded into the main parent application as an Angular Element and NgRx is used as the framework for having a consistent pattern through each application on how data and state is loaded.
I’ve used NgRx before, especially when writing a introduction to NgRx chapter of my book, Getting Started With Angular 8. So if want to learn about how to use NgRx check the chapter from my book. Using NgRx with Elements is something new to me, so this was an interesting exercise.
In a previous contract I’ve used Nx as a way to create something similar. We used Nx to manage all the sections of the application we created as Angular elements and generate a library which was used across all the sections of the application to share common functionality. This worked really well, but it did lead to all the code being in a monorepo.
In this new project we don’t want to have a monorepo, instead each sub-section is in its own repo. This allows a developer to get the single project and it makes managing the deployment easier. There are many pros and cons to using either a monorepo approach or not. For this client, the multi repo approach is what they have in place.
Using Angular Elements (which I admit when I first heard about Elements I wasn’t to sure on the benefit it would bring) is allowing us to really separate out each sub-section so they can be developed as a single application in its own right. Once the application has be built and tested it can be packaged up as an Element and loaded into the parent application. We’re using Ngx-build-plus to manage the build of the elements which takes a lot of the work out of creating a single bundle for the Element.
The use of NgRx is allowing us to write a cleaner code base, I know NgRx has a lot of boilerplate code, but it is a consistent pattern and if multiple developers are working on multiple parts of the application. It can lead to a lot of repeated code, bad habits can appear in the code base. Using NgRx means that if a developer picks up a different sub-section to work on they can follow along with the structure NgRx defines. This makes fixing bugs, adding new features and working out how an application works easier. We’ve all been there where we’ve take over a project written by another developer and a common question you ask yourself is ‘why have they written it like this’. Well with NgRx that’s not a question we should be asking.
It’s early days with this approach, we still need to test this further to make sure there aren’t any further issues that we may run into before we completely switch over to using Elements and NgRx, but so far I think it’s a good approach for developing large enterprise applications if you don’t want to us a monorepo approach that Nx prescribes.
We’re into September now and I thought I’d give a small update on what’s been happening behind the scenes at CGCSoftware towers.
The main thing that has happened is I’ve started a new contract working for Cambridge Assessment. Working in one of their teams on a large scale Angular application. It’s an interesting project working with NgRx and Angular Elements to create a more loosely coupled application allowing different developers work on individual sections of the application, but still access the APIs that run the application in a consistent way.
I’m finding working with Angular Elements really interesting, they have real scope to give so much more flexibility in how Angular applications can be set up. Not only are they great for gradually upgrading an AngularJS application to Angular. They allow teams to create individual parts of a large scale application in separate pieces which can be slotted together in the main application.
Writing a book has been a massive project, it’s taken far longer than I thought it would, but I’ve learnt so much through writing the book.
Not only have I learnt more about Angular, but how to create content for the book. Originally you think that it’s just a simple case of writing out you thoughts on the topic of the book (in this case Angular) but there is so much more that you need to think about. How to structure the chapters, how to make sure the reader is left feeling that they have learnt something, how a section you felt made sense when you originally wrote it, didn’t make sense at all.
Having published the book through Leanpub I can make further updates to the book as newer versions of Angular come out or new features are added.
So August has been busy, I did manage to get a holiday in as well, which was great. Now we’re into September and got another busy month ahead. Looking to work some more with NgRx, while still getting up to speed with how things work at the new contract. Also looking at ways to be involved in some more open source projects in the coming months.
As part of my upcoming book Getting Started With Angular 8, I spent a time researching Observables and RxJs in Angular. In the book I spend a complete chapter going through how Observables work and how RxJs is a JavaScript library that comes with Angular, which helps with working with Observables.
While this chapter gives a detailed explanation of using Observables and Observers, how you use them within your Angular applications.
One thing I have noticed now within the Angular community, there are more and more talks and articles about how to make use of Observables and RxJs to create fully reactive applications.
Now developers are beginning to understand what Observables are and what RxJs brings to their applications, the next question is how can we make use of this to the benefit of our applications? More and more community leaders are showing ways we can use RxJs to make applications more reactive.
Changing the mindset from imperative to reactive
In the Observables and RxJs chapter of the book I go through how to use and Observable with RxJs, but the approach I use is a more imperative approach. Where we create and Observable, set it up and then Subscribe to the Observable when we want to make use of it.
Now after seeing some fantastic talks from NgConf about how we can make use of RxJs to turn how we setup our Observables to make the way data is passed throughout the application more reactive.
Some of the great talks that show this new approach are:
Data Composition with RxJs – in this talk Deborah Kurata show a pattern for creating streams of data with RxJs to generate a View Model behind our components. Models that load data via Observables that don’t need to be subscribed to.
Thinking Reactively – Mike Pearson goes through why thinking in a more reactive approach is a great idea. He makes some fantastic points about why taking this reactive approach will benefit our applications.
Having a more reactive mindset means we use patterns to structure how data is passed into and out of our components, so the application reacts to changes from the user. Building applications this way makes our apps appear faster and more responsive to the user. A fast acting application makes a happy end-user.
As Angular developers I think we should start sharing different approaches to how we can write more reactive Angular applications. If we look at sources from outside Angular, like existing patterns which may not be used currently in this imperative approach. These patterns will help us develop in a more reactive mindset.
These talks are a great starting place if you want to start take your knowledge of Observables and RxJs and how they can be used to making a more reactive application. If you’re not sure how to use Observables and RxJs then feel free to check the chapter in my upcoming book.
I’ve recently worked on a project where we found ourselves in the situation where we was waiting for some APIs to be developed by the backend team. So in order to not stop our development we decided to look at creating mock APIs.
Now there are many online services that can provide you with a mock end point to work with, but there are limitations with the number of endpoints you can make or the structure of the data you can return.
So we decided to take a look at using NestJS in order to create our mock APIs. First impressions were really positive, as an Angular developer I found getting started with Nest very easy. With Nest using similar concepts to Angular (Services, Modules etc) I found Nest a great way of adding a backend to my Angular application, Nest is something I plan to look at further.
I can see that there will be two approaches to creating a fullstack application, one approach seems to be ReactJS with Node/Express and the second approach is Angular and Nest. If you look at the job market you’ll see a lot of roles where the tech stack is React and Node in order to create a complete fullstack application. Now with Nest becoming more and more popular I can see Angular and Nest becoming a tech stack for creating a fullstack application.
If we look at how Nrwl are developing enterprise applications they are taking this approach of using Angular with Nest as their stack for their clients. As a side note when we decided to create our mock APIs we was using Nrwl’s Nx service, which makes managing the setup of a complete Angular/Nest application so easy and with the addition of Cypress it makes a fantastic complete approach to creating a full stack application.
As an Angular developer I would recommend that any Angular developers look at using Nest even if the applications they build are using APIs created in another language by another team within their organisation. The reason I think we should look at Nest is because if, like I did in this application, you have to wait for the ‘real’ APIs to be ready you could use Nest to create a mock APIs.
Eventually I can see the Angular/Nest approach becoming a standard way of building fullstack applications, which is something I’m planning to work on while I’m between projects.
For the last 6 months, I’ve been working with Packt publishing writing a book on Angular. This is the first time I’ve ever written a book and it has been a big old slog of work, but it has been worth putting in the work.
We all see these ‘famous’ developers who have written books, attend all the conferences and even find time to work on open source projects and while it’s not a good idea to compare yourself to others, sometimes you can’t help yourself. So for the last year, I’ve had an idea of writing a book, but never actually started. Then I was contacted by Packt asking if I’d be interested in writing for them. I think they had read some of my blog posts and were interested.
This was the push I needed, and so I quickly replied to them and said yes, my life as an author has started. But if you’ve never written a book you can be completely unprepared for what you need to do. I wish I had either asked someone about what is involved in writing a book before I started, it may have put me off.
So what you need to know before writing a book is, first, no matter how much time you think it’ll take it will take longer. I originally thought that I’d find enough time in the day to write and then be able to make good progress on the book. You see I work for myself as a contractor, so if I don’t work I don’t get paid. I needed to carry on working as I write the book. I did think that it’ll be easy to work all day and then write for a couple of hours in the evening. Unfortunately, this did not happen every day, first of all, you finish a days work and your brain doesn’t have the capacity to then switch from coding all day to writing. It’s hard to concentrate, what you write makes no sense and you just can’t think about coding after spending all day working as well.
So I thought I’d spend more time at the weekends writing, but soon life gets in the way. You need to spend time with your family or there are things to do around the house. Your plan of spending all day Saturday and Sunday may soon turn into an hour on Saturday and a couple of hours on Sunday. (Thankfully my wonderful wife is very supportive of me and was happy for me to work on the book when possible).
I soon found that getting up early and spending a couple of hours in the morning helped. I was getting up at 6am and writing before work started. I had a contract where I could work from home, that helped a lot.
The second thing you need to know about writing a book is that you need to be consistent. Writing every day if you can, even if it’s just an hour helps so much. Getting that daily writing means that you can carry on from where you were in the previous day far easier. You can get ‘into’ writing quickly, ideas for what you are going to say come to you easier because you’ve got ideas flowing from you. It’s like pushing a large ball up a hill, the more momentum you get the easier it is. Momentum is key in writing a book.
You’ll also have to be comfortable with feedback on your work. As I submit chapters to the publishers they are reading and reviewing them. Which means I get feedback on what I’ve written, now if I’ve written a section or a sentence that I think is fine, but the publisher thinks it’s confusing or needs some more work, you have to be comfortable with this feedback and respect the experience they have. I may know about Angular, but they know about books.
Not only do you need to be consistent and declined you also need to have a detailed plan of what you’re going to write. Before I started I need to provide an outline of the book, what the chapters are, what the reader will learn in each chapter and how many pages you’ll have in each chapter. In hindsight, I wish I had spent a little more time on this plan than I did. I guessed the number of pages for some chapters and you will have to fill those pages. So if you think you can write 40 pages on Unit Testing, you may find this hard, think about it that’s about 12,000 words!!!
Now, not only do you have to write the text for the book you need to find the time to write the supporting code for the book too. This can take a large amount of time as well and needs to be something to consider if you’re planning on starting a book
Now, while I found writing a book hard I do think to go through the process I’ve learnt so much about Angular, the topic of the book. Having to explain concepts to someone is the best way to learn and to find out what you do know about a topic and what you don’t know. You really have to research and understand a topic before you can write about it. Gaps in your knowledge will be filled in through this research.
So would I go through this again? I think I would, but maybe on a smaller scale or through self-publishing. I have been thinking about writing a smaller book on a topic within Angular, something on NgRx maybe.
Writing is hard, it takes planning, time and dedication, but the learning you’ll do through writing is a great benefit.
My book isn’t out yet, hopefully soon, just going through the last reviews and amends now, but when it’s out I’m going to let as many people as possible know, and hopefully, someone will even buy it.
I’ve recently listened to the latest episode of Adventures in Angular, a great podcast. In this episode they were discussing the merits of the Angular CLI, what it does for us as Angular developers, how much is saves a company on time and money.
The Angular CLI makes writing Angular applications so fast and easy. Before the CLI we had to handle all the build steps ourselves, using tools like Grunt than Gulp. Both fantastic build tools, but having to fight our way through JSON config files was not easy, especially if you wanted to create the ideal setup for your project. It would take days of tweaking the config settings working on the ideal build process.
Then you had to share this build setup with your other team members, and if one thing was different on their system, then the build would fail for them, it was a nightmare.
Thankfully the CLI has taken all that away from us, now there is one universal way of building and running an Angular application locally, which works the same for all members of a team.
Another great benefit of having a CLI is that we no longer have to worry about what build system a project is using. Whether it’s Grunt, Gulp, Bazel or Rollup, this is all handled behind the scenes by the CLI. So as new build systems are coming out, the CLI team can add them to the CLI and we as Angular developers can either accept the new build system the team have added to the CLI or make some changes to our angular.json file and choose the build system we want for our projects.
I think one of the greatest benefits of the CLI is how easy it makes running Unit Tests. Before Angular, in AngularJS, setting up Karma and Jasmine was a painful experience. Again, tackling JSON files, making sure all the paths were correct, spending hours searching for answers to errors when we finally tried running the tests. Reading blog posts where someone showed us a few ‘simple’ steps to making it all work first time, and finding that after following these ‘simple’ steps Karma still didn’t work for us, then trying to figure out where we went wrong. Setting up Unit Tests was a painful and long process, but now with the CLI it’s all handled for us. All we do is run a simple command, and boom all our Tests are run.
The Adventures in Angular episode really did show how much time and effort the CLI now saves us, not only as developers, but the costs it saves companies. No longer do companies have to pay developers for setting up their local build systems, now an Angular developer can be up and running in no time.
If, as an Angular developer, you’ve gotten use to having the CLI around, take a minute to think about all the benefits it brings us. The CLI is really an amazing tool, it really helps separate Angular from the other front-end frameworks out there.
Recently I saw Julien Renaux posted on Twitter that whenever they work on an Angular application, there were a few things they always did in their approach to how they built the application. One of these things they did was write one module per component, this drew a response from another developer asking why they didn’t use a SharedModule instead.
So this got me thinking why would you use a module per component instead of a shared module?
Before we look at the benefits of the module per component approach, it’s worth looking at the other approaches we can take in our Angular application.
First, there is the Featured module approach, this is where we are developing a feature of our application, say user management. So we create a UserManagement module that has all the functionality associated with user management, all the components and services for that feature. This is a pretty standard approach, which we start with when getting started with Angular.
Another approach is creating a SharedModule. In this shared module we may have components or services that are going to, well, shared in several features. For example, we may have an authentication service, which checks if a user is authenticated or not. We may need this functionality throughout an application, so placing this service in a SharedModule that is included into all the sections we need makes sense.
The problem with the share module approach is that over time and in a large application this module could grow out of control. Especially if you have multiple developers working on an application, and they don’t know where to add a new service or component they are creating, which is clearly not part of a feature module. The temptation is to add it to this global shared module, which over time gets bigger and bigger. I’ve seen this happen with .Net projects. They have a shared library that became a dumping ground for services where the developer wasn’t too sure where the best place to add their new service was.
There is also another approach, the module per component approach. This is where for each component, we create a module for each component in our application. At first that sounds like a big overhead having to create this module every time we create a new component, but it does have two great benefits. One, it helps with tree-shaking. If our application is not using the component, then it’s not loaded. This reduces the load the browser needs to make, increasing the speed our application loads.
The second advantage this brings is when importing a module, we know exactly what is in that component specific module. Unlike the shared module approach where they are other components and services which are part of this shared module. The single component module approach means we know that the single component is part of the module we’re importing. It keeps our imports clean.
This approach has been used to great effect by the Angular Material team, who changed from the feature module approach to the component per module approach. Now when using Angular Material we only import the module for the components we are using. Keeping the size of the Angular Material library we add to our applications down to a minimum.
So what is the best approach? Well, with all things it depends on your circumstance and the type of application you are building. For large enterprise application, where you are building a set of Angular applications across an organisation. There maybe a need for a limited shared module that has some functionality that is needed for each application. If you have a design system for your applications that give each app the same UI then the module per component approach is extremely useful. Just as it is in Angular Material.
As Angular continues to grow and being used in more and more large enterprise applications, the best practices for how to manage and make best use modules will continue to mature. So it is still something that needs to be researched into and as Angular developers we need to document the pros and cons of these different approaches so other developers can learn from what we’ve found when they come to deciding what their approach to modules is going to be.
I bought a licence for iA Writer ages ago, but never really used it that much at first. I was looking for a writing application as I was planning to start writing a eBook. So I looked around at the various options, there was Ulysses, Bear Notes, Evernote and iA Writer.
I knew I wanted a Markdown writer because Markdown is becoming a universal way of writing content on the web now. Not only is it used for things like GitHub, but now blog posts can be written in it, and even eBooks can be written using Markdown.
So this excluded the idea of using Evernote for a writing application. It is a great note taking application, ideal for keeping notes, ideas and plans together and the search in Evernote is amazing, but the writing and formatting within Evernote is not as good as it could be, hopefully it is something they add soon.
I did have a look at Ulysses for a bit, I downloaded the demo version and explored using it. Some of the features I really liked, like the word count target and the focussed UI when you are writing are both great features. I did find having to buy a monthly licence a problem because I was already paying for a yearly subscription to Evernote, getting another subscription on top of Evernote just for a writing application? I just couldn’t justify the cost to myself.
Then I looked at Bear Notes as I thought it would be both a replacement for Evernote and a writing application. It seemed great on paper, I could create notes as I did in Evernote, I could write quickly and easily using the Markdown features Bear supports, it seemed ideal. But after a while I found that it was becoming a mess, well the way I was using it. With out the structure of Notebooks, and Stacks that Evernote gave you I soon had things all over the place and I found that I missed the powerful search that Evernote provides.
In between going from Evernote to Bear and back again, I had a look at iA Writer, it was cheaper to buy than Ulysses. There was a one-off payment, no monthly subscription so if I bought it and didn’t use it much there was just the one payment instead of having a subscription for a service I didn’t use. It had versions for Mac, iPad and iPhone all synced through iCloud. All my content was stored in my iCloud account, which I liked and the UI was well thought out. So I paid for a subscription licence and installed it, then used it a couple of times and then left it. I suppose I got caught up in the online hype of Bear, so went onto trying that out.
After going back to Evernote I remember that I had iA Writer installed so I fired it up and found that solved a lot of the issues I had. Again it had the Markdown support, I can export to WordPress directly so I can write blog posts in iA Writer. I can tag things and use folders, so I can use it for more than blog posts, I can write the long form in it (I’m currently writing my Angular book using it) I can export in different formats if I want. The syncing between devices is really good. As soon as I stop writing on one device I can carry on using another device to continue on the same file. It works really well on iPhone, iPad and Mac. It is really good. I can export directly into WordPress and/or Medium if I wanted to, I can export to PDF and Word formats as well, which makes my blogging workflow a lot smoother.
Having all your content stored on your iCloud account is a nice feature, so if for any reason iA Writer stops, I have all my content for any books or blog posts I’ve written stored as Markdown files in my iCloud account.
So in the world of writing application I think iA Writer is a hidden gem, it might not be getting the praise of Bear Notes or the large number of users as Evernote, it still a very good alternative.
This week has been manly working on getting a first internal release of the client project. So as part of the internal team I’ve been working on a lot of small CSS changes to the Ionic application, giving it that extra polish to make it look as close to the original designs as possible.
What Went Well
The internal app is getting close to being released to real users, even though internal users it’s going to be good to get the app on devices and used by non-developers hands.
Book writing is still going, half way through and it’s clear that writing a book is a slog after a while. Being at the halfway point must be the toughest part. But it has been a great learning experience getting into the depths of Angular.
I also emailed Pete Bacon Darwin, who is a member of the Angular core team, after I heard an interview with him on the My Angular Story podcast. In the podcast he mentioned how working on open source has really helped him and opened a lot of doors in this career for him. So I thought I’d email him to say how I enjoyed the interview and if he had any advice on getting started with open source. And amazingly he emailed me back and said that there are so many ways to get involved, working on projects, writing documentation, answering others questions on Stack Overflow.
So after finishing the book I’ll be working on getting into a few open source projects.
What didn’t go well
Not much really, has been a good, but quiet week. I need to start working on using social media more in order to start promoting myself and business getting ready for my next project.
The business management of my freelance business needs to be something I need to focus on a bit more. Instead of going for one contract to the next, I want to build a lifestyle business instead of having a Limited company for contracting purposes.
As part of this I have been trying to be better organised with both work and personal life. So trying to work on that, but not there yet.
Things I’ve Read
I have read many articles this week, but I have been watching a few YouTube videos. One series in particular is the [Overpass](https://www.youtube.com/user/OverpassApps) Apps channel. Where the owner of Overpass Apps makes a daily video about running a mobile app development business.
