-
-
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
Upgrade to Glimmer VM 0.37.0 #17244
Upgrade to Glimmer VM 0.37.0 #17244
Conversation
40efdef
to
bc7dbcf
Compare
@tomdale looks like one of the node tests is failing |
@@ -655,7 +655,7 @@ const Component = CoreView.extend( | |||
*/ | |||
readDOMAttr(name: string) { | |||
// TODO revisit this |
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.
assuming this comment is related to the previous type inference below(as HTMLElement
), seems it can be removed now
There were some issues in CI (BrowserStack Edge 18 failures) that will be resolved with a rebase. |
The only API change in this version of the VM relates to TypeScript types for the DOM. Type signatures now use SimpleDOM types throughout, helping ensure code doesn’t inadvertently rely on DOM APIs that are not available in SSR mode. The other change has to do with what happens when an exception is thrown during render. Currently, Glimmer has a limited capacity to recover the state of the VM when errors are thrown from an opcode. A quick-and-dirty fix has been applied to Ember to try to catch and recover from these states, but options are limited until the root issue is addressed in Glimmer VM. This commit changes a previously passing test to be skipped. This is because the old test covered behavior that only worked in some limited scenarios, because it left the DOM in a bad state. This could lead to cases where the same DOM element would be rendered multiple times, or in the wrong location. Glimmer VM 0.37.0 does more rigorous type checking and now fails when a re-render is attempted and the DOM is left in a bad state. After a discussion between myself, @chancancode, @krisselden and @wycats, we felt that it was okay to temporarily mark this test as skipped since the behavior it captures was not working consistently anyway. We plan to address this more robustly in the VM itself, at which time we can re-enable the test, and remove some of the more ad hoc error recovery semantics from Ember itself.
bc7dbcf
to
4fe99df
Compare
Looks like the CI failure is legit, though I'm not 100% sure what the right fix is. It seems related to the simple dom changes:
You can easily run these tests via:
|
I believe the Node tests were failing because I forgot to upgrade SimpleDOM. We switched the SSR implementation from using a non-standard SimpleDOM API to using the standard Unfortunately, older versions of SimpleDOM don't expose this method. This means that FastBoot will need to update SimpleDOM as well, and newer versions of Ember won't be compatible with older versions of FastBoot. SimpleDOM is backwards-compatible, so we can update SimpleDOM in FastBoot now and it will continue working with previous versions as well as with Glimmer VM 0.37+. We should be able to do this in a point release, so people would get it even with conservative upgrades. Not sure if we want to detect an incompatible FastBoot/SimpleDOM version in Ember and warn about it. Architecturally, Ember doesn't "know" about FastBoot, but maybe we should make an exception here to avoid developer frustration. |
I'm comfortable landing this now, and adding messaging for |
The only API change in this version of the VM relates to TypeScript types for the DOM. Type signatures now use SimpleDOM types throughout, helping ensure code doesn’t inadvertently rely on DOM APIs that are not available in SSR mode.
The other change has to do with what happens when an exception is thrown during render. Currently, Glimmer has a limited capacity to recover the state of the VM when errors are thrown from an opcode. A quick-and-dirty fix has been applied to Ember to try to catch and recover from these states, but options are limited until the root issue is addressed in Glimmer VM.
This commit changes a previously passing test to be skipped. This is because the old test covered behavior that only worked in some limited scenarios, because it left the DOM in a bad state. This could lead to cases where the same DOM element would be rendered multiple times, or in the wrong location. Glimmer VM 0.37.0 does more rigorous type checking and now fails when a re-render is attempted and the DOM is left in a bad state.
After a discussion between myself, @chancancode, @krisselden and @wycats, we felt that it was okay to temporarily mark this test as skipped since the behavior it captures was not working consistently anyway. We plan to address this more robustly in the VM itself, at which time we can re-enable the test, and remove some of the more ad hoc error recovery semantics from Ember itself.