-
-
Notifications
You must be signed in to change notification settings - Fork 407
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Replacing moduleName
in template meta
#940
Comments
glimmer vm is also probably passing it as the only template information. captureRenderTree items has a property ``template` which is the same as moduleName |
Isn’t the scope closure good enough? |
Sorry I should be more specific, I was responding to the need for a function to “point at” for jumping to the definition; scopeFn could serve that purpose rather than introducing one specifically for debug purposes only, right? |
Copying my comment from emberjs/ember-inspector#2425 (comment) here: Wee may still need |
Today in the tooling meeting we discussed this and are generally in favor of trying to eliminate I looked around it seems like most places already assume I propose that
|
I don't think HMR should be using import Foo from "./foo";
import bar from "./bar";
<template>
<Foo @foo="..." />
{{bar "some" "args"}}
</template> Should be transformed into something like import { tracked } from "@glimmer/tracking";
import Foo from "./foo";
import bar from "./bar";
// TODO eliminate this when not import.meta.hot
const __imports__ = new (class {
@tracked Foo = Foo;
@tracked bar = bar;
})();
if (import.meta.hot) {
import.meta.hot.accept('./foo', (Foo) => __imports__.Foo = Foo);
import.meta.hot.accept('./bar', (bar) => __imports__.bar = bar);
}
<template>
<__imports__.Foo @foo="..." />
{{__imports__.bar "some" "args"}}
</template> Then everything should just work. |
what about just "name"? export const Foo = <template>
</template>; gets transpiled to: // ...
export const Foo = template('...', { name: 'Foo', /* ... */ }); no user-land customization? |
The point of the feature is for backwards compatibility anyway and I think we either try to preserve existing behavior as much as possible or not do it at all |
if you want it
That would naturally give you the |
it's just |
I think that space is spec-ed/reserved for That being said it does have its issues: e.g. what if you want to make it conditional based on |
Historically, Ember compiles a
moduleName
into the wire format of each template. The Ember Inspector displays this when navigating the hierarchy of components.This isn't really viable going forward, for two reasons:
moduleName
as traditionally understood doesn't exist reliably anymoremoduleName
we would need to faithfully run that transformation, backwards.The existence of Template Tag means that templates are not one-to-one with modules anymore. So identifying which module a component lives in is not enough to unambiguously locate it.
Since templates are javascript values (or to be precise: templates are a detail of components and components are javascript values), it's worth asking: why do we think we need to label them with their module names, when we don't do that with any other javascript values?
I would like to suggest that instead of trying to label components by their template moduleName, we can change the inspector to offer a "jump to definition" button on components.
window.inspect(theComponentInstance.constructor)
already works.templateOnlyComponent()
capture an Exception and save its stack so that it would be possible to navigate back to the site at which the component was defined.A related concern here is that AST transforms can see
moduleName
and I know some rely on it. They need a deprecation path to stop doing that. It's going to troll them anyway as soon as people are using template tag.The text was updated successfully, but these errors were encountered: