When adding a new `BlogPost` to the list we realize the component is over-rendering, as the numbers are increasing un-proportionally to the data we receive.
Try to implement operators that filter out values which should not get processed. e.g. empty arrays are not interesting to process.
also, if multiple subscriptions get done on the same Observable we could try to share the processed result with all subscribers to reduce the number of processing.
Also consider where and if `zip` could help here.
Try to minimize the amount of renderings.
Consider the following approaches:
- use `zip` to combine dependent changes
- filter out values which should not get processed
If values take longer than others it waits with the emission.
Also, if one stream is emitting faster than the other it is waiting with emissions and caches the emitted values until other included streams emitted the same number of times to emit them together.
If the sources emit values at different timings, `zip` waits until every source has emitted a value for the next combined result.
An example where the emissions wait for their other related Observables could be two polling mechanisms that depend on each other.
In this example we use random intervals to demonstrate this:
```Typescript
import {interval, zip} from 'rxjs';
const input1$ = interval(500); // emission rate varying between 1000 and 3000 ms
const input1$ = interval(200);
const input2$ = interval(1000);
const result$ = zip(input1$, input2$);
result$.subscribe(
([input1, input2]) => console.log(input1, input2)
);
// logs all first, second, third values together: 1 1, 2 2, 3 3, 4 4, 5 5, 6 6
// outputs
// 1, 1
// 2, 2
// 3, 3
// 4, 4
// 5, 5
// n, n
```
As we can see the numbers get logged in pairs and in the right order.
If one stream is faster than the other, the values of the faster one get cached and emitted when its related values arrive.
As we can see the results get logged in correctly ordered pairs.
If one source is faster than the other, the values get cached and emitted when its related values arrive.
Here a visual representation of the above example:
_zip - different rates_
Also, for completely random emission rates zip always emits in the right pairs.
_zip - different timings_
An example for random timings where `zip` still keeping the result in order
Be aware that `zip` can buit up a huge cache if the emission rate is too different.
Also, if one of them never emits you have a memory leak.
Be aware that `zip` can build a huge cache if emission rates are very different.
If one of the sources never emits a value you will end up with a memory leak.
