intravenous
intravenous copied to clipboard
sagacity
Store a class instead of an instance
I'm interested in this as well.
If i my module's factory returns a class, it is not possible to normally use the class. intravenous forces me to call .get(…) in every place where this class is used. subclassing is also made impossible by this.
@mathieug Why would you want to do it anyways?
@derhuerst
Define "normally" please. You can use the class directly via require anywhere. May be you should post some more code here.
@tusharmath I just think intravenous does an unnecessary thing here. Besides limiting me in how to use the class, it also introduces more complexity in the code base. I'd like it to just return the class.
I don't mean to self promote, but node-ioc is something that can help you create custom factories.
const IOC = require('node-ioc')
const container = new IOC()
class SampleClass {}
// register takes a factory function for SampleClass
container.register(() => SampleClass).as(SampleClass)
container.resolve(SampleClass) // returns the class and not the instance.
I would like Intravenous to Store a class but return a NEW instance on every call to container.get('..') . As currently I get an entry point class in the controller the entry point class which is actually my service has dependencies on other classes and these classes have dependencies on some other class which are injected through their constructors. Intravenous creates the whole graph and gives me the service class. The service class processes the request and returns the result this all falls in line with the strategy of keeping controller as dumb as possible. After returning the result I would like to dispose the service class as some the library classes used by one of its dependencies is leaking. So I have defined "dispose" method on all the classes and in this method set its class variables reference to null and also call the external libraries close() or end() method where ever required. But once I dispose the service class intravenous call the dispose on its cached instance of service class and in the next request or parallel request the dependencies references are all null.
This is probably a good place to point out that I'd recommend you take a look at the libraries shamelessly promoted by the others :)
As you may be able to tell from the commit logs I'm not really actively developing this library anymore since I don't really have the need for it anymore.
Out of curiosity, what is the reason for why you don't need this library anymore?
Well, for server-side stuff I'm doing Java mostly nowadays and client-side I think ES6 modules are a pretty decent alternative, especially combined with React/Redux. You don't need dependencies accessible from everywhere, instead you only (mostly) need them in the reducers and then they're just a require away :yum: