feat: add 'rename' context-item#971
Conversation
| if (path !== this.newPath) { | ||
| if (context.fields.length !== 1) { | ||
| throw new Error('Cannot rename multiple fields.'); | ||
| } | ||
| const field = context.fields[0]; | ||
| if (field.includes('*') || this.newPath.includes('*')) { | ||
| throw new Error('Cannot use rename() with wildcards.'); | ||
| } | ||
|
|
||
| if (_.get(req[location], this.newPath) !== undefined) { | ||
| throw new Error(`Cannot rename to req.${location}.${path} as it already exists.`); | ||
| } |
There was a problem hiding this comment.
These errors are thrown at runtime, should we use context.addError() even if it is not a validation error?
| const newValue = instance.value; | ||
| if (contextItem instanceof Rename) { | ||
| // change instance path | ||
| instance.path = contextItem.newPath; |
There was a problem hiding this comment.
Is it correct to change instance.path?
There was a problem hiding this comment.
I'll guess no because of the below:
express-validator/src/context.ts
Lines 66 to 70 in 6715a6a
but we can always change behaviour.
And side comment, I'd just find it a bit more classy if we could use context's APIs instead of checking for the specific implementation of Rename here.
e26d3df to
db52eb4
Compare
gustavohenke
left a comment
There was a problem hiding this comment.
ohey only 1.5 years later
| if (this.newPath.includes('*')) { | ||
| throw new Error('Cannot use rename() with wildcards.'); | ||
| } |
There was a problem hiding this comment.
WDYT of moving this to the constructor/.rename()?
Just thinking that failing on server start might be a better developer experience than on request.
| if (_.get(req[location], this.newPath) !== undefined) { | ||
| throw new Error(`Cannot rename to req.${location}.${path} as it already exists.`); |
There was a problem hiding this comment.
I'm guessing that a client might, due to a bug, send more information than required and litter logs with 5XX errors (as I think it'll probably flow all the way to next()).
Perhaps it's best to remove this?
| _.set(req[location], this.newPath, value); | ||
| _.unset(req[location], path); |
There was a problem hiding this comment.
These should obey the dryRun option
| import { Meta } from '../base'; | ||
| import { Rename } from './rename'; | ||
|
|
||
| it('the new path is identical to the old one', () => { |
There was a problem hiding this comment.
nitpicking, but I usually like to make test names read nicely with the it.
For example:
| it('the new path is identical to the old one', () => { | |
| it('does nothing when the new path is identical to the old one', () => { |
| const context = new ContextBuilder().setFields(['foo']).build(); | ||
| const meta: Meta = { req: {}, location: 'body', path: 'foo' }; | ||
|
|
||
| expect(new Rename('foo').run(context, 'value', meta)).resolves; |
There was a problem hiding this comment.
| expect(new Rename('foo').run(context, 'value', meta)).resolves; | |
| await expect(new Rename('foo').run(context, 'value', meta)).resolves; |
though I'm afraid that .resolves might not be asserting anything 🤔
| const newValue = instance.value; | ||
| if (contextItem instanceof Rename) { | ||
| // change instance path | ||
| instance.path = contextItem.newPath; |
There was a problem hiding this comment.
I'll guess no because of the below:
express-validator/src/context.ts
Lines 66 to 70 in 6715a6a
but we can always change behaviour.
And side comment, I'd just find it a bit more classy if we could use context's APIs instead of checking for the specific implementation of Rename here.
3177f64 to
6e160b1
Compare
Description
This allows to rename a property.
Closes #785
To-do list
1.0)instance.pathediting