DEV Community: Ronan Connolly 🛠

Why NX == Modern Web Development

Ronan Connolly 🛠 — Fri, 20 Aug 2021 10:23:44 +0000

I am in the process of setting up a Monorepo which will contain many large apps and libs, and I've absolutely fallen in love with NX.

I've done a lot of research into NX the past few weeks and here's what I've found.

The benefits I see in migrating to Nx:

Upgrading Angular -- The "nx migrate" commands from reading, seems to make upgrading your version of Angular much easier by letting you complete the migration in a multi-step way instead of all at once: https://nx.dev/latest/angular/core-concepts/updating-nx
1. Another benefit here is that you can upgrade all your libraries/apps at the same time, rather than having some lib fall behind a version of two of Angular, or managing getting all the repos upgraded separately, then linking them and finding more issues you need to resolve due to the upgrade.
Only run commands on affected project with "nx affected" -- Lets you auto test all libraries that have been affected by updating one library, on the pipeline this will be very handy as all affected libraries will auto build, and you can have your CD auto publish too.
Reduce redundant computations with the computational cache -- is great at when you are constantly running nx affected test, build, etc commands you don't want to re-run the same tests when the code hasn't changed.
The tags are great for enforcing code boundaries -- You can make sure certain libs don't depend on other libs, especially great when you have lots of less UI focused people in the code base as they will get a Lint error instead of a big PR comment (after they've worked so hard on a feature).
The mindset behind NX -- In my mind NX equals modern Web development, as in they are always pushing for the latest and greatest technologies, tooling, and creating extra tooling to help remove redundant repetitive tasks, and this is the default! Just looking at the defaults you can see this: ESLint vs TSLint, Cypress vs Protractor, Jest vs Jasmine/Karma, Prettier set up for formatting.
1. Along the same lines, it helps you push your argument to use new modern technologies -- As once people in your organisation can see the efficiency that NX provides they'll start to have confidence in it's defaults (rather than Angular's) and the plugins it provides (example: see how easy it is to add a storybook with NX, let's introduce Storybook to our project! is a much easier sell with NX already in the org).
2. Same could be said for NGRX and the tooling it adds to help with adding and setting it up.
Helps you create your own automation -- by providing generators for creating generators (ng schematics) and executors (ng builders). NX makes it much easier to get started adding your own automation tooling (creating generators and executors).
The Dep Graph is a wonderful way of viewing how your project dependencies are set up -- The moment you create one manually it's out of date, so an auto generated one is very useful.
Encourages smaller more modular libraries & code reuse -- which should result in smaller bundle sizes as you won't libraries depending on other large libraries that has lots of code that is not needed. This also speeds up all your commands as you are testing, and building smaller libs.
NX Cloud allows you to share your cached command output across the team -- reducing redundant computations, which will speed up commands. It also comes with a nice GitHub bot for displaying build information. I'm not using this feature but I have tested it and it's a pretty cool idea which works well.
Setting global rules -- Example: setting the same ESLint rules across the project. Anytime I have to give a PR comment I consider adding a Lint rule to catch it so it's automated. I have a list of rules that I want in all my projects, it's been a pain adding them to every project. With a Monorepo I can add it once and all the projects have it. Another example is adding a Prettier pre commit hook, if you want to add it to all projects, that may be a lot of PRs.
Setting consistent standards -- Similar to my previous point, it's easier for example to have all your prefixes be named in a similar manner when you can do the update all at once and see all projects easily in one place.
Explorability & learnability -- Monorepos are fantastic for learning about how projects work and seeing patterns and strategies in action. Previously I would have all my apps and libs cloned down to a UI folder, I'd pull down their develop branch on all repos, then open that UI folder in VSCode, and do global searches to find examples. Monorepo removes this need as I have all the examples I need in one place. This is really useful for junior devs also.
The VSCode NX Console plugin -- is extremely useful in exploring all your CLI options for generating apps & libs, and running the different commands like build, test, serve affected libs/apps.
1. The auto dry run output makes it easy to understand what CLI commands are being created before initiating the command.
Migrating from an Angular project to an NX Workspace -- is well documented and there is tooling available. I haven't kicked off the process of migrating but from looking at the docs it looks fairly straight forward to turn an Angular app into an NX workspace, and migrating libs into it.
https://nx.dev/latest/angular/migration/overview
1. This command will migrate your project to an NX project: ng add @nrwl/workspace
2. They have great steps on migrating projects into the Monorepo too: https://nx.dev/latest/angular/migration/overview#migrating-libraries
You can use NX even if you don't use Angular -- It supports NestJS, React, and other frameworks too.

Foot Note

This is my current outlook on it and I hope it doesn't change. I for one find that NX solves many problems and frustrations I've had working on a very large number of large apps and libs.

Code Review Checklist ✅

Ronan Connolly 🛠 — Wed, 21 Aug 2019 15:18:13 +0000

CR (Code Review) checklists are a powerful tool.

They allow you to organise your own thoughts & intuitions on what you look out for when reviewing other peoples code.
Essentially they are a reflection from your point of view of what constitutes best practices, clean code, and good code quality.

Everyone has a checklist, most don't write it down.
By not writing it down it makes it hard to prioritise what's important.

❓ What should my checklist include?

Different people, teams, and organisations will have different items on their checklist, with their priority in differing orders, and the enforcement of each item at different levels.
And all of these things will change over time, especially during when deadlines are close!

Most of the time it's to do with code quality, design patterns, tests, formatting, and styles of programming.

My current CR checklist:

Below is an example of a CR checklist; this is my current CR checklist (and will most likely look different in a weeks time! 👀).

No bugs are being introduced.
If you find a scenario where the new code may be introducing a bug.
Methods & Classes have a singular purpose.
Remember SRP (Single Responsibility Principle) from Uncle Bobs SOLID principles.
Names should be meaningful.
Classes, methods, and properties should have names that describe what they do.
A method/class name should describe what it does, and a comment may be added to explain the why.

If you find yourself writing comments in your code, it may be a sign that you need to make the name more meaningful or break your method into multiple methods.
Naming should be consistent.
If you name one property: personCount, don't name the next property: countAnimal.
Follow current patterns.
Your project will develop certain patterns or ways of doing things over time.
If you are breaking the pattern you should have a good reason for doing so.
This is an example of a good time to self annotate your PR.
All method logic paths are tested.
Make sure that every branch of logic is tested.

There are some code coverage tools that will enforce this. If you are testing web components then trigger the method calls through the UI.
HTML Template logic is tested.
Make sure to test the logic in the HTML template, such as showing/hiding elements.

Most of these assertions should be done when testing the method, but sometimes you will need a specific test for some HTML template binding.
Project style & formatting standards adhered to.
Having consistent code formatting matters.
Imagine reading a book where the font-face, font-color, font-size, and line indentation was different in every paragraph.
It would be difficult to read, and incredibly difficult to update (maintain) and find typos (bugs).

This is often a good candidate for automation (The likes of Prettier and TSLint rules can help here).
Add documentation to the required methods.
Some teams will require everything to have a method doc, others will require only public methods, and some will have it as optional for complex methods.

You can automate this check and fail the build if certain methods are missing documentation. TSLint can help enforce JSDoc rules: https://www.npmjs.com/package/tslint-jsdoc-rules
Documentation is meaningful.
A method/class doc comment should be the why not the what.
The method/class name should be self-descriptive, leaving the doc to be the why.

Avoid this kind of what doc: "The add method". Instead, state the why or don't add the doc at all.

⭐ Benefits of writing it down

Prioritise important items.
By writing down what you look out for when reviewing code, it allows you to prioritize what's important.
You may find that most CR comments are to do with formatting and styling issues; these types of comments may be at the bottom of your CR checklist and hence should either be less strict or should be ideally automated.
During certain times in a project, delivery takes precedence over code quality and as such, you can be less strict on items lower down in the list.
Share the checklist with colleagues.
They may be missing items that you have and vice versa.
They can give their view on why particular items should be at different priorities.
Gives confidence and passes on intuition to juniors.
Junior engineers won't have the intuition or experience to know what to look for when reviewing code, and often the case they won't review code or will just approve as they don't want to give an incorrect comment.
By having a checklist it gives juniors the confidence to give CR comments.

🤷 When to use the CR checklist

When reviewing other peoples code.
Instead of including all items in your initial look through each file, you could instead flick through the files checking for the top 5 items, and then flick through the files again with the next 5; this can help with really big PRs, or WIP (work in progress PRs); as they can become overwhelming.
When writing your own code.
As you write your own code, always keep your CR checklist in mind; like a little code quality angel is watching over you.
Ideally, you would print out your CR checklist and stick it up beside your monitor (👼 Angel doodle required).
When you open your code for review.
Review your own code before sending it to others.
Often you are in such a scramble to get your feature working and your tests complete, that you miss basic stuff.

📝 Summary

This is my current CR checklist and it will most likely be different in a weeks time.

Treat it like an ever-evolving document that reflects your vision of code quality.

💭 Thoughts

What's on your checklist?
Have I missed anything on my list that you think I should add?
Do you disagree with the priority of my items?

Please comment with your thoughts below! 🙃

Why start a blog?

Ronan Connolly 🛠 — Sun, 18 Aug 2019 14:50:34 +0000

Previous attempts

I've tried this blogging thing here and there over the years.
Usually, I would end up blogging about a variety of things: food, nature, technology, poetry, etc.
To be honest, this is probably why I didn't continue, it wasn't niche enough.

Now that I've read enough blogs, I have a better idea of how to do my own.
My niche is Front-End software development, and this is what I will be blogging about.

I'll leave my business and finance knowledge to separate blogs if I wish to write articles on them.

Why create a blog?

I want to use this blog as a learning tool. Everything I blog about will be something I've just learned.
The great thing about this is that I'll be writing in a way that is beginner-friendly. Once a concept has clicked for me, I'll summarize my learnings for you to digest.

As such there may be errors in my articles, and if there are and people point it out, that's great. I can then learn from my audience!

What to blog about?

I'll be covering the niche of Front-End software engineering.
This will cover:

Vanilla JS
Angular & everything within (RxJS, TS, AgGrid, Sass, etc)
Productivity tips
Getting a job
Digital nomadism
Tools, techniques, and workflows
UI Design

Audience

I'm aiming this at the Front-End community and will be sharing on Dev, Twitter, LinkedIn, and my personal site (https://ronanconnolly.dev/blog).

To be honest, I'm writing this for myself, and if others learn from it that's great!

But I am very excited to see what this Dev.to community is all about ☺️