search

plumatic / dommy

A tiny ClojureScript DOM manipulation and event library
759 stars 74 forks source link

deftemplate requires dommy.core import #25

Closed eagleflo closed 11 years ago

eagleflo commented 11 years ago

Hi,

I was updating from 0.0.2 to 0.1.0 and noticed some breakage related to the deftemplate macro and inline styles. The compile-add-attr! macro refers to dommy.core/style-str, which leads to:

Uncaught TypeError: Cannot read property 'style_str' of undefined
if(cljs.core.truth_(cljs.core.ObjMap.fromObject(["\ufdd0'width"], {"\ufdd0'width":"100%"}))) {
        dom3877.setAttribute("style", dommy.core.style_str.call(null, cljs.core.ObjMap.fromObject(["\ufdd0'width"], {"\ufdd0'width":"100%"})))

Workaround for this is to require dommy.core somewhere in your application manually. Shouldn't the deftemplate macro work independently, though?

aria42 commented 11 years ago

Unfortunately it can't. In order to share compile/runtime templating the compile stuff must fallback to runtime to ensure user doesn't need to be totally aware of what can be done at compile time. This isn't actually a new issue, the older dommy template macro stuff depended on the runtime template file as well.

The rule is if you use dommy.macros macros, you must also require dommy.core. We could probably make it so deftemplate emitted a "goog.require('dommy.core');", which seems a bit hacky to me, but I'm amenable. What do you think?

cpetzold commented 11 years ago

Closing this for now, but feel free to continue the discussion.

eagleflo commented 11 years ago

I'd rather have the dependencies handled by the dependant macro namespace, but if ClojureScript doesn't currently make this easy to do in a non-hacky way, I'm amenable to leaving it to documentation.

We ended up doing the "phantom" dommy.core require with a fat warning of nonobvious dependency.

By the way, is there a similar dependency on dommy.template by dommy.macros/node?