Menu
I come from Java world where services are commonly meant to be stateless. Should be services in Angular2 also stateless? Or can we simply store the state, because we do not have to care about concurrent thread access as in Java example?
At https://angular.io/docs/ts/latest/guide/router.html#!#teach-authguard-to-authenticate in AuthService class the state is stored.
Is it just to simplify the example or is it a common practice? I know that services are instantiated and live for the scope where they are declared, but that would mean that I would have to care where the service has been provided to know how long the state lasts.
758
These loosely-coupled, heterogeneous, and composite applications require that all Services should be stateless such that they don't impose their knowledge of a system or process unnecessarily on other parties, thus tightening their level of coupling, reducing their ability for reuse, and limiting broad applicability.
The Service Statelessness principle provides guidelines in favor of making the service stateless by shifting away the state management overhead from the services to some other external architectural component. This further helps in the overall scalability of the service-oriented solution.
All of the above Angular 2 components are stateless. They have no knowledge of their surroundings, but are passed data via property bindings and emit changes via event callbacks.
Stateless Protocol is a network protocol in which Client send request to the server and server response back as per the given state. Stateful Protocol is a network protocol in which if client send a request to the server then it expects some kind of response, in case of no response then it resend the request.
It's usually a good idea to have components stateless and store the state in a service, especially in components added by the router, so that navigating away and later back to a route, doesn't drop the data.
Therefore to your question: Services are not supposed to be stateless. They often are, but it's not required.
You can use an NGRX Store to store the state instead, but that's a service as well.
I would have to care where the service has been provided to know how long the state lasts.
Yes, that's what you have to do. It's usually quite easy. If you want a service and its state to be available during the whole application lifetime, you provide it in @NgModule() (needs some special handling for lazy loaded modules), otherwise you provide it at a component, and the lifetime of the service will end with the component instance being destroyed.
141
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
