🦺 for validation changes

[cnfw]

Emoji symbol

🦺

Emoji code

:safety_vest:

Emoji description

Validation logic/schema changes

Describe the use case of your emoji

Often features are developed rapidly with little thought given to validation checks on user-submitted data (at least initially), and so work can be done at a later stage to add or improve the validation on API requests, form submissions, etc.

In these cases, it's hard to determine which is the best gitmoji to use.

It could be business logic, it could be a new "feature" (if you consider validation a feature), it could be a bug fix (updating incorrect validation rules), but in all of these cases, tracking down changes to validation is harder to spot in a commit timeline without an emoji of its own.

The choice of safety vest comes as validation gives visibility to potential errors if the code was to proceed with given data.

Is this use case covered by an existing emoji?

No ❌

Does this emoji fall into the "how" category?

No

Examples

• 🦺 Check chosen Cat object exists in database before form submission
• 🦺 Replace vague validation errors with more helpful ones on Cat creation form
• 🦺 Add CatValidationPipe class and apply to CatController
• 🦺 Fix false positive validation error on Cat creation form

Validations

• [X] Follow our Code of Conduct
• [X] Read the Contributing Guide.
• [X] Check that there isn't already an issue requesting the emoji.

[mike-mccormick]

I'd definitely use this!

[vhoyer]

When faced with this example I generally use the :children_crossing: (Improve user experience / usability), as for systems the likes of an Http API I view that the "user" are the programmers using it, or even the client requesting from this server, so improvements on error validation are definitly a "user experience improvement" in my world view.

What do you think about using this on this cases?

[carloscuesta]

Hey!

I like the idea behind this suggestion 😍

When faced with this example I generally use the :children_crossing: (Improve user experience / usability), as for systems the likes of an Http API I view that the "user" are the programmers using it, or even the client requesting from this server, so improvements on error validation are definitly a "user experience improvement" in my world view.

I understand this point of view but when going through the commit log that could fall into UX / Usability

It could be business logic, it could be a new "feature" (if you consider validation a feature), it could be a bug fix (updating incorrect validation rules), but in all of these cases, tracking down changes to validation is harder to spot in a commit timeline without an emoji of its own.

Personally I would use "business logic" but it's not 100% accurate on this case, so in my opinion I would be happy to introduce this one! 😊

Feel free to send a PR! 🙏🏼