@@ -212,12 +212,32 @@ block get-heroes-details
212
212
We've also decided to return a user friendly form of the error to
213
213
the caller in a !{rejected_promise} so that the caller can display a proper error message to the user.
214
214
215
- ### Unchanged `getHeroes` API
215
+ ### Get hero by id
216
+ The `HeroDetailComponent` asks the `HeroService` to fetch a single hero to edit.
217
+
218
+ The `HeroService` currently fetches all heroes and then finds the desired hero
219
+ by filtering for the one with the matching `id`.
220
+ That's fine in a simulation. It's wasteful to ask a real server for _all_ heroes when we only want one.
221
+ Most web APIs support a _get-by-id_ request in the form `api/hero/:id` (e.g., `api/hero/11`).
216
222
217
- Although we made significant *internal* changes to `getHeroes()`, the public signature did not change.
218
- We still return a !{_Promise}. We won't have to update any of the components that call `getHeroes()`.
223
+ Update the `HeroService.getHero` method to make a _get-by-id_ request,
224
+ applying what we just learned to write `getHeroes`:
225
+ + makeExcerpt('app/hero.service.ts' , 'getHero' , '' )
226
+ :marked
227
+ It's almost the same as `getHeroes`.
228
+ The URL identifies _which_ hero the server should update by encoding the hero id into the URL
229
+ to match the `api/hero/:id` pattern.
230
+
231
+ We also adjust to the fact that the `data` in the response is a single hero object rather than !{_an} !{_array}.
232
+
233
+ ### Unchanged _getHeroes_ API
234
+
235
+ Although we made significant *internal* changes to `getHeroes()` and `getHero()`,
236
+ the public signatures did not change.
237
+ We still return a !{_Promise} from both methods.
238
+ We won't have to update any of the components that call them.
219
239
220
- Our stakeholders are thrilled with the added flexibility from the API integration.
240
+ Our stakeholders are thrilled with the web API integration so far .
221
241
Now they want the ability to create and delete heroes.
222
242
223
243
Let's see first what happens when we try to update a hero's details.
@@ -230,15 +250,12 @@ block get-heroes-details
230
250
it. As we type, the hero name is updated in the view heading.
231
251
But when we hit the `Back` button, the changes are lost!
232
252
233
- .l-sub-section
234
- :marked
235
- Updates weren't lost before, what's happening?
236
- When the app used a list of mock heroes, changes were made directly to the
237
- hero objects in the single, app-wide shared list. Now that we are fetching data
238
- from a server, if we want changes to persist, we'll need to write them back to
239
- the server.
253
+ Updates weren't lost before. What changed?
254
+ When the app used a list of mock heroes, updates were applied directly to the
255
+ hero objects within the single, app-wide, shared list. Now that we are fetching data
256
+ from a server, if we want changes to persist, we'll need to write them back to
257
+ the server.
240
258
241
- :marked
242
259
### Save hero details
243
260
244
261
Let's ensure that edits to a hero's name aren't lost. Start by adding,
0 commit comments