Better odata handling in UI5 using promises part 1
The why
I make custom UI5 applications for clients, often working as part of larger teams but lately I've been working as the sole UI5 resource on a few different applications.
One of these applications was essentially a knock off SAP Ariba (as noted by the fact that the client continuously compared the solution to SAP Ariba) and the other a full scale work order management application with over 10+ tabs of data entry, reading, updating and deleting entries.
One of the few things about these applications is that I wasn't able to do and direct data binding to the view, various reasons for this such as needing data from one call before I could trigger another call but mostly there were lots of dynamic filters used and that's not something we currently have the ability to do in UI5. Whatever your reason for doing the data call in the controller you're doing it and so we should deal with it in the best possible way.
What happens when we get multiple levels deep with many calls relying on each-other? Quite often you find yourself in callback hell and how do we avoid callback hell? Promises. (side note: I hope that I'll make a future blog about the use of Async/ Await rather than promises but for now promises are more widely supported in browsers especially as clients are often stuck using Internet explorer)
Our Standard UI5 call
Our standard UI5 oData call that you've likely seen in samples across the internet will look something like this:
This is what I would say is the complete standard for a simple UI5 call that would grab data and set it to a model, in reality we'd probably do a lot more in this success function but this is just an example. (note: for simplicity's sake all of these examples will use the keyword 'var' rather than the newer 'const' and 'let' variable keywords.)
A more complex example
What if I need to call the one or two data sets before we get to the data we need? Something that might look like this:
Okay... I mean this isn't so bad! I can still read and understand it but it's not exactly re-usable and definitely could look prettier.
Promise encapsulation
This is all easily solved through promise encapsulation which is the idea that we simply take our standard UI5 call and encapsulate that inside of a promise. For further readability I tend to throw my promises inside their own separate function, this allows those who come after me to understand what each function does without really reading the content.
So with that how do we use it to set data as we did in our first example? Like the below:
Nice, that's a bit better but what about our slightly more complex example? First here is the two functions that hold our data calls so you can get the idea, note the change to our "returnTodoItems" function to add our key.
And our new function/ call to get and bind this data?
This is quite a contrived example that I don't think effectively shows the full potential of promises but if people are interested I will do a part 2 that dives into this in more detail.
End of Part 1
This is going to be a multi-part series on the use of Promises in UI5 to handle our Odata calls from the SAP gateway service. This first post covered the use of simply taking our simple UI5 data call and encapsulating it with a promise and a single example of how this could benefit you. In the next post I'm going to dive much deeper into how to use promises effectively and in a more reusable way in our projects. Follow me on Twitter where I'll be sure to post when I make the next blog. (along with some of my various ramblings)
As a side this post was mostly written while on the train traveling to client site, minor mistakes might exist and get updated as I see them.
Part 2!
Please follow on to part 2
···
