These are some rules that I have lazily picked up over the past four years of professional development on angular.
I generally work on small to medium projects without the time to integrate a formal state management system.
It is for this reason that there are data services that try to solve the problem of carrying communication around. If anyone has any further questions or curiosities regarding these points feel free to leave a comment.
- methods must be extracted into functions until nothing can be extracted anymore
componentlogic shold refer only to local resources of the
componentas much as possible
dataservicesdeal with data I/O with the server
- the business Logic must live within the
dataserviceand all components should be of assistance to the business Logic, visualization assistance and small local logics to visualize and modify data
components(internal to the feature internal to the root component) must implement the root
dataserviceor receive data as input (observables are strongly preferred)
- avoid multi-level handovers through inputs, it slows you down and makes refactoring a hassle
- if the data as input changed hands more than twice use a
- each feature must have its own module and declare
componentsrelated only to that feature
- putting the general
dataservicenext to the feature module is the best way to indicate the root from which to start exploring the code
- the beginning of the end of the data flow must take place within the
- the substrate
cache-servicesfor API calls must live in the provide of the feature module they belong to and refer to
componentscan be interaction contexts between
dataservicesbut services are preferred when possible
interaction servicescan be interaction contexts between