Commit b623730b authored by micha's avatar micha
Browse files

progress

parent 69188be0
...@@ -11,7 +11,7 @@ export const MENU_ITEMS: MenuItem[] = [ ...@@ -11,7 +11,7 @@ export const MENU_ITEMS: MenuItem[] = [
}, },
{ {
label: 'opt-in updates-v1', label: 'opt-in updates-v1',
link: './opt-in-updates-v1' link: './withLatestFrom'
}, },
{ {
label: 'state normalisation and zip', label: 'state normalisation and zip',
......
...@@ -31,9 +31,9 @@ export const ROUTES = [ ...@@ -31,9 +31,9 @@ export const ROUTES = [
.then(m => m.ComparisonModule) .then(m => m.ComparisonModule)
}, },
{ {
path: 'opt-in-updates-v1', path: 'withLatestFrom',
loadChildren: () => import('./exercises/opt-in-updates-v1/opt-in-updates-v1.module') loadChildren: () => import('./exercises/withLatestFrom/withLatestFrom.module')
.then(m => m.OptInUpdatesV1Module) .then(m => m.WithLatestFromModule)
} }
] ]
} }
......
# Combining ongoing Observables - Exercise # Combining ongoing Observables - Exercise
![](./assets/images/Reactive-architecture-and-ux-patterns_angular_over-fetching_michael-hladky.png)
![](./assets/images/Reactive-architecture-and-ux-patterns_angular_http-caching_michael-hladky.png)
## Intro ## Intro
As processing HTTP calls directly in the component we run into "over-fetching" of data. As processing HTTP calls directly in the component we run into "over-fetching" of data.
Over-fetching means we request data from the server more often than we need to. Over-fetching means we request data from the server more often than we need to.
......
...@@ -31,4 +31,4 @@ export class SolutionForkJoinComponent { ...@@ -31,4 +31,4 @@ export class SolutionForkJoinComponent {
## Conclusion ## Conclusion
Great! We managed to combine two http calls with the `forkJoin` operator into a single list of `BlogPost`. But what if we want to Great! We managed to combine two http calls with the `forkJoin` operator into a single list of `BlogPost`. But what if we want to
handle data manipulations? In a next step we refactor our architecture to a minimal http caching solution. handle ongoing Observables? In a next step we refactor our architecture to a minimal http caching solution.
...@@ -38,7 +38,7 @@ If any of the sources raises an `error`, it gets forwarded, and the resulting Ob ...@@ -38,7 +38,7 @@ If any of the sources raises an `error`, it gets forwarded, and the resulting Ob
![forkJoin error](./assets/images/Reactive-architecture-and-ux-patterns_angular_combination-operators-forkJoin-error_michael-hladky.png) ![forkJoin error](./assets/images/Reactive-architecture-and-ux-patterns_angular_combination-operators-forkJoin-error_michael-hladky.png)
## Gotcha(s)! ## 💡 Gotcha(s)!
As stated above, the `forkJoin` creation function waits until every source raises a `complete` event. After that it will return As stated above, the `forkJoin` creation function waits until every source raises a `complete` event. After that it will return
the very *last* value of each source. It suits perfectly fine when dealing with HTTP Requests since they `complete` on their own. the very *last* value of each source. It suits perfectly fine when dealing with HTTP Requests since they `complete` on their own.
......
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment