How to Use the New R Promises Package
The long awaited promises will be released soon!
Being as impatient as I am when it comes to new technology, I decided to play with the currently available implementation of promises that Joe Cheng shared and presented recently in London at the EARL conference.
From this article you’ll get to know the upcoming
promises package, how to use it and how it is different from the already existing
If you are not familiar with the concept of Promises, asynchronous tasks or Futures, I advise you to take a longer moment and dive into the topic. If you’d like to dive deeper and achieve a higher level of understanding, read about Continuation Monads in Haskell. We’ll be comparing the new
promises package with the
future package, which has been around for a while so I suggest you take a look at the future package overview first if you haven’t used it before.
Citing Joe Cheng, our aim is to:
- Execute long-running code asynchronously on separate thread.
- Be able to do something with the result (if success) or error (if failure), when the task completes, back on the main R thread.
A promise object represents the eventual result of an async task. A promise is an R6 object that knows:
- Whether the task is running, succeeded, or failed
- The result (if succeeded) or error (if failed)
Without further ado, let’s get our hands on the code! You should be able to just copy-paste code into RStudio and run it.
R is single threaded. This means that user cannot interact with your shiny app if there is a long running task being executed on the server. Let’s take a look at an example:
We’ll use a simplified version of user interaction while there are some additional computations happening on the server. Let’s assume that we can’t just put all the computations in a separate block of code and just run it separately using the
future package. There are many cases when it is very difficult or even almost impossible to just gather all computations and run them elsewhere as one big long block of code.
User cannot interact with the app for 10 seconds until the computations are finished and then the user has to wait another 5 seconds for next interaction. This is not a place where we would like to be in. User interactions should be as fast as possible and the user shouldn’t have to wait if it is not required. Let’s fix that using R
future package that we know.
Nice, now the first user interaction can happen in parallel! But the second interaction is still blocked – we have to wait for the values, to print their sum. In order to fix that we’d like to chain the computation into the summing function instead of waiting synchronously for the result. We can’t do that using pure futures though (assuming we can’t just put all these computations in one single block of code and run it in parallel). Ideally we’d like to be able to write code similar to the one below:
future package won’t allow us to do that.
What we can do, is use the promises package from RStudio!
Let’s play with the promises! I simplified our example to let us focus on using promises first:
We’d like to chain the result of
longRunningFunction to a print function so that once the
longRunningFunction is finished, its results are printed.
We can achieve that by using %…>% operator. It works like the very popular %>% operator from magrittr. Think of
%...>% as “sometime in the future, once I have the result of the operation, pass the result to the next function”. The three dots symbolize the fact that we have to wait and that the result will be passed in future, it’s not happening now.
But what if I want to filter the result first and then print the processed data? Just keep on chaining:
Neat. But, how can I print the result of filtering and pass it to the
sum function? There is a tee operator, the same as the one magrittr provides (but one that operates on a promise). It will pass the result of the function to the next function. If you chain it further, it will not pass the result of
print() function but previous results. Think of it as splitting a railway, printing the value on a side track and ending the run, then getting back to the main track:
What about errors? They are being thrown somewhere else than in the main thread, how can I catch them? You guessed it – there is an operator for that as well. Use
%...!% to handle errors:
But in our example we’re not just chaining one computation. There is a
longRunningFunction call that eventually returns 1 and another one that eventually returns 2. We need to somehow join the two. Once both of them are ready, we’d like to use them and return the sum. We can use
promise_all function to achieve that. It takes a list of promises as an argument and returns a promise that eventually resolves to a list of results of each of the promises.
Perfect. We know the tools that we can use to chain asynchronous functions. Let’s use them in our example then:
A task for you – in line
sumAC <- promise_all(a, c) %...>% reduce(+
), print the list of values from promises
c before they are summed up.
Handful of useful information:
 There is support for promises implemented in shiny but neither CRAN nor GitHub master branch versions of Shiny support promises. Until support is merged, you’ll have to install from async branch:
 Beta-quality code at GitHub
 Early drafts of docs temporarily hosted at Joe Cheng’s Medium
 The plan is to release everything on CRAN by end of this year.
I hope you have as much fun playing with the promises as I did! I’m planning to play with shiny support for promises next.
Till next time!