-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
refactor: turn main service into a class again #914
refactor: turn main service into a class again #914
Conversation
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @davidlj95 and the rest of your teammates on |
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #914 +/- ##
==========================================
- Coverage 99.45% 99.45% -0.01%
==========================================
Files 79 79
Lines 370 369 -1
Branches 68 68
==========================================
- Hits 368 367 -1
Partials 2 2 ☔ View full report in Codecov by Sentry. |
📦 Bundle size (Angular v18)Git ref:
|
📦 Bundle size (Angular v17)Git ref:
|
📦 Bundle size (Angular v16)Git ref:
|
📦 Bundle size (Angular v15)Git ref:
|
🎉 This PR is included in version 1.0.0-beta.17 🎉 The release is available on: Your semantic-release bot 📦🚀 |
Issue or need
In #873, the main service
NgxMetaService
was turned into an abstract class so that it could use a provider to provide the implementation and save a few uncompressed bytes (171 bytes in v18)However, didn't realize that introducing this change would make the service not tree-shakeable. Given when calling
provideNgxMetaCore
(or the module-based equivalent API), it would always be provided.Even if unused.
Proposed changes
Turn it back into a service provided in
root
. This way it can be removed from the bundle if unused.Other alternatives considered
Turn it into a lazy injection token
It's not something very Angular'ish. At least yet? So for an external API would seem weird to use by a developer.
Keep it as is, service will be used
It is true that the main service will be almost certainly used. Given it's providing the key piece functionality of the library.
So could assume that it will always be used hence no need to provide it in a tree-shakeable manner. And save those 171 bytes.
But a user may only be interested in one of the utils. So allowing tree-shaking could be interesting for those.
Plus this way APIs follow the traditional Angular way of doing things. So less weird things to expect.
Quick reminders