An Opinionated Approach to KnockoutJS Components

In the prior post, I mentioned my organization began to use KnockoutJS within an application we have developed for one of our clients. You can get a little more background on the project by reading my prior post.

When I first started creating components with KnockoutJS, there wasn’t any specific pattern established for handling state, properties, computed values, subscribed listeners, and event bindings. In hind-site, it began creating challenges when maintaining code as each developer had a different way to organize their code.

I took some time about 18 months ago and began to define a pattern that could be used when developing components and view models within the application. The hope was to improve the quality of the code produced and to help when maintaining the code in the future. Having unified patterns can help teams in several ways, from reviewing requirements to final code reviews. It can produce a common vocabulary and starting point for adding or updating the functionality of the application, and can help on-board new developers to the project.