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
Hi - loving DI, using it daily. Great tool, with a really tiny footprint. I've been living in my own fork for a while, though I did (hand merge) your latest changes in today. I have some changes (in addition to the ones I wrote up just a bit ago on a couple of other issues here) that if they were pulled, I could remove my fork and use your repo - so wanted to see if these were interesting or not!
A great benefit of DI is how small it is, and a platform I target (along with Node) is called Moddable. It's a (nearly) fully compliant ES2021 implementation of JS for embedded microcontrollers, and it works great with DI and TypeScript. For it to link / build, it needs a file called manifest.json. Adding this file would not change anything about DI, but would enable building on Moddable.
The other change is that I added a static getter that acts as a singleton to retrieve an instance of DIContainer. With my monorepo and how I organize tests, it's really nice to be able to say DIContainer.container().get<MyType>(), and this way the container is shared across all my cross-linked projects in my monorepo (since it is a shared singleton instance of DIContainer.
One thing I do a lot of, by the way, is register in a library the various injectables (in it's index.js) so when the library is referenced, all injectables are ready and waiting. Then, in my test code (often in a different library), I commonly register the same type, but pointing to a mock or spy instance. It's great that DI handles that cleanly with overriding a previously registered type. Not sure if that was by design or intentional, but it's a wonderful capability that I wanted to mention in case future changes might disrupt that behavior!
If you are interested, I can create a new fresh branch and apply just the select needed changes with updates to the README accordingly and do a pull for your review.
Let me know your thoughts, and it's great to see you updating the code base! Thanks.
The text was updated successfully, but these errors were encountered:
Thanks, I'm very glad you like it and see value in the tool. I definitely want to help you out here, and I am open to adding first-hand support to Moddable.
Feel free to come up with a PR, and I'll take a look at it.
Thanks again!
Hi - loving DI, using it daily. Great tool, with a really tiny footprint. I've been living in my own fork for a while, though I did (hand merge) your latest changes in today. I have some changes (in addition to the ones I wrote up just a bit ago on a couple of other issues here) that if they were pulled, I could remove my fork and use your repo - so wanted to see if these were interesting or not!
A great benefit of DI is how small it is, and a platform I target (along with Node) is called Moddable. It's a (nearly) fully compliant ES2021 implementation of JS for embedded microcontrollers, and it works great with DI and TypeScript. For it to link / build, it needs a file called
manifest.json
. Adding this file would not change anything about DI, but would enable building on Moddable.The other change is that I added a static getter that acts as a singleton to retrieve an instance of
DIContainer
. With my monorepo and how I organize tests, it's really nice to be able to sayDIContainer.container().get<MyType>()
, and this way the container is shared across all my cross-linked projects in my monorepo (since it is a shared singleton instance ofDIContainer
.One thing I do a lot of, by the way, is register in a library the various injectables (in it's
index.js
) so when the library is referenced, all injectables are ready and waiting. Then, in my test code (often in a different library), I commonly register the same type, but pointing to a mock or spy instance. It's great that DI handles that cleanly with overriding a previously registered type. Not sure if that was by design or intentional, but it's a wonderful capability that I wanted to mention in case future changes might disrupt that behavior!If you are interested, I can create a new fresh branch and apply just the select needed changes with updates to the
README
accordingly and do a pull for your review.Let me know your thoughts, and it's great to see you updating the code base! Thanks.
The text was updated successfully, but these errors were encountered: