KnockoutJS Interview Questions

KnockoutJS Interview Questions

Q1) What is Knockout JS?

Ans: Knockout JS is a JavaScript library based totally on MVVM (Model View ViewModel) pattern that lets you create a wealthy, responsive show and editor person interfaces with a clean underlying data model.

Knockout JS is a small mild weighted JavaScript library this is usually used for designing a SPA.

Q2) What are the Features of Knockout JS?

Ans:

Features of Knockout JS

• Automatic UI Refresh
• Dependency Tracking
• Support all modern browsers
• Template Binding
• Declarative Binding
• Compact Size less than 20 kb.
• Written in Pure JavaScript
• Easy to implement

Q3) What are the types of data binding supported by Knockout JS?

Ans:

• Two-way binding
• One-way binding

Q4) Define dependency tracking.

Ans: The KnockoutJS will automatically update the UI (DOM) when your data model is changed.

Q5) How is Knockout JS used in context properties?

Ans: Context Properties used in KnockoutJS

• $parent property
• $index property

Q6) Define $index property.

Ans: $index property returns the index of the current context item in the array.

Q7) Define $parent property.

Ans: $parent property allows us to examine the parent of an object.

Q8) Define observable in Knockout JS.

Ans: Observable is a property of knockout js that contains the view model. This property is bound with UI (View) in two-way binding.

Q9) What is observable Arrays in Knockout JS?

Ans: The Observable cluster is KnockoutJs properties that contain the thing gathering in the view model and this property is tied with UI (View) in two-way binding.

Q10) What are the difference between KnockoutJs and MVC?

Ans:

Q11) How does JQuery differ from KnockoutJs?

Ans: 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 applications in a simply manner.

Q12) How KO intended to compete with jQuery or work with it?

Ans: 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 behaviours, 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.

Q13) How does dependency tracking work?

Ans: 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. 

for example, 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.