Question

_this vs this in Coach View javascript code, why is it needed?

Answer 1

In a coach view's JavaScript, this is the coach view object only while the framework calls your handler (load, view, change, unload, or a control event). As soon as you go into a nested function - a callback of an Ajax service, a setTimeout, a DOM event listener, an array method - this is rebound by JavaScript's rules to whatever called that function (window, the DOM element, undefined in strict mode). var _this = this; captures the view in a normal variable that closures can see:

// load handler of a coach view
var _this = this;                                   // capture the view
this.context.element.querySelector("button").addEventListener("click", function () {
  // here "this" is the <button>, not the view
  _this.context.binding.set("value", "clicked");    // correct
  _this.ui.get("Status").setText("saved");          // works; this.ui would be undefined
});
setTimeout(function () { _this.refresh(); }, 1000); // same reason

Modern alternatives that do the same: arrow functions keep the lexical this (btn.addEventListener("click", () => this.context...) - fine in BAW 20+ coaches, not in old browsers), or fn.bind(this). The UI Toolkit avoids the problem in control events by passing me (the control) as an argument - use me there instead of this (question 2659).

Rule: at the top of every coach view handler that uses callbacks write var _this = this; and never use bare this inside a nested function.

References

• BAW documentation - coach view JavaScript (event handlers, context)
• BPM UI Toolkit - me / this / page