-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
fix: rework directive name handling #9470
Conversation
|
Uh I didn't realized that sorry |
The latest updates on your projects. Learn more about Vercel for Git ↗︎
|
Not at all! None of this stuff is all that obvious, I was just explicitly flagging it so it didn't seem like i was passively-aggressively rewriting code for no reason :) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The reason I was against adding it to the AST is that for example prettier relies on these fields for printing, because they're verbatim, so no need to extract them from the original source
Unfortunately #9462 introduced a bug (cc @paoloricciuti and @dummdidumm) — a directive like
use:a.b.c-d
needs to becomeget(a).b['c-d']
ifa
is state (mutatis mutandis if it's a prop).This was surfaced by TypeScript as soon as I rewrote
member_expression_id_to_literal
to return an expression instead of a string (mostly because I wanteda.b.c-d
to result ina.b['c-d']
rather thana['b']['c-d']
, becauseserialize_get_binding
will only accept anIdentifier
.I also got rid of the snapshot test. We should use these extremely sparingly — most of the time we don't care that much about the precise nature of the generated code, we only care about whether the generated code is valid. Snapshot tests are annoying because they frequently need to be updated for reasons unrelated to the test itself.
I'm not sure I agree with the decision in #9462 to do this at transform time rather than parse time. For the sake of things like sourcemap generation, it's good to preserve as much information about node start/end as possible, and it means we can apply this logic in a single place. I haven't done that yet though, we should discuss.
Finally, by working through this problem I think I've uncovered a separate bug — animate/transition directives 'lock on' to the directive value at component init time, even though it may change by the time the directive takes effect. It's less broken than it is on main, but it's still broken. Will create a follow-up issue/PR for that once this is merged.