Closed tpluscode closed 7 years ago
my-behavior.ts
:
export namespace Example {
export const MyBehavior = {};
}
my-behavior.html
:
<script>
window.Example = window.Example || {};
window.Example.MyBehavior = { };
</script>
my-element.ts
:
import { Example } from `my-behavior.ts`
@behavior(Example.MyBehavior)
export class MyElement { }
my-element.html
:
<link rel="import" href="my-behavior.html" />
<dom-module id="my-element">
<script>
Polymer({
behaviors: [ window.Example.MyBehavior ]
});
</script>
</dom-module>
At first glace it seems rather easy. When transpiling imports to JS (currently it works on commonjs output), the above would create a variable like myBehavior_1
. Simply finding the myBehavior_1.Example
or myBehavior_1.MyBehavior
and replacing the myBehavior_1
with window
would probably work (at least in most cases). What do you think?
I would think so. I haven't looked at the code so you'll know better. But yes, for common scenarios it looks rather simple. Let's worry about edge cases (namespaces even) later
I've been thinking about behaviors and decided to split them from #11 as a special case. Not sure how difficult it would be to implement, but maybe it could be possible to handle them in a special way, similarly to what you're doing with
link!...
andscript!...
imports.Here's my idea:
my-behavior.ts
my-behavior.ts
produces a html file with exported behaviors added to global scopeDo you think it is safe to assume that any exported object could be treated as a behavior?
my-element.ts
my-element.ts
is processed by twc and it encounters the import, it would replace it with an import link and correct the reference inbehaviors
array (tsc emits some generated namespace).