Open just-boris opened 8 years ago
I suspect that the second variant is slightly better, cause it's easier to understand and to use. Also it restricts undocumented ways of usage.
But still, we have to provide the full API if the user will require runtime
module.
btw, I just thought, we can wrap runtime.js
module in the custom API also. Since we are making a wrapper for the template engine wrapper, we need only two possibilities: to add new template and to transform bemjson into html.
What do you think, if we implement runtime.js
module with smthing like that:
var bh = new require('bh').BH;
module.exports = function (bemjson) {
return bh.apply(bemjson);
}
module.exports.add = function (name, template) {
bh.match(name, template);
};
The last example is not ok because method add
doesn't match with bh's method match
. It is confusing.
Also, I don't think that we have a custom API. We are just instantiating BH. ENB does exactly the same thing here: https://github.com/enb-bem/enb-bh/blob/master/techs/bh-commonjs.js#L129
Well, I wanted to make it slightly better. Also I wanted to have the same API from the template and runtime.js
.
Consider two options.
the second option is nice because it exposes function as well it does
handlebars
and jadeloaders