Sync Requests with RxJS and Angular
When you implement a search bar, the user can make several different queries in a row. With a Promise based implementation, the displayed result would be what the longest promise returns. Here we see how RxJs can be used to avoid this problem.
[00:00] Whenever you create a search bar, you have to think about concurrent requests. In our example here, we have radio buttons, and each time you click one, they refresh the entities listed below. We have colors, furnitures, pets, and nothing.
[00:18] The problem with the promise-based implementation is that you can't control the time a promise takes to resolve. Basically, if we click the foreigner here, you can see we end up within a very weird state where everything is out of sync.
[00:37] This happens because we don't display the latest requests. We display the one which takes the longest time to resolve. This is a side effect of promises. We can't conceal them. The delay you observed is due to the timeouts, time I decided for each collection.
[01:00] A first fix would be to use debounce in order to trigger requests whenever our radio buttons are clicked long enough, one after another. Let's give it a shot. Whenever I click allows and nothing now, because I did it within one second and a half. Only one request is made, and I can see the expected output.
[01:28] The problem here is we have to assume a correct time. Too long, and the UI is not responsible enough, and too short, and we may encounter weirdness again.
[01:43] I suggest here to use RxJS in order to solve our problem. In order to use it, we first have to create a source. A source is an observable, and it takes an observer as a param, and we are going to reuse the watch function we had before.
[02:09] Instead of searching entities, we are going to pass the new value to the observer using the un-next function. Because we are only interested in the latest value, we are using flat map latest. It will take the type as param, and we can now use the promises we get from our data service and just convert them using Rx Observable.fromPromise.
[02:59] We can remove the user's code now. Now we have our source. We can create a listener, so it's just a matter of source.subscribe. We are going to get the entities from it, so we only need to assign them to our controller.
[03:36] Let's give it a shot. No matter what order we click the radio buttons, we'll always get the expected outcome. RxJS will handle that for us. The main benefit of RxJS over mere promises is we always get the latest query results. You can see, this implementation of Rx has a way to cancel promises.
[04:07] I strongly encourage you to do two additional things now. The first thing is to clean after yourself. On each destroy event on the scope, so basically, whenever you use a router, it could be on route change, you have to dispose the listener so Rx knows it can get rid of everything linked to it.
[04:33] The second thing is we don't want to put too much pressure on our server, so we are going to use debounce again. It's very important to understand here that debounce is not a way to avoid UI issues. It's a way to avoid useless server queries.