You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I started playing with this project in order to explore options for plugging in this project to different backends (different caches, queries) while preserving the api surface area.
Unfortunately, this project's dependencies (different classes) are highly dependent on each other which makes it hard to customize.
I saw some customization efforts being done in v5 but what I'm suggesting should make the code modular and extensible by design.
I suspect this will also make adoption and customization easier for libraries such as tRPC, and encourage more libraries to integrate with this project.
Note: The code might be non-modular and tightly coupled by design, and so maybe this is not something you're looking for. It's something I'm planning to do anyway so I thought I'll share this.
The following is a subset of the dependency graph of query-core, as it's currently built:
"Instance" means that the class directly instantiates the class that the arrow points to.
"Extends" means that it extends this class.
The following is a rough idea of how to make this part of the code more modular
The arrows represent a dependency graph described via interface inheritance and implemented via dependency injection.
Downside: Since this codebase is OOP based, dependency injection will be based off of something like inversifyjs which requires reflect-metadata and experimental decorator support. This increases installation friction for the end user as reflect-metadata must be imported exactly once so the user should do that.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
Uh oh!
There was an error while loading. Please reload this page.
-
I started playing with this project in order to explore options for plugging in this project to different backends (different caches, queries) while preserving the api surface area.
Unfortunately, this project's dependencies (different classes) are highly dependent on each other which makes it hard to customize.
I saw some customization efforts being done in v5 but what I'm suggesting should make the code modular and extensible by design.
I suspect this will also make adoption and customization easier for libraries such as tRPC, and encourage more libraries to integrate with this project.
Note: The code might be non-modular and tightly coupled by design, and so maybe this is not something you're looking for. It's something I'm planning to do anyway so I thought I'll share this.
The following is a subset of the dependency graph of query-core, as it's currently built:

"Instance" means that the class directly instantiates the class that the arrow points to.
"Extends" means that it extends this class.
The following is a rough idea of how to make this part of the code more modular

The arrows represent a dependency graph described via interface inheritance and implemented via dependency injection.
Downside: Since this codebase is OOP based, dependency injection will be based off of something like inversifyjs which requires reflect-metadata and experimental decorator support. This increases installation friction for the end user as reflect-metadata must be imported exactly once so the user should do that.
Thank you for your time and effort.
Beta Was this translation helpful? Give feedback.
All reactions