During the session several questions have been raised which I want to discuss again here in this blog post and elaborate a bit more in detail here.
Thanks for the overall positive feedback. It really shows that we are heading in the right direction and finally benefit from a well harmonized and modern browser stack of today for the development of UI5 applications. With the IE11 de-support we now can get rid of most of the Polyfills and finally removed them with the 1.89 version.
Moving to asynchronous APIs is important to unlock the browser and to benefit from a best possible performance. Every synchronous request happening as a result of our legacy synchronous API will cause to block the browser and prevent any other action – be it rendering, event processing, request processing or anything else. It is really essential that we continue to evolve the UI5 framework towards more asynchronous APIs, to rollout those APIs so that you can start using them.
Q: Async loading of XMLViews should be declared in the manifest for the FLP?
A: Before the introduction of the async createContent of the Component, the XMLView needs to be explicitly declared as async in the manifest.json. Otherwise, the Component will load and create the view synchronously. When using the new async createContent API available with UI5 >= 1.89, the async flag in the manifest.json is not necessary anymore, as the views will be created async by default. (Example: http://plnkr.co/edit/y6eunAe820hVsWKb?preview)
UI5 Web Components
The UI5 Web Components will become the layer which will be used to write agnostic UI elements in future. This allows to reuse the UI elements in UI5 and as well in any other web UI framework such as Svelte, Vue, React or Angular. This also ensures that our UI elements can also be used with any other emerging web UI framework of the future, but we will also ensure and take care to create the best of breed integration of Web Components in the UI5 framework to benefit from the UI5 programming model.
Q: Is it possible to bind a Web Component against an OData Model (e.g. OData V4)?
A: No, this is not possible. Databinding is not part of the UI5 Web Components and requires e.g. the UI5 programming model which integrates the UI5 Web Components as via UI5 Control wrappers and thus allow to use databinding in UI5 to connect the UI5 Web Components with an OData V4 model.
Q: Will it also possible to generate wrappers for Non-UI5 Web Components?
A: Yes, this is the plan. The first iteration will focus on the integration of UI5 Web Components since they expose proper metadata (properties, slots and events) which are needed to generate the UI5 Control wrappers. For non-UI5 Web Components, e.g. plain Vanilla Web Components, the main question for the generation of the wrappers is how the metadata for this can be exposed.
Q: Do you already have a timeline for supporting generation of Non-UI5 Web Components?
A: Our focus right now is the availability of UI5 Web Components in OpenUI5/SAPUI5. The next step is to provide the tooling to allow the generation of UI5 Control wrappers and the libraries for Web Components built on top of the UI5 Web Components framework. The final step is to enable the integration of arbitrary Web Components via UI5 Control wrappers. Basically, Web Components could always be integrated manually, but the UI5 Control wrappers combined with the UI5 Web Components framework ensure a best possible integration into the lifecycle (rendering, databinding, …) of the UI5 framework.
Q: Is there a plan to further detail the documentation of the already existing UI5 Web Components? I’ve had some issues when creating tables for the first time, for example, and I believe it could be better detailed or to have more examples.
A: Thanks for your feedback. We will consider it and work to improve the UI5 Web Components playground in future to make it easier to get an overview on the available UI5 Web Components.
TypeScript Support for UI5
With the support of TypeScript for UI5 development, we will improve the development experience by getting better IDE support for code completion and type checks. Also the code completion will integrate the JSDoc into the IDE so that you can read directly what the modules and functions are about. For the TypeScript development we will focus on modern ES modules and ES classes and use a toolchain to transpile them back into UI5 runtime code. The sample project can be found here: https://github.com/SAP-samples/ui5-cap-event-app/tree/typescript/
Q: Is it also possible to use simply ES6 without TypeScript?
A: Yes, this is possible. ES6 APIs are supported since 1.38 onwards since UI5 always included proper Polyfills. Starting with UI5 1.88 and the de-support of IE11 it is allowed to use all ES6 APIs and ES6 language features. The UI5 Tooling also supports ES6 language features for bundling the preloads or self-contained bundles. In general, for ES6+ APIs and language features you should check the Browser PAM of SAPUI5 and caniuse to verify whether the APIs and the language features can be used. Regarding the ES modules and ES classes, Ryan Murphy created a custom Babel plugin: babel-plugin-transform-ui5 which converts the ES modules into UI5 AMD-like modules and ES classes into UI5 classes. The generated code is then compatible with current UI5 runtimes.
Q: When will TypeScript be fully available and the recommended approach for developing UI5 apps?
A: The TypeScript support for UI5 is planned around the UI5con ON AIR 2021 in June. But the availability of TypeScript doesn’t mean that this is the recommended approach to develop UI5 apps. Finally, it is one more option which can be considered for developers who prefer to use TypeScript. Overall, the TypeScript support definitely improves the content assist of the editor (like SAP Business Application Studio or Visual Studio Code) and thus lowers the entry barrier for UI5 development.
Q: Do we need to have the types in the project itself (like in the refence project: https://github.com/SAP-samples/ui5-cap-event-app/tree/typescript/packages/ui-form/types)? How will this be generated?
A: The types are generated by the UI5 build process with the UI5 TypeScript generator and shipped as a separate NPM package (@sapui5/ts-types). Those types have been used by the SAP Business Application Studio for the UI5 code completion and are available already today. Those types are not perfect, and we are working on improving the quality of the types by improving the JSDoc of UI5 and by enhancing the UI5 TypeScript generator. In addition, we will create a new types NPM package (@sapui5/ts-types-esm) which will provide proper support for ES modules and ES classes. The first drop of this NPM package is included in the UI5 CAP Event App for now, just for simplicity until we can also officially ship the ES modules types NPM package.
Q: Wouldn’t the UI5 TS declaration modules have the same issues regarding versioning as the UI5 code itself, if consumed from NPM? Or will download of the declarations be handled by the tooling (not sure if this can work)?
A: The versioning of the types will follow the versioning of the UI5 runtime. For each newer UI5 runtime version, we will also publish the NPM packages for the types. This allows to consume the NPM packages at least directly in your project. In future, we may also put the types closer to the UI5 libraries and ship them per library. Then using the UI5 Tooling would be beneficial to also integrate the types. Finally, this is not 100% clear yet.
UI5 Tooling Evolution
In the area of the UI5 Tooling, the extensibility plays a major role. As of today, the UI5 Tooling allows to extend the development server with custom middlewares and the build process with custom tasks. To allow to integrate even more functionality into the UI5 Tooling without being a bottleneck, it is essential to open up even more. Other potential places for extensibility are to allow for custom project types which allow to orchestrate the required build tasks and the possibility to add custom commands to add e.g. a deploy command.
Q: What about the deploy command from Fiori tooling? Will this change as well?
A: The SAP Fiori tools have their own CLI as of today. With the availability of the command extensibility, it can also be re-discussed to integrate custom commands from SAP Fiori tools into UI5 Tooling.
Q: Would it be technically possible to have Hot module reloading known from Snowpack or Vite in the UI5 tooling?
A: Hot Module Replacement can improve the development cycle significantly as the web application doesn’t need to be fully reloaded after changing modules. This feature is quite challenging related to replacing/patching modules or handling the state of the application. We need to investigate this more in detail to get an understanding what this would mean to support this from UI5 Tooling and the UI5 framework perspective.
UI5 Community & Easy-UI5 Generator
Together with the UI5 Community we had several nice innovations already in the past. One example is the UI5 ecosystem showcase project, which was the foundation to rollout the extensibility concepts of the UI5 Tooling. One thing which is missing for the UI5 Tooling as of today is templating/scaffolding. But Marius Obert spotted this niche in the past and placed his Easy-UI5 generator there. The Easy-UI5 generator has become the de-facto standard generator for OpenUI5/SAPUI5 projects. Together with Marius Obert, Volker Buzek and Geert-Jan Klaps we also pushed the Easy-UI5 generator to the next level: From Community Contributions to Community Plugins.
Q: Could you explain easy-ui5 vs @sap/generator-fiori?
A: Easy-UI5 is the de-facto standard generator for OpenUI5 and basic SAPUI5 freestyle projects maintained by the UI5 Community, whereas the SAP Fiori tools generator is the standard generator for SAP Fiori elements and advanced SAPUI5 freestyle projects. In addition, the SAP Fiori tools generator comes with SLA and thus official support.
Q: Which generator should we use in the future? The one from SAP Fiori tools, UI5 team or Easy-UI5? 🙂
A: Easy-UI5 for OpenUI5 and the SAP Fiori tools for SAPUI5 and SAP Fiori elements projects.
Thanks for all those great questions and for being such an awesome audience. I showed you a lot of individual topics around the innovation of the UI5 framework and what comes next. I really enjoyed the session and would like to invite you to join our next stop: the keynote at UI5con ON AIR 2021! There you will see how all those innovations connect with each other to reach a great and modern development experience for your daily UI5 development!