Revisiting KnockoutJS - v3.2 cherry-picks
| 5 min read
In case you missed it
It's been awhile since KnockoutJS released it's latest stable iteration 3.2. It was a real slow paced development however it introduce some of the most wanted features KnockoutJS was missing since the beginning. KnockoutJS community didn't make any fuss over it's release. Hence, ICYMI article.
> Feature-centric release
3.2 is purely feature-centric along with some minor bug fixes and patches. Find detailed change log on github.
What's new?
KnockoutJS 3.2 comes with several new features worth taking a look. If you are serious about making your HTML code more readable and avoiding memory leaks, you should definitely refactor your code and use these features.
Pure computed observables
Although ko.computed is one of the powerful key features of KnockoutJS. In the same way, ko.computed, if used without care, is prone to memory leaks which can heavily impact your application's performance. Fortunately, there's a fix for that.
]
Pure computed variables, defined as ko.pureComputed, do not maintain subscriptions to its dependencies when it has no subscriptions at all. Resulting improved performance and prevention of memory leaks. Pure computed variable is in sleeping state when there are no subscribers, which means it pauses the evaluator. It enters in to the listening state as soon as there is a subscriber resulting immediate invocation of an evaluator.
I have customized the default example from pureComputed documentation in order to demonstrate the exact difference between ko.computed and ko.pureComputed.
In above example, you will find pureComputed function executes only when the view including that variable is visible unlike regular ko.computed variable which is executed on every key hit. Huge performance improvement, isn't it?
When and when not to use Pure computed observables?
Pure computed variables are useful when you are sharing data between temporary views models and models. Pure computed variables can be very useful while working on single page applications using KO. So far pure computed variable is kind of win win feature. But wait, It is not supposed to replace ko.computed entirely. You must not use pure computed variables where you are using computed observable to run callback which is dependent on multiple observables. e.g. change tracking and auto saving forms.
Well there is a lot to talk about how dependency tracking works. It's impossible to write it in an single article that covers multiple features. Head over to pure computed documentation if you want to learn more about it.
Components
Web Components are already proving to be the next big thing and the future of web. KnockoutJS "Components" are heavily inspired by Web components. Components are a powerful, clean way of organizing your UI code into self-contained, reusable modules. Which results improved scalability of web app developed on top of KnockoutJS.
> Knockout apps are now scalable
KnockoutJS always lacked the modular development out of the box. Yes, there were helpers and extended frameworks available (see DurandalJS) but many of the developers do prefer out of the box feature over extensions.
Some key features of Knockout components -
- Contain own view, can have own viewmodel (if required at all)
- Accepts parameter, can write back new value.
- Can be preloaded or loaded asynchronously on demand.
- Reusable across multiple projects Example :
Custom elements
While component binding improves reusability of an application, it's HTML markup still is sort of inconvenient to read. Let's take a look in above fiddle.
| <div data-bind='component: { | |
| name: "message-editor", | |
| params: { initialText: "Hello, world!" } | |
| }'></div> |
It still doesn't look good for human eyes. With custom elements, instead of writing above markup, you can write this -
| <message-editor params='initialText: "Hello, world!"'></message-editor> |
Custom elements make the markup look much cleaner, easy to read and most important, it is valid!
More documentation on custom element
textInput binding
The "value" binding in KnockoutJS does great job but there are some limitations with "value" binding.
"value" binding has limitations where the observable value does not update immediately in following scenarios -
- Browser auto filling (such as chrome)
- drag drop value into text box
- selecting browser injected dropdown suggestions.
"textInput" binding solves such problems. You can use "textInput" binding with
< input >and< textarea >elements. It works exactly like "value" binding. If you still want to read more about how to use it, go through the documentation.
Three point three, long way to go.
Well, there is no solid information about new feature implementations and bug fixes in upcoming version v3.3 (version number might change in future). But I have managed to get some idea about what's going to change and being added in v3.3 by looking at the Github repository itself. The feature set being listed below might change in future. It depends upon the contributors
- Event on completing update of DOM element.
- Custom bindings isolated to components or binding context.
- Add caching to sleeping computed variables
- Support observable values for new valueAllowUnset option It looks like the next iteration will be having very less set of features and more of bug fixes and patches.
To conclude, KnockoutJS still remains a small library that suffice multiple way data binding needs. Again, I would not use it for developing large scale business applications as it still has some limitations. However, for applications that do not require heavy data manipulation and processing at front end, KnockoutJS still remains on top for me.
I am working more on AngularJS these days but KnockoutJS still remains one of my favorite frameworks to work on. It suffice all the needs of small web applications. With components like features, it has become more scalable and reusable.
Hope you liked the excerpt,
Peace, RP