docs: mention 3 strats for with(Entity)Resource error handling#271
docs: mention 3 strats for with(Entity)Resource error handling#271rainerhahnekamp merged 7 commits intomainfrom
with(Entity)Resource error handling#271Conversation
|
Caretaker note: once the actual error handling PR is merged, update the two doc pages' links to point at the jsdocs for the error handling behavior deep explanation |
docs/docs/with-entity-resources.md
Outdated
|
|
||
| ## Error Handling | ||
|
|
||
| The behavior of Angular's resources' error handling and the NgRx SignalStore's `getState/patchState` required `withEntityResource` to approach error handling |
There was a problem hiding this comment.
TODO - I phrased this so weird. Once the v21 blog post is more fleshed out, take what was written there and replace some of this awkwardness.
rainerhahnekamp
left a comment
rainerhahnekamp
left a comment
There was a problem hiding this comment.
Good, good, just a few remarks.
| - **Resource members**: `todosValue()`, `todosStatus()`, `todosError()`, `todosIsLoading()`; `projectsValue()`, ... | ||
| - **Entity members**: `todosIds()`, `todosEntityMap()`, `todosEntities()`; `projectsIds()`, `projectsEntityMap()`, `projectsEntities()` | ||
|
|
||
| ## Error Handling |
There was a problem hiding this comment.
The complete withEntityResource is based on the undefined value strategy. I think we just need to here a quick note on that and link to withResource for further details.
Users cannot change the error handling here, since withEntityResource uses the resource internally. It is an implementation detail so to say.
docs/docs/with-resource.md
Outdated
|
|
||
| Starting in NgRx Toolkit v20.6.0, error handling now has more resilient options. | ||
|
|
||
| The behavior of Angular's resources' error handling and the NgRx SignalStore's `getState/patchState` required `withResource` to approach error handling |
There was a problem hiding this comment.
I wouldn't be that specific. I would just say sometihng like
that the error throwing behavior of the native resource causes a deadlock in the error case. That's why withResource comes with a different error handling, which doesn't throw.
docs/docs/with-resource.md
Outdated
|
|
||
| Options: | ||
|
|
||
| 1. `'undfined value'` (default). In the event of an error, the resource's value will be `undefined` |
There was a problem hiding this comment.
| 1. `'undfined value'` (default). In the event of an error, the resource's value will be `undefined` | |
| 1. `'undefined value'` (default). In the event of an error, the resource's value will be `undefined` |
docs/docs/with-resource.md
Outdated
| Options: | ||
|
|
||
| 1. `'undfined value'` (default). In the event of an error, the resource's value will be `undefined` | ||
| 1. `'previous value'`. Provided the resource had a previous value, that previous value will be returned. If not, an error is thrown. |
There was a problem hiding this comment.
I wouldn't mention the condition that it only returns if a previous value exists. It just returns the previous value.
A resource always has a value in its initial state. The implementation needs to consider a "non-realsitic" scenario because of TypeScript.
2 participants
Assuming the following PR for resource error behavior in the resource features is merged: #270