Closed pubmikeb closed 3 years ago
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
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
;)
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.
@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:
async
/await
and callbacks-freeAnd 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…
Stay tuned ;-)
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-bootstrapperdata-sap-ui-preload = "async"
in HTML-bootstrapper"async": true
insap.ui5/routing/config
of manifest.json"async": true
insap.ui5/rootView
of manifest.jsonsap.ui.core.IAsyncContentCreation
inmetadata/interfaces
of Component.jsAs 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: