ts-mixer: Doesn't pick up validation decorators for class-validator
compared to the mixin function provided by TypeScript.
CODE
import { IsBoolean, IsIn, validate } from "class-validator";
import { Mixin } from 'ts-mixer'
function applyMixins(derivedCtor: any, baseCtors: any[]) {
baseCtors.forEach(baseCtor => {
Object.getOwnPropertyNames(baseCtor.prototype).forEach(name => {
Object.defineProperty(derivedCtor.prototype, name, Object.getOwnPropertyDescriptor(baseCtor.prototype, name));
});
});
}
// Disposable Mixin
class Disposable {
@IsBoolean()
isDisposed: boolean = false;
}
// Activatable Mixin
class Statusable {
@IsIn(['bound', 'open'])
status: string = 'test';
}
class ExtendedObject extends Mixin(Disposable, Statusable) {
}
class MixedObject {
constructor() {
this.status = 'test'
this.isDisposed = false
}
}
interface MixedObject extends Disposable, Statusable {}
applyMixins(MixedObject, [Disposable, Statusable]);
async function test(classObj)
{
let smartObj = new classObj();
console.log(smartObj)
console.log(smartObj.status)
console.log(smartObj.isDisposed)
console.log(await validate(smartObj))
}
async function main() {
await test(MixedObject)
console.log('-----------')
await test(ExtendedObject)
}
main()
OUTPUT
Statusable { status: 'test', isDisposed: false }
[
ValidationError {
target: Statusable { status: 'test', isDisposed: false },
value: 'test',
property: 'status',
children: [],
constraints: { isIn: 'status must be one of the following values: bound,open' }
}
]
-----------
ExtendedObject { isDisposed: false, status: 'test' }
[]
About this issue
- Original URL
- State: closed
- Created 4 years ago
- Comments: 19 (7 by maintainers)
Commits related to this issue
- test: adds a test case for #15 (did not fix the issue yet) — committed to tannerntannern/ts-mixer by tannerntannern 4 years ago
Hi @kenberkeley, glad you got it working. As for the multi-validator suggestion, I would prefer that a separate issue/feature request be opened. It can definitely be done “on the JavaScript side”, but the typing might not be so simple given that the order of application matters for class decorators.
Happy to discuss this in another issue (or PR if you’d like to take a crack at it!)
Good news: #18 revealed a potential strategy for resolving this issue. My initial implementation actually fixes the integration test specifically for this issue (#15) so I’m hopeful! More info to come after I take some time to flesh out the idea.