Skip to the content.

Microservice first?

One argument I’ve heard for building microservices from the beginning is that, teams often lack discipline to enforce modularity and separation of concerns. A monolith usually turns into a “big ball of mud,” which is a problem. Starting with microservices forces teams to think about their module boundaries up front.

Read More

React.js, JSX and readability

React.js is the new hotness in front-end JS frameworks, although I am having a hard time getting excited about it. I’m reacting (pun intended) mostly to readability concerns with JSX. I also have issues about slicing everything up into granular components, but that’s a topic for another day.

Read More

Node.js with SQL Server

Yes, you can use SQL Server with Node.js. I added a Gist to show how it could work. I didn’t get to connection pooling or transactions, just enough to get a general feel.

Read More

Cost of supporting old browsers, revisited

As I was starting to pick up blogging again, I came across a post I wrote over 10 years ago about having to put up with older browsers. It was kind of funny to see how back then, I was excited about IE 6 and this new thing called AJAX. Also, that back then, it seemed like a novelty to prioritize support for different operating systems and browsers based on real usage metrics.

Some things haven’t changed: old browsers are still a pain, and there’s still a sizeable number of users in various industries stuck on Windows XP and therefore IE8 – the US Navy is one of the more public examples.

Read More

KnockoutJS implicit subscriber via ko.computed: Elegant, yes. Readable, maybe?

I have seen code that looks like this with KnockoutJS a few times, using a ko.computed as a substitute for ko.subscribe on multiple observables:
this.x = ko.observable();
this.y = ko.observable();
this.updated = ko.observable(false);
this.tracker = ko.computed(function() {
}, this);

The tracker function is equivalent to
var callback = function() {

this.x.subscribe(callback, this);
this.y.subscribe(callback, this);

The pattern with ko.computed is compact and elegant. A single function tracks multiple observables, and fires an event when one of the tracked observables changes.

My challenge with this pattern is the readability, though.  A non-expert KnockoutJS user may have a hard time figuring out what's going on because the intent is not obvious from the code.  The pattern is exactly the opposite of basic ko.observable usage.  Simple cases like "fullName = firstName + lastName" use the tracked observables to calculate and return an output, and have no other side effect.  In this case, the tracked observables' values aren't used, there is no output, and there are side effects.

On the other hand, a KO expert who understands how ko.computed tracks observables might find this pattern is more readable than the alternative.

So I'm thinking, it's ok to use this pattern, but with some conventions to help prevent beginners from getting too confused.  Some thoughts:

  • Use a naming convention to distinguish this ko.computed pattern from others.  For example, onSomethingChanged or trackSomething.  This way the name sounds like an event listener. 
  • Don't mix the ko.computed patterns - either return a value or have a side effect, but not both
  • Within the ko.computed body, make a clear separation between setting up observable tracking and the action to fire when something changes.  
  • Consider separating the code comments - this is one of those times when code comments are helpful to explain something that might not be obvious from the code itself.
For example:

this.onInputChanged = ko.computed(function() {
var trackedObservables = [this.x(), this.y()];
// action when one of trackedObservables changes
}, this);

KO documentation on computeds:

Read More