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

[Glimmer 2] Master Issue #13949

Closed
chancancode opened this issue Jul 29, 2016 · 3 comments
Closed

[Glimmer 2] Master Issue #13949

chancancode opened this issue Jul 29, 2016 · 3 comments

Comments

@chancancode
Copy link
Member

chancancode commented Jul 29, 2016

Glimmer 2

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.sets 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 and ember-cli-htmlbars-inline-precompile. The issue has been fixed in ember-cli-htmlbars 1.0.10 and ember-cli-htmlbars 0.3.3.

    To ensure you are getting the right versions, you can update your package.json to require these versions:

    {
       ...,
    
       "devDependencies": {
           "ember-cli-htmlbars": "^1.0.10",
           "ember-cli-htmlbars-inline-precompile": "^0.3.3",
           ...
       },
    
       ...
    }
  • General caching related issues

    In some cases, you might have to remove your node_modules directory after changing the ember version (followed by an npm install).

  • Incorrect production builds

    Production (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 builds

    Alpha builds before 2c20658 incorrectly included "tslint" test modules, which led to bloated file size and increased parse time. This is now fixed.

  • Incorrect version numbers

    Alpha builds before f247628 had incorrect version numbers like 2.9.0-canary+SHA (as opposed to 2.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.

  • [Glimmer 2] Removal of "always dirty" re-rendering #13946: Re-rendering a component manually (i.e. calling this.rerender()) no longer forces everything in its subtree to recompute. Notably, helpers like {{unbound}} are not updated when re-rendering.
  • [Glimmer 2] Difference in willRender semantics #13947: The willRender lifecycle hook will be called on a component whenever anything in its subtree has changed.
  • [Glimmer 2] "Backtracking re-render" is now an assertion #13948: "Backtracking re-render" is now an error in development mode, and will not work in production builds.
  • {{#each-in}} updates automatically when values are added to the object using Ember.set.
  • "Tagless" components (components with tagName set to an empty string) used to ignore any id attribute, which unintentionally allowed users to repurpose it for their own uses. This is now a hard error ("You cannot use elementId 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.

Known 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)

Engines

✅ Working

Liquid Fire

⚠️ Waiting for Liquid Fire release

  • Liquid Fire currently does not work with 2.8+ due to its private API dependencies

Ember Inspector

⚠️ Working with some limitations

Performance 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.

@chancancode chancancode added this to the Glimmer2-Beta milestone Jul 29, 2016
@emberjs emberjs locked and limited conversation to collaborators Jul 29, 2016
@emberjs emberjs unlocked this conversation Jul 30, 2016
@chancancode
Copy link
Member Author

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! 🎉

@Cryrivers
Copy link

addons dependent on ember-htmlbars/streams/stream or ember-views/streams/stream are not working at the moment as well. (e.g: liquid-fire and ember-i18n)

@snuggs
Copy link

snuggs commented Aug 29, 2016

Bravo @chancancode !!! Well done!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants