Since code keeps growing, it turns out that the client side’s structure is far from perfect. I used to have a root containing 2 folders with components and services respectively, and some other common or general stuff. That can be enough for a tutorial, but I’m slightly more ambitious and organized. Also, declarations of every single service polluted the root module in order to make it available in lower levels in hierarchy. Even the documentation recommends organizing services in a hierarchy according to the component tree in order to limit access to them to relevant components only. Import paths are much simpler then as well. So that’s what I’ve done recently – added a bunch of folders for separate pieces of behavior, moved everything suitable into them and adjusted references. Sounds like a piece of cake, but it took some time – the VS Code’s Problems panel doesn’t list all the existing errors from everywhere, but only from open files, I guess. So I had to update a lot of paths in imports after runtime errors. Now services are declared at the lowest possible level – in components, like below (names are sample, the tree in my code is higher):
This is different than in C# where I have one project with all the controllers and another one with all the services. But in C# it works much easier – imports don’t refer to single files only and in particular they don’t refer to file locations.
There could be probably something more done to split the main module into smaller ones so that not only services, but also components are registered on appropriate lower levels only. I’ll consider it in the future though, maybe after having some tests, because now it’s not so burdensome.