KnockoutJS Interview Questions
What is Knockout JS?
What are the Features of Knockout JS?
Features of Knockout JS
- Automatic UI Refresh
- Dependency Tracking
- Support all modern browsers
- Template Binding
- Declarative Binding
- Compact Size less than 20 kb.
- Easy to implement
What are the types of data binding supported by Knockout JS?
Define dependency tracking?
The KnockoutJS will automatically update the UI (DOM) when your data model is change.
How Knockout JS used in context properties?
Context Properties used in KnockoutJS
- $parent property
- $index property
Define $index property?
$index property returns the index of the current context item in the array.
Define $parent property?
$parent property allows us to examine the parent of an object.
Define observable in Knockout JS?
Observable is a property of knockoutJS that contain the view model. This property is bind with UI (View) in two-way binding.
What Is observable Arrays in Knockout JS?
The Observable cluster is KnockoutJs properties that contain the thing gathering in the view model and this property is tie with UI (View) in two way binding.
What are the difference between KnockoutJs and MVC?
|KnockoutJs is a MVVM pattern||MVC is a design pattern|
|It work like connected mode||It work like disconnected mode|
|It supported two types of binding|
One-way binding , two-waybinding
|MVC supported only one-way binding.|
|UI part automatically update when your data model update|
In MVC, not update UI automatically when your data model update. Need event to call data model and update it.
|Model part is not directly bind with the view page. Models directly bind with the view-model and view-model directly with the view page.||Model parts directly bind with the view page.|
How JQuery differ from KnockoutJs?
The KO does not depend on the jQuery library, but we can use jQuery at the same time. Using KO you can handle client and server side application in simply manner.
How KO intended to compete with jQuery or work with it?
jQuery is an outstanding replacement for the clunky, inconsistent DOM API we had to put up with in the past. jQuery is an excellent low-level way to manipulate elements and event handlers in a web page. KO solves a different problem.
As soon as your UI gets nontrivial and has a few overlapping behaviors, things can get tricky and expensive to maintain if you only use jQuery. Consider an example: you’re displaying a list of items, stating the number of items in that list, and want to enable an ‘Add’ button only when there are fewer than 5 items. jQuery doesn’t have a concept of an underlying data model, so to get the number of items you have to infer it from the number of TRs in a table or the number of DIVs with a certain CSS class. Maybe the number of items is displayed in some SPAN, and you have to remember to update that SPAN’s text when the user adds an item. You also must remember to disable the ‘Add’ button when the number of TRs is 5. Later, you’re asked also to implement a ‘Delete’ button and you have to figure out which DOM elements to change whenever it’s clicked.
How dependency tracking works?
It’s actually very simple and rather lovely. The tracking algorithm goes like this:
- Whenever you declare a computed observable, KO immediately invokes its evaluator function to get its initial value.
- While your evaluator function is running, KO keeps a log of any observables (or computed observables) that your evaluator reads the value of.
- When your evaluator is finished, KO sets up subscriptions to each of the observables (or
computed observables) that you’ve touched. The subscription callback is set to cause your
evaluator to run again, looping the whole process back to step 1 (disposing of any old
subscriptions that no longer apply).
- KO notifies any subscribers about the new value of your computed observable.
So, KO doesn’t just detect your dependencies the first time your evaluator runs - it redetects them every time. This means, for example, that your dependencies can vary dynamically: dependency A could determine whether you also depend on B or C. Then, you’ll only be re-evaluated when either A or your current choice of B or C changes. You don’t have to declare dependencies: they’re inferred at runtime from the code’s execution.
The other neat trick is that declarative bindings are simply implemented as computed observables. So, if a binding reads the value of an observable, that binding becomes dependent on that observable, which causes that binding to be re-evaluated if the observable changes.