fix(lit-html,lit,lit-element): adjust ssr directive patch condition#4988
fix(lit-html,lit,lit-element): adjust ssr directive patch condition#4988
Conversation
…ve needs to be patched by comparing Function.name
🦋 Changeset detectedLatest commit: 8ef20f6 The changes in this PR will be included in the next version bump. This PR includes changesets to release 3 packages
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
augustjk
left a comment
There was a problem hiding this comment.
thank you for getting to the bottom of this!
i think this is a reasonable change. i suppose we never originally figured we could somehow get a new reference to the ssrResolve function if it's coming from the same @lit-labs/ssr code.
Co-authored-by: Augustine Kim <augustjkim@gmail.com>
Description
Adjusted the comparison to use the Function.name property of the
_$resolvefunction and theresolveOverrideFnin private ssr support to prevent attempted duplicative patching of a directive class.It appears that after the first patching the directive, like
classMap, that the conditional check remainsfalse. The member/method on the class is still_$resolve, but its name isssrResolve. Further processing of checking the Prototype of the directive withproto.hasOwnProperty(resolveMethodName)sincessrResolvedoesn't exist. That path leads to an error being thrown and breaks SSR for that render.Hopefully addresses Issue #4527