Custom DTO Decorator

[summer mango]

Your DTO should not contain such logic. It should only be concerned about providing a stable contract and input validation. Instead, you can have a look at guards or middleware.

[still patio]

So I use this decorator in the same way in another project and it works. I copied the code and the necessary changes to make in my new project, but it still doesn't work.

Do you want me to show you how it is in the other project?

[summer mango]

I don't know the solution to your problem, I would have to do some debugging myself. I am merely stating that what you are doing, is the 'wrong' way and instead you should opt for guards or middleware.

[still patio]

I'll see about that, thanks so far

[neat bone]

@still patio you can check this https://github.com/rubiin/ultimate-nest/blob/master/src/common/decorators/validation/is-unique.validator.ts

[summer mango]

Mhm on a second thought. The dto does not seem to be concerned with calling the database but it leaves a bitter taste in my mouth. What are your thoughts on it?

[neat bone]

If it's something like a validation on database level, this would help with keeping things dry

[still patio]

@neat bone can you help me to implement this using sequelize ?

[wooden onyx]

Also note that if you want to use DI in those custom DTO validation decorators, you should have this in the main.ts file.

useContainer(app.select(AppModule), { fallbackOnErrors: true });

[summer mango]

It's also dry if you were to put it in a guard or within your business layer. I am not sure if I agree with the idea of having a dto be concerned with uniqueness of some value. The whole idea behind a dto is to transfer data which includes input validation. Not business logic?

[ocean panther]

ugh i do not like images of code they are a pain to read
by quick looking i do not get the full code either things are cut of or not fully included here
i also strongly recommend against such things
and you would be better of doing this in the controller/service
it also feels wrong

but it isn't dis allowed either
to start of your decorator validate expects a promise Boolean
but you return a Boolean instead

you're not properly awaiting the res here

[neat bone]

uniqueness is a validation in a sense. Also having that as a validation is a advantage as you could get the errors within the validation itself. I agree with not putting the whole business logic thing tho but for simpler usecases it would be fine 😄

[turbid musk]

Eh, personally, I feel the ValidaitonPipe should concern itself with shape, and uniqueness is a business logic rule that should be in the service. My two cents though