Best practice for using multiple libraries in angular 11

[st-clair-clarke]

I'm submitting a...

[ ] Regression (a behavior that used to work and stopped working in a new release)
[ ] Bug report  
[ ] Performance issue
[ ] Feature request
[x] Documentation issue or request
[ ] Support request
[ ] Other... Please describe:

Current behavior

I have two angular libraries A and B, each containing its entity models.

I would like to create two states in my Core module reflecting injectable services for A and B libraries to make them application wide services.

Given the way the akita Store and Query are constructed, this would force me to move all my models to Core module to facilitate the createInitialState() and the generic passed to the Store constructor https://datorama.github.io/akita/docs/angular/architecture.

Since my application will be large this will cause serious bloat to my Core module, and, something I don't want to do.

Is there a way for me achieve what is stated above without importing my entity model to my Core module?

Expected behavior

Minimal reproduction of the problem with instructions

For bug reports please provide the STEPS TO REPRODUCE and if possible a MINIMAL DEMO of the problem via
https://stackblitz.com or similar (you can use this template as a starting point: https://stackblitz.com/github/NetanelBasal/akita-issue-seed).

What is the motivation / use case for changing the behavior?

Environment

Angular 11

Angular version: X.Y.Z


Browser:
- [ ] Chrome (desktop) version XX
- [ ] Chrome (Android) version XX
- [ ] Chrome (iOS) version XX
- [ ] Firefox version XX
- [ ] Safari (desktop) version XX
- [ ] Safari (iOS) version XX
- [ ] IE version XX
- [ ] Edge version XX
 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[kragoth]

My team and I have written quite a large app using akita.
30+ domain entities with more being added soon so, I think I have an idea of what you are going through.

First off though, I think you need to consider if you are asking the right question.
You are concerned about the size of your core module but, there's a number of things to consider here.

1. No matter what path you take, all the entities will exist in some module whether it is the core module or not. Thus, your app size won't change. The core module size might affect your initial load time but, will it affect it significantly? That's very unlikely.
2. You don't need to put entities into the "core" module. Put them all into a shared module that can be imported by any other module. The same goes for your A and B services. Put them into the shared module if you want them available app wide. In our app the core module only contains things that are required for either booting the app or things like header/footer components, security, guards etc.
3. Our shared module contains all things akita (models, stores, queries) and components/services that may be used anywhere in the app.
4. Try think of akita as a persistence layer not as entities that you are dividing into modules. Your persistence layer should be availalbe to your entire app as you don't know what services will require what entities. (You might know today but, it could change tomorrow)

Now more importantly, leverage technology. Use a service worker to cache your files etc.

By and large the code you write is going to be a tiny fraction of the size of the libraries and media that will be packaged with your app. So while caring about size is a good thing, a few kb extra in your module is unlikely going to be a perceivable difference..

For example, my app....

• vendor.js - 6.73MB
• main.js - 348kB
• sharedModule - 2.31MB

The size of the vendor chunk is nearly tripple the size of my sharedModule that cotains a boat load of stuff.

Anyway just my personal opinion.