SAP UI5 SDK - Component Life Cycle

[Karol-K]

In my components as in the Karol's SDK Components blog I have stated that those are working only with 1.3 release SP1 and higher.

Here some explanation why with a small deep drive into the component lifecycle.

Scope

This blog is handling only components of type "sapui5".

What is this about?

As SDK developer you need to evaluate component properties which are send back from the server and based on those you can draw your visualization.

Before 1.3 SP1

In the initial release, the getters and setters were used to pass the properties with following workflow:

1. call the getter (always)
2. if getter is retrieving a value which differs from the new value...
   • call the setter with new value
3. if value are same, do not call the setter

This means, all setters were called on "random" basis and it was difficult to decide when the time to render consistent component is. Also, it was not easy to pass properties which have dependencies between each other, for the same reason - no idea when all properties are passed to the java script component.

Change in 1.3 SP1

With release 1.3, SP1 there is a small correction which allows you to make explicit checks which properties have been changed in the current response-request cycle and also trigger the rendering after all available properties are distributed.

How does it work?

When you check the java script from the SDK framework for dispatching of properties, you can see following two function calls which are new in 1.3 SP1:

     Function "beforeDesignStudioUpdate()"

This function is called (without any parameters) always when new properties have arrived and BEFORE the properties will be distributed.

     Function "afterDesignStudioUpdate()"

This function is called (without any parameters) always when new properties have arrived and AFTER all the properties are already distributed.

New Workflow

After this change, the sequence is different:

1. call "beforeDesignStudioUpdate()"
   

          // for all properties

1. call the getter (always)
2. if getter is retrieving a value which differs from the new value...
   • call the setter with new value
3. if value are same, do not call the setter
1. call "afterDesignStudioUpdate()"

How you can use it?

Here I can refer to all my components, which are using the "afterDesignStudioUpdate()" method to rebuild the content. My examples are not yet perfect, as I destroy old content in the majority of the components and do not make any delta handling.

But if you really start thinking about use of both methods, you can set some values, eg. "propertySelectionOld = getSelction();"in the method "beforeDesignStudioUpdate()" and then check if the new property value equals to the old. If yes, no change on this - so you do not need to touch the area of your rendering which is reflecting the property.

So, in short when the method "afterDesignStudioUpdate()" is called, you know that is for this update. You are fine now.

Lifecycle Visualization

More Extensions Coming (release 1.4)

This is the status of 1.3 SP1, in 1.4 release some more changes will come, eg. delta handling of properties in SDK components... This means only changed properties will be passed to the client. Keep this in mind when making assumptions in the client (eg. do not reset your properties as you never know if they will be set again until changed)...

At this point, we should consider in giving some practice how to pass "huge" content to the SDK components, eg. you have a list and corresponding selections. Of course a list does change not so frequently as the selection - if you pass the selection together with the list in same JSON object, your update is always huge and you cannot know if the list has changed or only the selection. When the delta handling is on (default in 1.4) it is actually better to distinguish the list content itself and the selection information in some form that delta handling can reduce the content passed from server to client.

Delta handling means, the check has been moved from the client to the server (initially it was calling the getter and comparing, now all is in the server side – so even you cannot assume your getter will be called in Java Script)

Summary

This is why my components do work only on 1.3 SP1...

Have fun with applying the knowledge!