Provide a state object in the command request that can be directly modified to update store state#213
Conversation
| */ | ||
| export interface Command<T = any, P extends object = DefaultPayload> { | ||
| (request: CommandRequest<T, P>): Promise<PatchOperation<T>[]> | PatchOperation<T>[]; | ||
| (request: CommandRequest<T, P>): Promise<PatchOperation<T>[]> | PatchOperation<T>[] | void; |
There was a problem hiding this comment.
I think this needs to be void | Promise<void> for async commands when using the state object.
There was a problem hiding this comment.
@agubler Could have sworn I did that, sorry. It's done now!
96413da to
960aa05
Compare
|
I updated this to use a getter for state and throw an exception if used in IE. It seemed preferable to an alternative factory to me for a couple reasons:
Because of the way the patches are applied providing a |
|
@matt-gadd @agubler It's not pretty, but I think I've got optional types working with both approaches now. |
|
Nice work @maier49 |
The command error test was ignoring the error in the command, which was being neither returned nor thrown, and instead failed because it was trying to iterate over undefined. Now the process will still succeed if a command returns no operations, and this and the intended error handling are verified in updated tests.
91a6b71 to
0c6f46e
Compare
Type: feature
The following has been addressed in the PR:
prettieras per the readme code style guidelinesDescription:
This leverages proxies (where available), to add a
stateproperty to the command request object which can be modified directly to create operations that will update the store. Of the concerns raised on the original issue performance seems to be the biggest one, at least using this implementation. A simple operation that modifies one property two levels deep in an object takes about twice as long due to the time to create the proxy, regardless of whether it's used. Using the proxy slows down the operation further.Resolves #40