Best practice about using multiple services in one component

user_5098209 0
Viewed 518

I'm looking for a good practice concerning using one component with multiple services.

I have a side navigation menu with 7-8 items in it. Clicking on them should open up a component to edit a simple form, and send the updated data to a service that corresponds to the selected navigation item.

// responses-routing..
const responsesRoutes: Routes = [
  {
    path: 'responses',
    component: ResponsesComponent,
    children: [
      {
        path: '',
        component: ResponsesHomeComponent
      },
      {
        path: ':type/:childUrl',                <----- here
        component: ResponsesEditComponent
      }
    ]
  }
];

I'm currently using one component (ResponsesEditComponent) to

1) Get the "type" and "childUrl" fields from the url (This url is navigated to using the router and the side navigation menu. The params are extracted using activatedRoute)

2) Take very basic user input

3) Make a service call to send taken input. The decision to use a service depends on the "type" and "childUrl" fields received from the parameters.

The 7-8 menu items will have sub-items at some point, which also will be using the services that belong to their parent menu item.

The current system may work if I proceed with it, however I feel there should be a better way to handle this. Injecting 8 services to the service, and having to decide on which service to use on every submit button click doesn't feel like the best way to go with it.

I'm considering to

  • separate the one route into 8 routes
  • use 8 components instead of 1, each corresponding to a menu item
  • inject 1 corresponding service to each component

but it seems to be just repetitive work.

Would you mind explaining how you would approach such a scenario, or pointing out a related concept I might not be familiar with?

Cheers.

angular7 angular6 angular-routing angular frontend
2 Answers

Common behavior induces common components.

In Angular, you code by composition rather than by extension : you implement several interfaces (OnInit, AfterViewInit, CanActivate, etc.) to your classes, defining their behavior, instead of extending your classes with other classes.

If I had 8 routes, that do the same thing but call different endpoints, I would :

  • Make 1 component
  • Make 1 service
  • Use resolvers to override the API URL of each route

If the 8 routes had slightly different behaviors, I would

  • Make 1 service
  • Make 1 component
  • Use a component factory resolver to create components with slightly different behaviors
Admin1

I'd make these two things more standalone. Side nav item does not need to know about any ResponsesEditComponent services. It could have it's own service, and, say, ActivatedRoute. From the ActivatedRoute, you can deal with the state of the nav menu. From the service, you can subscribe to any "highlight this or that" events. And the service can emit these events by being injected with your ResponseEdit services.

And the ResponseEditComponent should likely also just have one wrapper service. That is easy, almost trivial, to test. Send the component a given :type and :childUrl (get them more descriptive names, please). Draw the appropriate form (maybe you can have different subcomponents for different forms, further separating of layers). Load the form data, if any, based on the given type. When the form (or nested component) emits a change, e.g. Save event, call the service with simple (type, childUrl, emittedData). The service should be able to determine which subservice to redirect the save to.

So yeah, splitting route into 8, is not that bad, but the alternative is to simply have different components for different forms. Likely this way you avoid some repetition, but add the overhead of the statefull, management component.

user_1620700
Related