Consolidate async-related configurations into one single property

[pubmikeb]

As we all know, the way the application is loaded (async vs. sync) has a huge impact on the application performance and, as the result, on the end-customer UX.

Due to historical/legacy or compatibility reasons, UI5 has quite a lot of configurations dealing with async loading, here are just some of them which came to my mind immediately:

• data-sap-ui-async = "true" in HTML-bootstrapper
• data-sap-ui-preload = "async" in HTML-bootstrapper
• "async": true in sap.ui5/routing/config of manifest.json
• "async": true in sap.ui5/rootView of manifest.json
• sap.ui.core.IAsyncContentCreation in metadata/interfaces of Component.js

As you may see, the list is not so tiny, and I'm pretty sure the UI5-experts could add even more async-related configurations.

Wouldn't be great to consolidate all async-related configurations into one single option, which a developer could enforce either via manifest.json or in HTML-bootstrapper and be sure that the UI5-application will work in async mode as much as possible?

Such change should:

• cut the learning curve
• ensure the maximal application performance for the end customer
• simplify the development process and eliminate the potential performance pit-falls if a developer forgets to tune one of 5-7 async-related parameters

[Shtilianova]

Hello @pubmikeb , Thank you for sharing your enhancement proposal. I've created an internal incident 2170175348. The status of the issue will be updated here in GitHub. Regards, Diana

[Thodd]

Hi @pubmikeb,

we feel you, the "async-switch" situation is a bit out of hand. I agree that it would be much better to have one switch to rule them all, but (ugh... I don't want to be that guy...):

We have big reservations with respect to compatibility.

We have discussed this many times already, but the harsh bottom line is, we can't keep it compatible. We can introduce a new switch now, capturing all currently available flags, but once other asynchronous behavior or features are added we cannot change the behavior of such a switch under the hood.

I'll try to give you a bit of insight in some of issues we have encountered when dealing with asynchronous APIs in the past:

• Sometimes we see a chance to capture more asynchronous behavior in an already asynchronous closure, but even that causes quite a number of problems. Since a couple of weeks we now capture the async root-view loading in the already async Component factory, but even this caused major problems, e.g. with eventing order and timing. Quite some applications had issues that are sometimes impossible to resolve compatibly.

• We tried something similar with the sap.ui.core.IAsyncContentCreation interface, but this also lead to quite some issues, again because of changed timing. Especially the handling of nested components gets tricky, since you of course control your own component, but you can't simply propagate the asynchronous switches down to your child components. Neither developer nor framework might know the internals of the nested component. If it is not async ready, your app blows up.

• Same is true for Views, if a nested View depends on synchronous loading and eventing, you cannot simply propagate the asynchronous behavior down, that breaks just too many applications.

So far the IAsyncContentCreation interface is the best version of a "cover-it-all" switch we have: https://sapui5.hana.ondemand.com/#/topic/b430345887f1419fba50320b57c1bdf9 As I motivated above however, it still can't capture everything in a compatible manner and any async additions cannot simply be made under this interface, again due to compatibility.

I hope this does not sound too defeated and you understand that we are on it and are trying our best to make this is easy as possible. Still even if we get a "fully-async" switch running now, the next time we would need to top it with a "finally-async" switch and so on ;) Jokes aside, maybe @codeworrior can add something else to this discussion.

BR, Thorsten

PS: Don't forget to set your ComponentContainer to async:true ;)

[codeworrior]

I fully agree to what @†hodd already wrote.

The biggest problem, that we have with adapting the semantics of switches, is the automatic version upgrade of cloud systems. We must not change behavior under the hood in such scenarios. There's no point in time (or in processes) where app developers could react.

We could revive the compatVersion configuration and couple behavioural changes to a certain version. But in the FLP scenario (the most common usage scenario for UI5), this also doesn't help as FLP couldn't upgrade the compatVersion either, without risking to break apps.

Making the compatVersion a per-Component switch was another idea that we discussed in the past. But as UI5 APIs are so much constructor driven, not factory driven, it is hard to propagate per-Component switches to all API implementations and we decided against that.

That's why we usually end up with feature-specific switches that allow fast adoption by front runner apps without breaking slowly- or never adopting other apps.

The latest idea that was discussed was a kind of named configuration profile that combines all best practices at a certain point in time (e.g "UI5BestPracticesSummer2021") and suggest this only to standalone apps, resp. apps that have full control over version updates. We then realised that this is the same as the compatVersion, just with a different label and without "edge".

Well, that's the current status.

[pubmikeb]

@Thodd and @codeworrior , thanks for sharing info regarding the asynchronous challenges.

I might be wrong, but from what I've read it looks like a legacy-design issue, which is OK for almost ten-years old project, especially when the tech stack (e.g. JS) is extremely dynamic.

Perhaps, the solid solution is to re-write the entire codebase under UI5 3.0 and Fiori 4.0 using:

• TypeScript
• ES2022
• async/await and callbacks-free
• Synchronous XHR requests-free (where it's possible)
• JSON-views only instead of XML, HTML, and JavaScript views
• jQuery-free
• CSP-compliant

And then to serve to versions: LTS focused on the backward compatibility and innovative, focused on the latest technologies and performance but at the cost of backward compatibility.

Is it feasible/realistic? I don't know…

[codeworrior]

Stay tuned ;-)