Decouple components

[raitisbe]

Feature Request

Hslayers components are not tree-shakable and all of them are included in every application which uses hslayers. For example trip-planner, sharing and location, add-data searching functionality might not always be needed, but still are included in all applications. Add data is especially heavy because it imports large OL modules (KML support).

• We should reduce the cross importing of hslayers modules (services)
• HsLayoutComponent and its PanelSpace should be dynamically populated with components from container application, similarly as with dialog modals and toasts.
• Move nonessential module imports out of HsCoreModule into HsLayersModule which would contain everything
• Make importing of HslayersModule optional giving container application developers the possibility to import HsLayers modules separately similarly how it is done with NgBootstrap - NgbModule vs NgbPaginationModule (https://ng-bootstrap.github.io/#/getting-started#imports)
• Just an afterthought about HsEventBus . Its actually good to use event bus for this reason, because it reduces the interdependency of HsLayersModules, even though the event Subjects are not grouped by function, but by form. If we want to have some decoupling between modules still, but don't want to use HsEventBus, then we can split the RxJs Subjects out of the particular modules/services into small files having just the subjects exported as constants. In that case we can import those and not import the Hs.. Angular module with quite many components and services for some of the panels.

[jmacura]

https://angular.io/guide/architecture-services#providing-services https://angular.io/guide/lightweight-injection-tokens

[raitisbe]

https://angular.io/guide/architecture-services#providing-services https://angular.io/guide/lightweight-injection-tokens

Very interesting, even if we are not using @ContentChild that much. Wonder if those tokens would work for dynamic components such as dialogs or panels (later)

[jmacura]

https://angular.io/guide/architecture-services#providing-services https://angular.io/guide/lightweight-injection-tokens

Very interesting, even if we are not using @ContentChild that much. Wonder if those tokens would work for dynamic components such as dialogs or panels (later)

Aye, it won't affect us that much now, as I can't recall we use @ContentChild anywhere. Meanwhile I found this Medium article which seems to be much more relevant to us: https://tomastrajan.medium.com/the-best-way-to-architect-your-angular-libraries-87959301d3d3