SFC compiler: optional chaining generates different event #4107
Labels
🔨 p3-minor-bug
Priority 3: this fixes a bug, but is an edge case that only affects very specific usage.
has workaround
A workaround has been found to avoid the problem
🐞 bug
Something isn't working
scope: compiler
scope: sfc
Version
3.1.4
Reproduction link
https://sfc.vuejs.org/#eyJBcHAudnVlIjoiPHRlbXBsYXRlPlxuICA8ZGl2IEBjbGljaz1cImEuYlwiPkNsaWNrICh3b3Jrcyk8L2Rpdj5cbiAgPGRpdiBAY2xpY2s9XCJhPy5iXCI+Q2xpY2sgKGJyb2tlbik8L2Rpdj5cbjwvdGVtcGxhdGU+XG5cbjxzY3JpcHQgc2V0dXA+XG5jb25zdCBhID0ge1xuICBiKCkgeyBhbGVydChcIndvcmtzXCIpIH1cbn1cbjwvc2NyaXB0PiJ9
Steps to reproduce
Click on the repro divs, one works, the other doesn't.
The reason why is evident if you look at the generated JS code.
SFC compiler handles event listeners that are an expression, such as
a.b
, as functions themselves and invokes(...args) => a.b && a.b(args)
It does not consider
a?.b
to be such an expression, though, and invokes() => a?.b
.What is expected?
Both works
What is actually happening?
Only first link works
You could take this opportunity to optimise generated code
a.b && a.b(...args)
intoa.b?.(...args)
.Not only is the latter shorter, it also evaluates the first part only once, which might be relevant if there are side-effects -- and one common side-effect is reactivity tracking, so it's just more performant.
Downside: if targeting a browser that doesn't support optional chaining, the code needs to be transpiled. With evergreen broswers, everybody supports it nowadays (Chrome 80, FF 74, Safari 13.1): https://caniuse.com/mdn-javascript_operators_optional_chaining
PS: The issue creation app replaces
everywhere, including in the repro link and that breaks links to sfc.vuejs.org.
+
withThe text was updated successfully, but these errors were encountered: