search

exteranto / framework

The Exteranto browser extension framework core packages.
https://exteranto.github.io
MIT License
5 stars 4 forks source link

[utils] should functionality be defined in providers? #75

Closed kouks closed 5 years ago

kouks commented 5 years ago

At the moment, all functionality from @exteranto/utils is bound to the container automatically via @Binding and @Singleton.

Although these are not bound to the container before including them via import { ... } from '...', should it be explicit to the user? Should we instead export optionally registered providers?

Another issue is when a user registers CacheProvider and leaves StorageProvider out. Cache has its dependencies on storage as it uses its APIs but as it is not being registered, an error would be thrown.

porkbrain commented 5 years ago

  1. The concern is that developers would not be sure how to use/register the logic from @exteranto/utils, right? On the contrary, I think this package serves as a great example of using these annotations. Let's write an in-depth description doc for each utils export that is bound to the container implicitly. Even better would be indicating this annotation in docs with a link to the core/container, hence we have this description in one place. This way, when a developer is searching for any of those packages, they actually learn about core functionality they might not know about. I don't mind either though, exporting a Provider or linking class to our docs.

  2. Would adding another optional Provider getter (like only: Script[]) named depends/assumes: typeof Provider[] overkill? I think Provider would be preferable to Dependency (not even sure if we export this).

kouks commented 5 years ago

I think this is now quite well solved with introducing stricter container that throws an exception when a dependency is not found.