Is it a good practice to use shared services to avoid duplicate API calls for fetched data?

I have a scenario where I fetch vehicle details from the backend in one component (ValuationComponent). Once the data is fetched, I need to use the same data in another component (OtherComponent) for various operations.

Instead of making a separate API call in OtherComponent, I'm considering using a shared service to store the fetched data from ValuationComponent and retrieve it in OtherComponent. This way, I can avoid duplicate API calls and ensure consistent data across components.

Is this approach considered a good practice? Are there any potential drawbacks or alternative solutions I should consider?

In my scenario, I have successfully fetched vehicle details from the backend in the ValuationComponent using an API call. The fetched data is stored in a local variable within the component.

In the Other Component, I want to access the same vehicle details without making an additional API call. To achieve this, I'm considering using a shared service that holds the fetched data. This way, I can simply retrieve the data from the shared service in Other Component.

Yes, that's absolutely a valid scenario for using a service.

To take it one step further, rxJs / observables make it even easier without needing to cache it yourself with operators like shareReply

> You generally want to use shareReplay when you have side-effects or taxing computations that you do not wish to be executed amongst multiple subscribers. It may also be valuable in situations where you know you will have late subscribers to a stream that need access to previously emitted values. This ability to replay values on subscription is what differentiates share and shareReplay.

Using a shared service to store and retrieve data between components is a common approach in Angular applications, and it can be a good practice in certain scenarios. It helps avoid redundant API calls and ensures consistent data across components.

However, there are a few considerations and potential drawbacks you should keep in mind:

1. Data consistency: When using a shared service, you need to ensure that the data stored in the service remains consistent and up to date. If the data changes on the backend while the user is interacting with your application, you need to handle updating the shared data appropriately.

2. Data sharing scope: Make sure to consider the scope of the shared service. If you need the data to be accessible only within a specific module or component hierarchy, you should scope the shared service accordingly. If the data needs to be shared globally across the entire application, you can provide the shared service in the root module.

3. Dependency management: If multiple components depend on the shared service, it's important to consider the dependencies and potential impact of changes to the service. If you make changes to the shared service implementation, ensure that it doesn't inadvertently affect other components relying on the data.

4. Data synchronization: If the fetched data in the shared service can change over time, you may need to implement mechanisms to update the shared data whenever it changes on the backend. This could involve using websockets, long polling, or periodic polling to keep the data synchronized.

Alternative solutions to consider:

1. State management libraries: Instead of using a shared service, you
   could leverage state management libraries like NgRx or Akita. These
   libraries provide a centralized store for managing application state
   and can handle data sharing between components effectively.

2. Caching mechanisms: You could introduce a caching layer in your
   application to store the fetched data temporarily. When a component
   needs the data, it first checks the cache, and if the data is
   available, it can use it directly. This approach can help reduce API
   calls and improve performance.

3. Component communication: Depending on your component hierarchy and
   data flow, you could explore options for component communication,
   such as input/output properties, event emitters, or RxJS
   subjects/observables. This way, the ValuationComponent can directly
   pass the fetched data to the OtherComponent when necessary.

Ultimately, the best approach depends on the specific requirements and complexity of your application. Evaluate the trade-offs and choose a solution that provides a good balance between data consistency, performance, and maintainability.