search

SAP / ui5-tooling

An open and modular toolchain to develop state of the art applications based on the UI5 framework
https://sap.github.io/ui5-tooling
Apache License 2.0
466 stars 71 forks source link

Support route-based code splitting #380

Open BenReim opened 5 years ago

BenReim commented 5 years ago

Expected Behavior

Having the self-contained build is a great improvement in terms of bundle size. Creating sap-ui-custom.js bundles brings huge performance benefits. However, as apps grow, the bundle grows as well. This can become an issue, especially for the initial start up time of such an app.

To address large bundle files lots of tools like Webpack perform Code-Splitting. A common approach is to split bundles by routes. UI5 already comes with a concept of routes and components. It would be great to have the ui5 builder support splitting bundles by routes as well.

Current Behavior

Projects can either be build using the preload or self-contained build. The latter does not allow code splitting.

Sample Project Setup

Imagine the following setup of application using routing and nested Components (each which potentially differing ui5 control includes and dependencies):

projectA (application)
└─(uses sap/m/Page, ...)
  \
   ├──/home  (component)
   │  └─(uses sap/m/Button, sap/f/Avatar)
   │
   ├──/users (component)
   │  └─(uses sap/m/Button, sap/ui/table/Table)
   │
   ├──/report (component)
   │  └─(uses ui5lab/thirdparty/lib)

Affected components (if known)

gregorwolf commented 5 years ago

As you can see in https://github.com/SAP/ui5-builder/issues/9 there is an option numberOfParts which allows to split the generated bundle. But unfortunately there is currently no documentation how to apply this for the self-contained build.

BenReim commented 5 years ago

Thanks for the fast reply! Indeed I had not seen that such an option to split builds exist. An open question for me would be if the bundles can be split in a way to leverage route based code splitting and how a scenario like the one described earlier can be set up.

codeworrior commented 5 years ago

That's definitely a useful feature - at least for standalone apps. For a launcher scenario (like the Fiori Launchpad), where the set of apps that run together in a single execution context is only established at deploy or configuration time, it doesn't work out easily (or requires deploy time / config time bundling).

There's even an internal prototype based on an earlier state of the tooling, which used routing targets, sap.ui.require calls and view loading APIs in general as split points. This prototype was far from being complete (esp. runtime support was missing at that time - we wanted it to be as transparent for apps as todays bundling is). Currently, other features are ranked higher on our backlog, but maybe I find time to at least "rebase" the prototype (in reality, it's a bit more than just rebasing).

It also has to be mentioned that there are other possible approaches, e.g. bridging between UI5 tooling and webpack.

But as I said, code splitting as a feature - no matter how it is implemented - is definitely worth to be considered.

BTW: with the current tooling, it is already possible to do a "poor man's code splitting" using manually configured bundles. Bundle definitions can be cascaded, omitting a set of already bundled files from a later bundle. In very urgent cases, this could be used already, but I guess one wouldn't like to do this regularly and only for a very small number of split points. Deriving split points automatically from the existing navigation APIs would be much more convenient.

For this cascaded bundling, unfortunately the same applies what @gregorwolf said about the automated size-based partitioning: documentation is missing :-(

BenReim commented 5 years ago

@codeworrior I fully agree with what you said. Thanks for your detailed answer!