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
- the
component
logic shold refer only to local resources of thecomponent
as much as possible -
dataservices
deal with data I/O with the server - the business Logic must live within the
dataservice
and 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 rootdataservice
or 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
dataservice
, - each feature must have its own module and declare
components
related only to that feature - putting the general
dataservice
next 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
dataservice
- the substrate
cache-services
for API calls must live in the provide of the feature module they belong to and refer to -
components
can be interaction contexts betweendataservices
but services are preferred when possible -
interaction services
can be interaction contexts betweendataservices
Top comments (0)