Search code examples
sapui5sap-fiori

Difference Between this.getView().byId(), this.byId(), and sap.ui.getCore().byId()

Can I know the difference and performance when I use:

const myControl = this.getView().byId("myIDhere");
const myControl = this.byId("myIDhere");
const myControl = sap.ui.getCore().byId("myIDhere");

Which of three is best to use to perform operations on control when I use XML views in UI5 apps?

Solution

  • Difference between this.getView().byId and this.byId

    According to the source code of this.byId:

    Controller.prototype.byId = function(sId) {
  return this.oView ? this.oView.byId(sId) : undefined;
};

    ... this.byId is just a shortcut for this.getView().byId. They both can be used to access controls defined in the view. E.g.:

    <mvc:View xmlns:mvc="sap.ui.core.mvc" xmlns="sap.m">
  <!-- ... -->
  <Panel id="myPanel" />
  <!-- ... -->
</mvc:View>

    myControllerMethod: function (/*...*/) {
  const thatPanel = this.byId("myPanel"); // === this.getView().byId("myPanel")
},

    What about sap.ui.getCore().byId in application development?

    The API sap.ui.getCore().byId awaits a fully concatenated global ID that is registered in the UI5 element registry which is why you cannot simply exchange this.byId with sap.ui.getCore().byId if the target control is defined as part of a view.

    sap.ui.getCore().byId("someComponent---myView--myPanel"); // <-- Don't!

    Generally, sap.ui.getCore().byId should be avoided when developing UI5 applications that would be added to an app container such as the SAP Fiori launchpad (FLP).
    Avoiding sap.ui.getCore().byId implies that, when instantiating a new UI5 element in JavaScript, the API createId("newPanel") should be used with "newPanel" as a local ID instead of global:

    new Panel({
  // Given this === Controller or View instance
  id: this.createId("newPanel") // makes it accessible via this.byId("newPanel")
});

    From the topic "JavaScript Coding Issues" section "Don't create global IDs":

    [...] you must not create stable IDs for your controls, fragments, or views in OpenUI5. Doing so might result in duplicate ID errors that will break your app. Especially when running together with other apps, there could be name clashes or other errors.

    Use the createId() function of a view or controller instead. This is done automatically in XMLViews [...]. The createId() function adds the View ID as a prefix, thus recursively ensuring uniqueness of the ID.

    If you really have to use sap.ui.getCore().byId, which is deprecated since UI5 1.119, require sap/ui/core/Element and call Element.getElementById (since 1.119). One valid use case that comes to my mind here is when accessing the currently focused control, of which the ID was retrieved via getCurrentFocusedControlId() until the UI5 version below 1.119. Since 1.119, current focused control can be accessed via Element.getActiveElement().

    For all other cases, there are often better approaches in application development. You might, for example, want to listen to routePatternMatched or patternMatched, then access the element via oEvent.getParameter("view").byId rather than trying to access the same element via the global element registry.

    More about IDs

    Favor model-first approach over byId

    Instead of accessing the controls directly via byId, consider manipulating the UI via data binding. Changes in the model will be reflected in the UI automatically, and, if two-way binding is enabled, user inputs from the UI will be stored in the model directly.

    SAP Fiori elements guidelines

    When developing Fiori elements extensions, make sure to adhere to the documented compatibility guidelines, especially regarding byId:

    [...] Don't access or manipulate controls, properties, models, or other internal objects created by the SAP Fiori elements framework.
    [...] Must not access any UI elements that are not defined within your view extensions.

    ⚠ Caution
    If you do not adhere to this guideline, your app may not work with future SAPUI5 versions because SAP Fiori elements might exchange controls for new ones that have a different API.