Skip to content
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(ssr): only default-exported classes are LWC components @W-17312358@ #4942

Merged
merged 7 commits into from
Nov 26, 2024

Conversation

wjhsf
Copy link
Contributor

@wjhsf wjhsf commented Nov 25, 2024

Details

Fixes #4938.

Does this pull request introduce a breaking change?

  • ๐Ÿ˜ฎโ€๐Ÿ’จ No, it does not introduce a breaking change.
  • ๐Ÿ’” Yes, it does introduce a breaking change.

Does this pull request introduce an observable change?

  • ๐Ÿคž No, it does not introduce an observable change.
  • ๐Ÿ”ฌ Yes, it does include an observable change.

GUS work item

@wjhsf wjhsf requested a review from a team as a code owner November 25, 2024 21:57
} else {
node.id = b.identifier('DefaultComponentName');
state.lwcClassName = 'DefaultComponentName';
}
Copy link
Collaborator

@nolanlawson nolanlawson Nov 25, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is actually a lot of logic that the babel-plugin-component currently does to try to distinguish LightningElement classes from non-LE classes:

function needsComponentRegistration(path: DeclarationPath) {
return (
(path.isIdentifier() && path.node.name !== 'undefined' && path.node.name !== 'null') ||
path.isCallExpression() ||
path.isClassDeclaration() ||
path.isConditionalExpression()
);
}

if (
node.superClass === null &&
isAPIFeatureEnabled(
APIFeature.SKIP_UNNECESSARY_REGISTER_DECORATORS,
getAPIVersionFromNumber(state.opts.apiVersion)
)
) {

The first controls registerComponent โ€“ if a component is not registered, then we'll throw an exception at runtime.

The second controls whether decorators are transformed.

I guess at the end of the day we only have to be 1-to-1 compatible if 1) a compiler error is not going to be thrown somewhere, and 2) the ssr-compiler is stricter than the pre-existing toolchain. (#1 is because, on core, components will be compiled both for SSR and CSR, so if CSR throws then we are fine. Dangling @apis on non-LE classes will throw eventually because decorators are not supported natively in Babel yet.)

So I guess I am saying this is fine, but we will probably keep discovering edge cases as we go.

@@ -0,0 +1,7 @@
export const FancyMixin = Class => {
return class extends Class {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

TODO: What happens if this mixin has decorated props?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I actually do that in production ๐Ÿ˜†

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@wjhsf wjhsf merged commit b04442f into master Nov 26, 2024
11 checks passed
@wjhsf wjhsf deleted the wjh/export-default-class-extends branch November 26, 2024 20:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

SSR compiler interprets all classes with superclasses as LWC components
3 participants