You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Ideally we like to see entities follow a consistent pattern of:
The entity class declaration
any custom relations, i.e. readonly numberOfBooks = hasPersistedAsyncPropety
the constructor
methods/async methods with business logic
getters/setters
Validation rules
Simple validation rules i.e. config.addRule(a => ...)
Reactive validation rules i.e. config.addRule("firstName", a => ...)
Hooks in the order that Joist runs them
beforeCreate
beforeUpdate
beforeFlush
etc.
Approaches
The most traditional approach for this would be an eslint rule(s).
An alternative would be the config API at boot-time what "phase" it's in it, and throw an error if a previous phase is called. However we'd needed exceptions for helper methods (like our internal addCollaborationUtils that adds multiple hooks) and also wouldn't get order of fields/cstr/getters within the class.
The text was updated successfully, but these errors were encountered:
Ideally we like to see entities follow a consistent pattern of:
class
declarationreadonly numberOfBooks = hasPersistedAsyncPropety
config.addRule(a => ...)
config.addRule("firstName", a => ...)
Approaches
The most traditional approach for this would be an eslint rule(s).
An alternative would be the
config
API at boot-time what "phase" it's in it, and throw an error if a previous phase is called. However we'd needed exceptions for helper methods (like our internal addCollaborationUtils that adds multiple hooks) and also wouldn't get order of fields/cstr/getters within theclass
.The text was updated successfully, but these errors were encountered: