refactor #3
refactor #3
Conversation
…ebugNamespace and _debugSuffix
| return name; | ||
|
|
||
| return function debug() { | ||
| var fn = require('debug'); |
There was a problem hiding this comment.
require('debug') should only be called once to avoid the logic inside require
There was a problem hiding this comment.
Is lazy-cache do the job as I (we/you) expect?
Or this will also work? (it seems it work, but is really work? lol)
var fn = requiresCache.debug || (requiresCache.debug = require('debug'));i'm not very familiar with caching and how to test it.
| app.debug[ns] = debugFactory.call(app, ns); | ||
| app.debug[ns].color = app.debug.color; | ||
| } | ||
| } |
There was a problem hiding this comment.
you need to return plugin so that debug will be propagated down the "plugin tree". Let me do an illustration so this makes sense.. brb
There was a problem hiding this comment.
Yea, okey.
It would be good to see some use-case / example, and i'll add a test.
There was a problem hiding this comment.
(this is for the templates docs, but it will help explain how plugins work in base. you obviously already know a lot about plugins, so this is for anyone who might find it useful)
Plugins
Overview of how
Templatesplugins work
App
The following example shows a plugin that will be invoked by the .use method. Example: app.use(plugin). When invoked, the plugin function is passed the application instance (app) as its only argument.
The plugin stops there and will not be called again, unless the plugin returns a function. If a function is returned it will be pushed onto the app.fns array and then called on each collection that is created using the app.create, app.collection, or app.list methods.
In the next example, a function is returned from the plugin so that it can be called again later.
Collection
The plugin stops there and will not be called again, unless the plugin returns a function. If a function is returned it will be pushed onto the collection.fns array and then called on each view that is added to the collection.
In the next example, we'll return a function inside the collection plugin, so that it can be called again later.
View
End of the line...
Short-circuit: "smart plugins"
Don't like all the function nesting? Want to register your plugin with
appbut only have it run on specific objects? No problem, just short-circuit the plugin!
Every class has a boolean .is* property that is useful for checking the instance name. For example, the Templates class has an isTemplates property, view collections have isViews, and views have isView. (all "apps", like Templates, Assemble, Generate, etc. also have isApp as a convenience).
To make your plugins "smarter" and eliminate the nesting, try the following:
Generators
There was a problem hiding this comment.
Yea.. it's.. damn, you're not a human being, 😆
I was a bit familiar with it, but didn't realize it is so big and awesome, and that it can be so nested.
Great clarification.
There was a problem hiding this comment.
haha, well it took me a while but I had to figure out how to use the diagram tool lol. glad you find it useful
but didn't realize it is so big and awesome
thanks! I just added a screen to show how plugins can be used with generators. this is only a high-level overview of part of the ecosystem. we still need to show verb, update, sub-generators, routes and middleware, and other parts of the build cycle.
it would be awesome if we could find a tool that makes it easy to create diagrams like these. most of the tools I've seen are for the browser or take a lot of work to create something that looks nice
That's it. As commented.
cross-ref: base-repos/base-namespace#1, base-repos/base#12
only need misc stuff, code comments, readme and etc, i'll get to them later.