sithmel / diogenes Goto Github PK

There should be something in place to automatically cache a service when dependency are unchanged

The goal of this release is to focus on using diogenes as dependency injection framework.

Version 1 relies on an asynchronous caching mechanism.
It was complicated to implement and also useless. Furthermore the cached value should be JSON serializable which is pretty stupid for a library used for dependency injection (for example you can't cache an object instance or a function).
So I need to:

• Use simple LRU cache object
• Back to synchronous simple deep-first-search

I'd like to cut any dependency from async-deco (maybe I would use the log).

• No decorator features

Event system is something should be implemented outside of diogenes:

• remove event system

Other improvements:

• a run method that return a promise
• dependsOn should also take a function that return an array of dependencies
• run should be able to take a regular expression as argument. Returning all services matching that regexp

Lastly I'd like to enphasize in the documentation that it is a dependency injection framework, not a library for dealing with asynchronicity.

• fix the doc

• Add a variation of addService for adding values. Useful for singleton objects that don't need config.
• addone method for adding a service to be executed only once
• getservices method to return multiple services
• cache method. To add a layer of cache to a service.
  Registry.cache(name, getKey,ttl)
  Getkey can be undefined, string, or a function. Ttl time to live. Default to Infinity.

Example:

registry.service(function example (deps) {
...
});

Would be the equivalent of:

registry.service('example').provides(function (deps) {
...
})

Also:

registry.service(function example (deps) {
...
})
.dependsOn([ref1, ref2]);

With ref1 ref2 as real functions rather than strings.

Maybe also an alternative shorthand:

registry.service([ref1, ref2], function example (deps) {
...
})

and a curried version to use as decorator

@registry.addService([ref1, ref2])
function example (deps) {
...
}

it should be easy doing something like:

function example() {
/**
Some text
**/
...
}

/\/\*\*(.+?)\*\*\//.exec(example.toString())

Extra goal: add markdown2html to diogenes-lantern

Some graphic representation of the graphs can help understand how the system work

Adding a system to invalidate the cache of a service:

• when a new service is added
• when a service is explicitly invalidated

• remove caching (making it standalone)
• dependsOn should never make the registry inconsistent (dependsOn adds nodes to the graph)
• diogenes express: manage graceful shutdown, express integration
• diogenes lantern should use "next"
• dependsOn should not get a function
• dependsOn could be an object to translate dependency names to object

Now if a configuration doesn't match any service, occamsrazor throws an exception.
There may be cases in which I don't need a service at all, so no need of complaining.

It should be possible to add extra deps while running:

registry.run('hello', { world: 'world' })

I had a few thoughts about diogenes API. The trigger for all of them was the use of decorators.

I really think that the decorator pattern fits particularly well in diogenes. You can enhance a service with caching/logging and many different features (just open async-deco and see how many things can be done).
Some of the current features don't fits well if you use this pattern, basically all features relying in introspecting the functions for its name and arity.

So I propose this set of changes:

remove the feature of using a function in the registry.service method and remove the feature of using an array of functions in the service.dependsOn method

cons

• we lose a shortcut to define a service
• it is not possible using the editor features to jump on a dependency

pros

• we can use decorators without bothering to set or reset the name of the decorated function
• we can easily implement a namespace feature, defining a service with the string "controller:renderpage" and then having the dependency as "renderpage"
• we lose an extra way to perform the same task

a service can't use callbacks

I used the arity of the function to guess if the service is callback based. But the decorator won't have the same arity. All my decorators for example use "arguments".

cons
I think we might need to define services with callbacks frequently, especially migrating from old code.

pros
it can be fixed easily using promisify (doh another decorator)

As a side note I would like to know what do you think about adding a special feature to define and compose decorators in diogenes.
I was thinking of something like

diogenes
  .service('myservice')
  .provides([cache, promisify, myservice])
  // or .provides(cache, promisify, myservice)

equivalent to:

diogenes
  .service('myservice')
  .provides(cache(promisify(myservice)))

but it can be just as good doing:

@cache
@promisify
function myservice() {
  ...
}

diogenes
  .service('myservice')
  .provides(myservice)

But the decorator specs are still in discussion ....

What's your thoughts @framp @mikeryancodes