Progressive and Ordered Loading
The previous snippet assumes the game is made up of 128 separate items, all of the same priority. If the game includes a main UI, as well as separate sections for chat, the player’s inventory, and a market for players to exchange items, the player needs to wait for everything to load, even if they don’t care about today’s prices for Fizzblonium. The next step is to break up the game into components. Each section of functionality (UI, inventory, chat, market) will have all of the parts required for operation in its own load observable.
This way, each component of the game interface can decide what needs to be loaded for that component. Additionally, this would let us control the order that the app’s component parts load in. Taking the same progress bar pattern as before:
| | merge(...componentRequestArray, 5) |
| | .pipe( |
| | scan((prev, val) => prev + (100 / componentRequestArray.length), 0) |
| | ) |
| | .subscribe(updateProgressbar, handleError); |
Unfortunately, we need to trigger our three subcomponents when the main load has finished, not just when there’s a new value. Right now, the only option is to pile all the things into an if statement in the the initial subscribe.
| | merge(...componentRequestArray, 5) |
| | .pipe( |
| | scan((prev, val) => prev + (100 / componentRequestArray.length), 0) |
| | ) |
| | .subscribe(percentDone => { |
| | if (percentDone === 100) { |
| | // Trigger the other observables |
| | marketLoader$.subscribe(); |
| | chatLoader$.subscribe(); |
| | inventoryLoader$.subscribe(); |
| | } |
| | updateProgressbar(percentDone); |
| | }, handleError); |
This is starting to get ugly. And everything constantly resets on every game load. A player may not care about the market and want it closed. We can save the user’s state and load it, at the cost of further complicating the subscribe function:
| | merge(...componentRequestArray, 5) |
| | .pipe( |
| | scan((prev, val) => prev + (100 / componentRequestArray.length), 0) |
| | ) |
| | .subscribe(percentDone => { |
| | if (percentDone === 100) { |
| | ajax('/userPreferences') |
| | .subscribe(results => { |
| | // Trigger the other observables |
| | if (results.marketOpen) { |
| | marketLoader$.subscribe(); |
| | } |
| | if (results.chatOpen) { |
| | chatLoader$.subscribe(); |
| | } |
| | if (results.inventoryOpen) { |
| | inventoryLoader$.subscribe(); |
| | } |
| | }, handleError); |
| | } |
| | updateProgressbar(percentDone); |
| | }, handleError); |
Yikes, this is getting pretty complicated. The whole point of using RxJS is it allows us to move each action into a single function. This code is starting to resemble all of the terrible patterns from the callback world. There’s a problem with the observables you’ve used so far—they’re single-use only, with new subscriptions creating entirely new streams. If we could take a single stream and split it to multiple subscribers, things like this would get a lot simpler. We’ll cover the exact mechanics of “observable splitting” in Chapter 5, Multiplexing Observables.