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.

RequireJS to WebPack

There are several articles on the web that discuss converting a site developed using RequireJS to WebPack. However, in several of these articles, there are assumptions in place that didn’t fit my scenario and had no instructions on how to handle a few of the modules in use within a project that my company needed to convert. These articles were a great place to start, but then found myself really getting to see some of the power available to you when using WebPack with an ASP.Net 4.6.2 MVC application that utilizes ASP.Net core 2.2 as well.