Harmonious Stylesheets and Inline Styles in React

Styling React components seems to be one of those things where there are a lot of solutions (libraries) emerging that try to solve the problem of how to use only inline styles in JavaScript sustainably. To me, it seems that this problem has been invented and can easily be avoided; and introducing a new library or tool is only adding to the complexity and cognitive overhead of your app. Many times it really is just better to stick with plain ol CSS stylesheets.

Both traditional stylesheets and inline styles have their place within React applications. By using them harmoniously you can have the best of both worlds.

Homogeneous Pipelines with Docker

Continuous Integration Build Pipelines are a dirty, nasty place. What usually starts out as a couple of simple tasks or bash scripts inevitably ends up as a heap of scripts, Gradle/Rake/Maven/(insert build tool here) tasks, and manually configured jobs held together with a thin layer of Elmer’s glue and Scotch tape.

Why? Partly because modern applications are complex; even simple stacks use multiple languages and tools. And partly because developers are lazy, and sometimes hesitant to “mess with the pipeline.” I don’t often see the amount of rigor in cleanliness applied to them as to other parts of the codebase, leading to unnecessarily complex and unfortunately tangled build pipelines.

So, my current team attacked this head-on using a great piece of technology: Docker! Using Docker as our sole interface to running things in our build pipeline, we sped it up, simplified it, and lived happily ever after.

To give credit where credit is due, the implementation of this pattern was spearheaded by my colleague Amber Houle.

How your 'Mother' can help you 'Build' cleaner unit tests - Part III

We ended Part II with an inner Builder for Address, which forced us to revert to specifying seemingly arbitrary values in each test that needed to build an Address.

What I’ve usually seen at this point is pulling the Address objects into constants in each test class. As the test suite grows, the number of private static final Address WHATEVER_ADDRESS = ...; grows and grows. Doing that makes it hard to keep control over your test data, especially in a large codebase. A minor change to Address, such as a new invariant or an added field, could cause cascading changes to keep all those objects valid.

To avoid that, the next step is actually a very simple one, and boils down to centralizing the definition and creation of an Address with an Object Mother.

How your 'Mother' can help you 'Build' cleaner unit tests - Part II

In Part I, we created a separate Builder class in an attempt to move away from a constructor with too many parameters. In the process, the separate Builder ended up taking on the additional responsibility of supplying default values, blurring the line between a Builder and Factory.

Though a step in the right direction, it didn’t actually fix any of the Address constructor’s original problems, unfortunately. Oops. Other classes can still call it directly, meaning all of the risks of having a method with multiple parameters of the same type are still there, and we have another class in our system to maintain.

What we need is a strictly controlled way of creating Address objects that can be accessed by test code and prod code that is decoupled from the current constructor and it’s baggage.