Building Maintenance Processes part 3: Operations Hello World
This is part of a multipart series of my deep dive into re-learning how to write production code for Octopus Deploy, which I haven’t done since 2016. In Part 1 I got familiar with our development environment, and in part 2 I updated the URL routes to make way for my brand new “Operations” page.
Here’s what I had when we left off. The deployment process links were working again, but nothing rendered when you click the Operations link:
Adding the Operations list view
The Deployment link lets you edit the deployment process, and the assumption is that a project only has one deployment process. But a project could have many “operations” processes: backing up the database, triggering a DR failover, removing a node from the load balancer for routine maintenance, whatever you need. So I figured that clicking on Operations would need to take you to some kind of list page that lets you add and remove these processes.
I added a new ReloadableRoute
(whatever that is) and pointed it to a new component I was going to create, OperationsProcessList
:
So far, so easy.
Next, I needed to create the new OperationsProcessList
component. I could create it from scratch, but I am lazy, so I decided to copy it from an existing component. I picked DeploymentProcessOverview
because I figured it might be a good starting point.
Yikes, this is a big component! The file is 528 lines long!
That felt very big to me. I dug out a copy of the AngularJS 1.0 code for the controller for same area, which was written in 2012 and maintained through to mid 2017. It was merely 485 lines long. Hah!
React sucks. Knew it.
I copied the component, and renamed my copy to OperationsProcessList
and started deleting code until I got a simple “Hello”. Along the way, I looked at the code I was deleting. I realized that I’m not just looking at a controller, but at the equivalent of the view as well. Of course, I knew from the outside that React worked this way, but it didn’t really sink in until I read the class.
I found the HTML view for the same screen from the Angular 1 days. It was 197 lines long. I guess React isn’t so bad.
Some parts of this component make a lot of sense as I scan past it, like this:
Or even this:
Then there are parts that seem like ceremony and fluff and detract from the readability. Like it’s just there to make the code look “important”. Example:
Whatever this does, I’m sure it’s something to do with React or state or something, and maybe protecting private classes, or who knows what. Then again, maybe I should take 5 minutes to actually read about React or whatever this is before I keep pretending to be a programmer :-)
Having now looked in detail at exactly one React component, I think I’m sufficiently expert enough to draw the conclusion that React is easier than AngularJS to reason about, but more difficult to read. With AngularJS’s views I quickly get a sense for how something is structured, that seems less obvious with React. This might be a good thing though.
I kept trimming my new component down until I got a Hello World:
Now to reference my component TSX file from the file that defines the routes. Wait, what’s this? Nice!
And here’s the final result:
The biggest difference I’m noticing — and I don’t know if this is a general React thing, or an Octopus thing — is that you have to dig a long way down to find any real HTML.
In AngularJS, you’d open a view, and you’d see 93% regular HTML, with a few directives mixed in. You might need to go find the CSS or view a directive, but for the most part the HTML was either in plain sight, or hidden one file away.
With React — and again, maybe this is just us — the team have spent a lot of time making tiny, self-contained components that can be composed together. So one component uses another, which uses another, which uses another, and then eventually you find the HTML.
I know this was deliberate. With a big AngularJS application, customers often complained that some screens put the save button in different places, and some screens were just inconsistent by small amounts that added up and made the whole thing feel a little unpolished. I’m sure this approach makes the UI much more consistent. I’m keen to see whether it makes it harder for me to build a new feature without having to refactor the object model of these components.
Summary
Takeaways from this session:
- The TypeScript and VS Code experience continues to be impress. Front end dev has certainly come a long way since plain old JavaScript with AngularJS and WebStorm.
- React isn’t as bad as I thought.
- I’m starting to quite enjoy all of this.
Next I need to figure out how to load a list of custom processes. I’ll probably need to write some back end C# code to prepare the object model for it too.