feat(payments-next): actions response validation and dto updates #18457
Conversation
julianpoy
force-pushed
the
FXA-10708
branch
7 times, most recently
from
c845324 to
74e2881
Compare
| cartId, | ||
| }) | ||
| ); | ||
| const cart = await actionsService.restartCart({ |
There was a problem hiding this comment.
What is the rationale behind sometimes doing the const { something } pojo initialization vs the const something assignment? I see both at play, but am not sure I understand the reason behind it
There was a problem hiding this comment.
Maintaining compatibility. Class validator requires that values be classes, and primitive values can't be transformed to a class like an object can. Because of that, I have moved some methods that previously returned a primitive type over to an object return type that then subsequently gets spread out in the actions layer to return the primitive we want in the frontend.
| * Will capture timing for this method and send them to StatsD. Requires the target class to have statsd exposed as a public property. | ||
| * Timings will appear as ClassName_methodName in StatsD. | ||
| */ | ||
| export function NextIOValidator< |
There was a problem hiding this comment.
can we change this to something like MethodTypeValidator? IO is an overloaded term that feels like less of a "clear" fit here
There was a problem hiding this comment.
The term type is overloaded imo, especially in TypeScript, and additionally means something that doesn't impact runtime.
Because: - We want response validation - We want a better way of doing IO validation for actions without the hassle of conversion to class-validator format each time This commit: - Adds a decorator that does the above Closes FXA-10708
Because
This pull request
Issue that this pull request solves
Closes FXA-10708