CODEWITHSUNDEEP
performanceodatasapui5formatter
Rahul
Rahul

Reputation: 151

SAPUI5: Does Using Formatters Impact Performance?

I am working on custom SAPUI5 app using ODataModel and for which I have to do the formatting for some of the fields which I will be displaying in List control.

I need to know which approach is good mentioned below is good w.r.t. performance of app.

1) Is it a good idea to use Formatter.js file and write each method for each field for formatting?

Example - 

There are 2 fields which should be formatted before showing in UI and hence 2 formatter function.

2) Before binding Model to List - Do the formatting using Loop at each row. Example - 

Loop at OData.
--do formatting here for both the fields 
move data to model.
Endloop.
Bind new model to UI

Is there any other way by which we can improve performance - apart from code minification or using grunt.

Appreciate your help.

Thanks, Rahul

Upvotes: 0

Views: 1196

Answers (2)

cschuff
cschuff

Reputation: 5542

Replacing Formatters with other solutions is definitely NOT the point to start when optimizing performance not to mention that you will loose a lot of the convenience the ODataModel comes with when manually manipulating the data in it.

Formatter Performance

Anyways using a formatter is of course less performant then pre-formatting your data once after they were loaded. A formatter will be executed on every rerendering of your control. So you might not want to do heavy calculations or excessive looping in a formatter that is executed frequently. But given a normal usage using formatters is absolutely nothing you should worry about or that does noticeably affect end-user experience. Keep enjoying the convenience of formatters (and take a look at the cool Expression Binding).

General Performance Considerations

To improve performance it is first of all very important to identify the real bottle neck. In many cases this is simply the backend, there is usually much more to win with much less effort. Always keep that in mind. UI Code optimization is ridiculous as long as the main backend call runs for say 3s.

Things to improve your UI performance might be:

  • serve SAPUI5 from a CDN
  • use a Component-preload, can be generated with grunt-openui5 or gulp-ui5-preload (I think it does not minify XML yet so you could do that additionaly before creating Component-preload)
  • try to reduce the number of SAPUI5 libraries you are using
  • be aware of which SAPUI5 libraries you are NOT using and very consequently remove those (don't forget the dependencies section in Component metadata resp. manifest.json)
  • be aware that sap.ui.layout is a separate independent library (not registering it as such will result in a lot of extra requests)
  • if you use an ODataModel make sure you set useBatch to true (default in v2.ODataModel)
  • intelligently design your OData service (if you can influence it)
  • intelligently use $expands: sometimes it can make sense to preload $expand data on a parent binding that does not actually use it e.g. if you most probably need the data later on
  • think about bundling your app as native app and benefit from improved caching (Kapsel)
  • Check Performance: Speed Up Your App and Performance Issues
  • squeeze out some more bytes and save some requests by minifying/combining custom css or other resources if you have some

If you are generally interested in Web Performance I can recommend Steve Souders books.

I'm totally open for more ideas on SAPUI5 performance improvements! Anyone?

BR Chris

Upvotes: 3

Ran Hassid
Ran Hassid

Reputation: 2788

the best practice is to do it this way. The formatter allows you to receive an input and return output. The formatter function will be called in runtime and will be called for each of the rows which are displayed in your list. The reason that it will be called for each of the rows is because that you cannot grantee that the input will be the same for all of the rows in the list.

The concept of binding is to loop on your data model and update the UI accordingly. It is much better to use binding because a lot of reasons like: maintainability, performance, separate the data layer from the presentation layer, core optimizations and more.

Upvotes: 0

Related Questions