-
-
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
[Glimmer 2] Master Issue #13949
Comments
Sorry that I locked the issue earlier! The intent is that it is generally a better idea to open new issues instead of having a long thread of disconnected issues, especially since there are no "sub-threads" in the Github UI. However, if there are things that you think really belongs here, I have unlocked it so you can add them at your digression. We may also periodically delete outdated comments to keep this thread current. Happy alpha testing! 🎉 |
addons dependent on |
Bravo @chancancode !!! Well done! |
Hello!
Welcome to Glimmer 2 alpha testing! Having worked on this for almost a year now, we are very excited to have you on board to help us smooth out the rough edges!
This issue will be updated as we discover new problems. If you experienced issues when testing the alpha builds, please check if it's already covered by one of the issues linked from here. Having all the relevant information in one place will help everyone – those fixing the problems as well as those who are experiencing them.
Background
Glimmer 2 is a ground-up rewrite with an architecture that departs significantly from Glimmer 1. For example, the old system eagerly registered observers on everything to get notified when things change, whereas Glimmer 2 is a "pull-based" system that does not rely on observers at all for tracking changes (it intercepts
Ember.set
s instead).While we are very careful to not break the public APIs (and known "intimate" APIs used by popular addons), there might be other emergent, incidental and undocumented behaviors in the old system that are simply a fallout of the old implementation details. To the extent that it is possible to support them (without incurring a big cost for everyone else), we will try to address these issues as we discover them.
However, please understand that it is not always easy or possible to fully emulate the subtle differences. Sometimes there really are no equivalent concepts in the new codebase (not in the sense that something is missing – but in the sense that the approaches are completely different).
Therefore, we need to decide what to do with these edge-cases on a case-by-case basis, and it would really help if you provide as much details as possible (what is it that you are trying to accomplish, what made you chose this path, do you know of any officially supported alternatives/workarounds, and if so how easy/difficult would it be to migrate to a supported path).
Current Status
In the last few months, we went through a large-scale effort to modernize our rendering test suite. This significantly improved the coverage, but more importantly, it allowed the same tests to be run on both the new and the existing rendering engines.
With a few minor exceptions, everything is passing now, and continuously being tested on CI on every push.
Separately, the rest of the test suite is also passing (and continuously tested on CI) with a few exceptions. The reason they are failing is that these tests incidentally coupled to the old engine. We are working on rewriting these tests and will re-enable them as soon as possible.
While Ember's core semantics are covered by the test suite and are believed to be mostly working with the new engine, certain addons might be depending on internal APIs or incidental behaviors. As a result not all addons might be working at this moment. One of the goals of the alpha testing period is to get addon authors identify and report such compatibilities so we can work on addressing them as soon as possible.
Installation/Build Issues
"@mut is not a helper"
This is an issue with
ember-cli-htmlbars
andember-cli-htmlbars-inline-precompile
. The issue has been fixed inember-cli-htmlbars
1.0.10 andember-cli-htmlbars
0.3.3.To ensure you are getting the right versions, you can update your
package.json
to require these versions:General caching related issues
In some cases, you might have to remove your
node_modules
directory after changing the ember version (followed by annpm install
).Incorrect production buildsProduction (
ember.prod.js
) and minified (ember.min.js
) alpha builds before 3a7b78a incorrectly included development-mode assertions and other debugging aids, which led to bloated file sizes, increased parse time and significant runtime performance penalty. This is now fixed.tslint
test modules included in buildsAlpha builds before 2c20658 incorrectly included "tslint" test modules, which led to bloated file size and increased parse time. This is now fixed.
Incorrect version numbersAlpha builds before f247628 had incorrect version numbers like
2.9.0-canary+SHA
(as opposed to2.9.0-alpha+SHA
). This is now fixed.Notable Changes
These changes are the natural fallout of some internal implementation changes. It is believed that the previous behaviors are incidental, undocumented, inconsistent or otherwise unreliable. If you believe this is breaking your app, please provide more details in the linked issues.
this.rerender()
) no longer forces everything in its subtree to recompute. Notably, helpers like{{unbound}}
are not updated when re-rendering.willRender
semantics #13947: ThewillRender
lifecycle hook will be called on a component whenever anything in its subtree has changed.{{#each-in}}
updates automatically when values are added to the object usingEmber.set
."Tagless" components (components withtagName
set to an empty string) used to ignore anyid
attribute, which unintentionally allowed users to repurpose it for their own uses. This is now a hard error ("You cannot useelementId
on a tag-less component").Missing Features
These features will be added before shipping. If your app depends on them, it will not work at the moment. However, we still intend to support them fully. You do not need to make any code changes at this moment.
[Glimmer2] Instrumentation #13910: Instrumentation Support: the new engine is not emitting instrumentation events[Glimmer2] Action instrumentation #13905: Actions instrumentation (part of theember-improved-instrumentation
feature flag) are also missingKnown Issues
These issues will be fixed before shipping. If your app depends on them, it might behave strangely in some edge-cases. However, we still intend to support them fully. You do not need to make any code changes at this moment.
- #13908:readDOMAttr
currently has a stubbed implementation [:lock: @wycats]Addons/Tooling
This is not meant to be an exhaustively list. In general, incompatibilities should be reported to the addon authors directly, but here are the status of a few notable addons. If you are an addon author and you have experienced issues not enumerated above, please open a new issue to describe your needs.
Testing
Current status:
✅ Acceptance Tests: Working
✅ Non-component integration or unit tests: Working
✅ Component integration tests: Working (history in #13963)
✅ Component unit tests: Working
Fastboot
✅ Working (ember-cli-fastboot 1.0.0-beta.9)
[Glimmer 2] Make Node Tests Pass #13930: Ember's Node tests need to passEngines
✅ Working
[Glimmer2] Implement {{mount}} #13903: Ember needs to implement the{{mount}}
helperLiquid Fire
Liquid Fire currently does not work with 2.8+ due to its private API dependenciesEmber Inspector
[Glimmer 2] Ember Inspector #13929: Ember needs to implement thegetViewClientRects
andgetViewBoundingClientRect
APIsPerformance Issues
While one of the overarching goals of Glimmer 2 is to improve performance, the immediate priority is maximal compatibility. However, if you noticed certain common patterns have become slower, please report them as bugs during the alpha period.
As always – when running performance benchmarks, please make sure you are using the minified production build (
ember.min.js
). The debug builds contain a lot of helpful development aids that are known to impact performance negatively.Re-rendering: general slow-down on big pages (validator issues) Should be fixed in [GLIMMER2] Remove remainingCURRENT_TAG
s #14012.when there is a proxy (e.g. alink-to
re-render performance regressionPromiseProxy
) in the yielded content. Fixed in [GLIMMER2] Remove remainingCURRENT_TAG
s #14012 and UsedidReceiveAttrs
(instead ofwillRender
) in{{link-to}}
#14035.The text was updated successfully, but these errors were encountered: