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(hmr): allow changes to component decorators when using HMR #5290

Merged
merged 1 commit into from
Jan 24, 2024

Conversation

alicewriteswrongs
Copy link
Contributor

This fixes an issue where HMR updates which changed arguments to the @Component decorator would crash the application because a HostRef for the component could not be located.

This occurred because HMR updates caused a new version of the component's lazy bundle to be fetched, which in turn would bundle the getHostRef function and the corresponding hostRefs variable, which is declared here:

export const getHostRef = (ref: d.RuntimeRef): d.HostRef | undefined => hostRefs.get(ref);

Because the newly fetched lazy entry point for the updated component did not have access to the hostRefs variable which was in-scope in the old bundle, the getHostRef function would always return undefined on the first render after the HMR update, causing issues in functions like setValue which make use of a HostRef.

In order to fix the issue we can persist the hostRefs map across HMR updates by storing a reference to it on the window object. We can additionally constrain this persistence to only occur when we're building with HMR, so that we don't clutter up the window object of unsuspecting Stencil users in the context of a production build.

What is the current behavior?

Unfortunately at present if you are using the hot-reload dev server and you make an edit to the @Component decorator of your component you'll see a big error in the browser console, and you'll be forced to reload 😢. The error will look something like this:

Screenshot 2024-01-23 at 4 53 35 PM

Not such a nice time.

What is the new behavior?

Now if you make an edit to your @Component decorator you'll just see your component get updated in the browser with no errors.

Does this introduce a breaking change?

  • Yes
  • No

Testing

In order to test this I would recommend the following:

  • confirm that you can reproduce the issue
    • create a new project with
      cd /tmp && \
      npm init stencil@latest component hmr-issue && \
      cd hmr-issue && \
      npm install
    • then confirm that if you start the dev server (npm start) and edit a property in @Component you see an error in the console like above
  • then confirm the fix
    • build and pack this branch:
      cd /tmp && \
      git clone [email protected]:ionic-team/stencil.git && \
      cd /tmp/stencil && \
      git checkout ap/allow-component-decorator-hmr && \
      npm install && \
      npm run install.jest && \
      npm run build && \
      npm pack
    • install into the sample project:
      cd /tmp/hmr-issue && \
      npm i ../stencil/stencil-core-4.11.0.tgz
    • then, as above, start the dev server (npm start) and confirm that editing the @Component decorator doesn't cause catastrophic issues anymore

This fixes an issue where HMR updates which changed arguments to the
`@Component` decorator would crash the application because a `HostRef`
for the component could not be located.

This occurred because HMR updates caused a new version of the
component's lazy bundle to be fetched, which in turn would bundle the
`getHostRef` function and the corresponding `hostRefs` variable, which
is declared here:

https://github.com/ionic-team/stencil/blob/0041dc27b9deb45cfd1434a3d82d563793e56056/src/client/client-host-ref.ts#L18

Because the newly fetched lazy entry point for the updated component did
not have access to the `hostRefs` variable which was in-scope in the
_old_ bundle, the `getHostRef` function would always return `undefined`,
on the first render after the HMR update, causing issues in functions
like `setValue` which make use of a `HostRef`.

In order to fix the issue we can persist the `hostRefs` map across HMR
updates by storing a reference to it on the `window` object. We can
additionally constrain this persistence to only occur when we're
building with HMR, so that we don't clutter up the `window` object of
unsuspecting Stencil users in the context of a production build.

STENCIL-973
@alicewriteswrongs alicewriteswrongs force-pushed the ap/allow-component-decorator-hmr branch from 9ba51b0 to 2ead573 Compare January 23, 2024 22:10
Copy link
Contributor

--strictNullChecks error report

Typechecking with --strictNullChecks resulted in 1209 errors on this branch.

That's the same number of errors on main, so at least we're not creating new ones!

reports and statistics

Our most error-prone files
Path Error Count
src/dev-server/index.ts 37
src/mock-doc/serialize-node.ts 36
src/dev-server/server-process.ts 32
src/compiler/prerender/prerender-main.ts 22
src/testing/puppeteer/puppeteer-element.ts 22
src/runtime/client-hydrate.ts 20
src/screenshot/connector-base.ts 19
src/runtime/vdom/vdom-render.ts 17
src/compiler/config/test/validate-paths.spec.ts 16
src/dev-server/request-handler.ts 15
src/compiler/prerender/prerender-optimize.ts 14
src/compiler/sys/stencil-sys.ts 14
src/compiler/transpile/transpile-module.ts 14
src/sys/node/node-sys.ts 14
src/compiler/prerender/prerender-queue.ts 13
src/compiler/sys/in-memory-fs.ts 13
src/runtime/connected-callback.ts 13
src/runtime/set-value.ts 13
src/compiler/output-targets/output-www.ts 12
src/compiler/transformers/test/parse-vdom.spec.ts 12
Our most common errors
Typescript Error Code Count
TS2345 366
TS2322 362
TS18048 224
TS18047 99
TS2722 37
TS2532 26
TS2531 23
TS2454 14
TS2352 12
TS2790 11
TS2769 8
TS2538 8
TS2344 6
TS2416 6
TS2493 3
TS18046 2
TS2684 1
TS2430 1

Unused exports report

There are 14 unused exports on this PR. That's the same number of errors on main, so at least we're not creating new ones!

Unused exports
File Line Identifier
src/runtime/bootstrap-lazy.ts 21 setNonce
src/screenshot/screenshot-fs.ts 18 readScreenshotData
src/testing/testing-utils.ts 198 withSilentWarn
src/utils/index.ts 145 CUSTOM
src/utils/index.ts 269 normalize
src/utils/index.ts 7 escapeRegExpSpecialCharacters
src/compiler/app-core/app-data.ts 25 BUILD
src/compiler/app-core/app-data.ts 115 Env
src/compiler/app-core/app-data.ts 117 NAMESPACE
src/compiler/fs-watch/fs-watch-rebuild.ts 123 updateCacheFromRebuild
src/compiler/types/validate-primary-package-output-target.ts 61 satisfies
src/compiler/types/validate-primary-package-output-target.ts 61 Record
src/testing/puppeteer/puppeteer-declarations.ts 485 WaitForEventOptions
src/compiler/sys/fetch/write-fetch-success.ts 7 writeFetchSuccessSync

Copy link
Member

@christian-bromann christian-bromann left a comment

Choose a reason for hiding this comment

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

I can successfully reproduce the fix. The only nit I have is the any cast of the window object. I am not sure how types are set up, if it requires to many changes we can keep as is.

👍

Copy link
Contributor

@rwaskiewicz rwaskiewicz left a comment

Choose a reason for hiding this comment

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

LGTM! Found another related bug when I was testing this, but I think it's outside of the scope of what we're looking to do here. Captured details in STENCIL-1113

@alicewriteswrongs alicewriteswrongs added this pull request to the merge queue Jan 24, 2024
Merged via the queue into main with commit 656355f Jan 24, 2024
120 checks passed
@alicewriteswrongs alicewriteswrongs deleted the ap/allow-component-decorator-hmr branch January 24, 2024 14:54
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.

3 participants