Nested #each loops in handlebars do not render in Safari in iOS 8. Cause white screen of death and nothing renders. Returns error in console: TypeError: Attempted to assign to readonly property.

Tried with Ember 1.7.0 and 1.8 beta

Example: http://emberjs.jsbin.com/vecuz/1/

This is a copy over of #2757 with a few modifications. I've added feature flagging and layering to expose the ability to override how the document.title is created.

To enable this feature set the flag "ember-document-title" to true.

A typical example for an application would be the following:

App = Ember.Application.create();

App.Router = Ember.Router.extend({
  titleDivider: ': ',
  titleSpecificityIncreases: true
});

App.Router.map(function () {
  this.resource('users');
  this.resource('user', { path: '/users/:user_id' });
});

App.ApplicationRoute = Ember.Route.extend({
  title: "MyApp"
});

App.UsersRoute.extend({
  title: "Users"
});

App.UserRoute.extend({
  title: Ember.computed.oneWay('controller.name')
});

This structure will update the title of the document to MyApp when the app loads; MyApp: Users after transitioning to /users; and MyApp: Finn the Human upon loading the user for Finn the Human.

If you would like to override how the title property is displayed, simply override the title property on App.Router. When the title property becomes invalidated, the document title updates. That is the only contract you must satisfy. To get the tokens that the title is composed of, look at the titleTokens property. If overriding the title, you should make the title dependent on title tokens.

Side question: The tests are passing, but the observers aren't getting removed. This needs a patch in tildeio/router in setupContexts to call willTransition to ensure that observers are getting torn down. I'm not sure, but are the observers getting removed upon transitioning away from a route, or do I have to remove them myself?

Glimmer is the next-generation rendering engine for Ember.js. Built on top of HTMLBars, streams, and an entirely rewritten view layer, Glimmer offers the best performance of any of the major JavaScript frameworks while remaining backwards compatible with Ember 1.x apps.

The Virtual DOM showed the world that render-time diffing delivers awesome performance by minimizing DOM updates and keeping unchanged elements stable. But like any abstraction, it comes with a cost. In this case, constructing the virtual DOM to compare requires at least some subset of components do a full re-render, and building virtual DOM nodes for static areas of your markup that will never change for every change requires many more allocations and increases GC pressure.

Glimmer analyzes templates at compile time, relying on the fact that Handlebars' declarative syntax clearly differentiates between static areas, which make up the majority of a template, and the dynamic areas that can change. Instead of invoking a render() method and diffing the result, Glimmer only walks the (much smaller) existing dynamic tree.

Handlebars' declarative syntax means that from the perspective of an app, the template is being "re-rendered every time", but we can take advantage of static knowledge to reduce the work that we need to do. User code, like helpers and computed properties, are executed during the walk, but only to get (primitive) values which can be === compared, not to build up a new tree. In other words, the programming model is equivalent to "render every time", but we take advantage of the declarative nature of Ember's APIs to reduce work.

Internally, instead of creating a virtual DOM, Glimmer builds a tree of streams, each stream pointing to a node in the DOM. On initial render, we track the last value (always a primitive) that we inserted into the DOM. The streams are not exposed to application code; Glimmer executes user code when necessary and pushes the new value into the stream.

When re-rendering, we walk the tree and flush the streams. If the primitive value produced by the stream has not changed, we do nothing. If it has changed, we write the change to the DOM. Like Virtual DOM approaches, this is a "write-only" algorithm.

One of the benefits of this approach is that we can naturally fuse the Ember/Polymer model of observing individual properties with the React model of explicitly re-rendering areas of the template. No matter what happens, the process of revalidation walks the tree, looking for dirty nodes, and revalidates any dirty nodes it finds.

The only difference is how much of dynamic tree is marked dirty before revalidation begins. Also, because observation can only dirty dynamic nodes (and schedule a top-down revalidation), multiple observers and re-renders that occur during a single run-loop still only produce a single batch of DOM updates.

In essence, the biggest difference between Glimmer and traditional virtual DOM approaches is that we diff values, not DOM. This approach not only lets us avoid the algorithmic complexity of tree diffing (instead, we just === check two values), it also lets us avoid doing many render-time allocations.

Slides from the talk at EmberConf

Work List

(this looks like more things than it actually is)

• [x] merge subscription change into our branch
• [x] linkRenderNode can mark stability
• [x] Ember should return true from linkRenderNode
• [x] make sure all child streams correctly disconnect from parents
• [x] add stream pruning logic that correctly prunes ancestors
• [x] add scope teardown hook to HTMLBars (recursive upon clear or remove)
  • [ ] this is also responsible for view layer teardown
• [x] Propagate correct visitor through descendent hooks (so dirty checks can be avoided for a subtree)
• [x] Do not dirty check render nodes that were just created (fixes regression)
• [x] Add "classify" hook to decide which hook content et al should delegate to
• [x] Make sure that #view is idempotent
• [x] Components and views should create a new scope frame
  • [x] Implement custom scope in Ember (so that ambient view, controller, etc. can be stored)
  • [x] Eliminate *component* hacks
• [x] Lifecycle hooks on the renderer
• [x] Move code duplicated between #view, #component and Ember.View into the Renderer
• [ ] Support reflecting attributes onto angle-bracket components
• [ ] Pass mutable bindings as "mutator" objects
• [ ] Support foo={{action "bar"}}
• [ ] Legacy support: Implement unknownProperty/setUnknownProperty to work with mutator objects
  • [ ] Deprecate setting non-mut attributes, and support (mut foo) sexprs in legacy Handlebars syntax
• [ ] Investigate executing teardown callbacks at a "quiescent" state ("vent plasma")
  • [ ] Make sure to consider the rpflo stress test situation
• [x] Implement a zip and map abstraction for streams to clean up ad hoc stream creation
• [ ] Add tests for memory leaks
• [ ] Make sure that custom render functions that mutate the buffer continue to work
• [ ] options.template should not exist if there is no template
• [ ] feature flag all the things
• [ ] Handlebars helper compat
• [ ] Template function that returns a string (legacy)
• [X] Context shifting #each
• [ ] collection helper
• [ ] {{input}}
  • [X] TextField
  • [X] Checkbox
  • [ ] TextArea
• [ ] Ember.Select
• [ ] unbound
  • [X] non-block form
  • [ ] block form (partially done, but not completely)
• [X] #view and view helper
• [ ] #view and view helper with back-compat edge cases
• [X] #with helper
• [ ] with helper with back-compat edge-cases
• [ ] yield without a block
• [ ] {{render}}
• [ ] ContainerView
• [X] Top-level view APIs
  • [X] createElement
  • [X] appendTo
  • [X] replaceIn
  • [ ] destroyElement
• [ ] isVisible

This error only occurs after the app has been active and running for a while, giving the user a chance to navigate between several different routes. It's very hard to reproduce, it seems to "just happen" after a while. We've been able to reproduce it a few times using our production build (ember.min.js), but never using a debug build (ember.debug.js).

Here is the stack:

 "Cannot read property '_lookupFactory' of undefined"

TypeError: Cannot read property '_lookupFactory' of undefined
    at i (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:7:2712)
    at o (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:7:2833)
    at Object.a [as default] (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:7:2888)
    at Object.i [as subexpr] (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:6:4717)
    at a (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16476)
    at i (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16302)
    at n (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16189)
    at Object.r [as acceptHash] (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:16075)
    at n (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:26102)
    at Object.a.inline (https://qa-integration.batterii.com/assets/vendor-69da94618271be1c4338db3f0e942865.js:15:26664)

That seems to point back to the lookup-helper. The few times I've been lucky enough to catch this at a breakpoint, I've observed that the minified owner parameter becomes undefined. The rest of the env looks correct. See:

I know that's very little to go on. Short of coming up with an easy way to reproduce this, is there any additional information about the stack that might helpful in debugging this?

Adding an observer on a nested property of objects within a collection does not reliably fire. I've created a test case that could be added to ember-runtime/tests/mixins/array_test.js that illustrates this. Observing a nested property on the EachProxy itself appears to work fine. However, observing the property using @each.nest.isDone does not.

In the following test, count1 is incremented to 1, count2 is not:

test('modifying nested contents of an object in an array should call @each observers', function() {
  var ary = new TestArray([
      Em.Object.create({ nest: Em.Object.create({ isDone: false}) }),
      Em.Object.create({ nest: Em.Object.create({ isDone: false}) }),
      Em.Object.create({ nest: Em.Object.create({ isDone: false}) }),
      Em.Object.create({ nest: Em.Object.create({ isDone: false}) })
    ]);

  var get = Ember.get, set = Ember.set;
  var count1 = 0, count2 = 0;

  // Works
  var each = get(ary, '@each');
  Ember.addObserver(each, 'nest.isDone', function() { count1++; });

  // Doesn't work
  Ember.addObserver(ary, '@each.nest.isDone', function() { count2++; });

  count1 = count2 = 0;
  var item = ary.objectAt(2);
  get(item, 'nest').set('isDone', true);

  equal(count1, 1, '@each.nest.isDone should have notified - observing @each array');
  equal(count2, 1, '@each.nest.isDone should have notified - observing chain containing @each');
});

This PR contains the same API as #755 but has a simper implementation. Ember.RadioButton can also be used independently of Ember.RadioButtonGroup.

Also introduces Ember.Control which is a view that uses itself as its context, necessary for the Ember.RadioButtonGroup implementation.

Every computed property based on something using @each has broken with the 2.1.0 upgrade. Here are two examples:

  titleUniqueInCollection: Ember.computed('[email protected]', function() {
    const sections = this.get('collection.sections');
    const sectionsWithSameTitle = sections.filterBy('title', this.get('title'));
    return sectionsWithSameTitle.length === 1;
  }),

  sortedCollectionItems: Ember.computed('collectionItems', '[email protected]', function() {
    return this.get('collectionItems').sortBy('rankPosition');
  }),

The functions are no longer running as expected when an attribute is changed. Edited to reflect @stefanpenner's comment.

See here for some examples: https://gist.github.com/machty/8167051

Depends on Handlebars subexpressions: https://github.com/wycats/handlebars.js/pull/690

The performance of the initial component render times seems to be significantly slower in Ember 1.13 than in Ember 1.12.

Ember 1.13: http://emberjs.jsbin.com/zijuye

Ember 1.12: http://emberjs.jsbin.com/layoso

Ember 1.11: http://emberjs.jsbin.com/kunaco

Ember 1.10: http://emberjs.jsbin.com/xivavi

Backtracking re-render refers to a scenario where, in the middle of the rendering process, you have modified something that has already been rendered.

For example:

{{foo}} {{foo-bar parent=this}}

// app/components/foo-bar.js

export default Ember.Component.extend({
  init() {
    this._super(...arguments);
    this.get('parent').set('foo', 'bar');
  }  
});

As you can see, by the time the foo-bar component is instantiated and rendered, we have already used the value foo from the parent context to populate the {{foo}} curly. However, in its constructor, it was trying to modify the same value, hence. "backtracking".

This is a pretty extreme example, but it illustrates the problem. Besides init, didInitAttrs, didReceiveAttrs, willInsertElement and willRender also happens synchronously during the rendering process. Additionally, backtracking is often an issue arising from the behavior of two-way bound properties.

This behavior has always been unreliable, but was partially supported with a deprecation (since Ember 1.13):

You modified ApplicationController.foo twice in a single render. This was unreliable in Ember 1.x and will be removed in Ember 3.0

Since 1.13, Ember supported this by immediately doing a second re-render when backtracking was detected (and then repeating until the system stabilizes). This strategy itself could be a source of performance problems. In extreme cases, this could cause an infinite loop.

In Glimmer 2, while the extra re-render is relatively cheap, the extra book-keeping to detect a backtracking set is not. One of the wins of the Glimmer 2 system is that it does not need to eagerly setup observers to track changes. Further, certain optimizations in Glimmer 2 allows the system to skip traversing subtrees when it knows nothing within it has changed.

Together, these factors mean that we can not readily detect these backtracking sets (or whether something was "already rendered" or not) without doing a large amount of extra book-keeping and intentionally defeating these optimizations.

We already wrote the code to support this, but due to the already unreliable nature of the feature, and the (very significant) book-keeping costs, we are hesitant to automatically enable them for everyone without knowing whether it is still needed.

As a compromise, we currently only perform the detection in development mode and turned the deprecation message into a development-mode assertion (hard error). In production mode, the detection code is stripped and backtracking will not work.

We have kept the facility to support this feature (without the assertion) in the codebase behind a second feature flag. The code is being tested continuously on CI, however, is disabled by default until we have enough usage information to determine next steps.

If you believe you have usage patterns that are affected by this, please provide as much detail about your scenario as possible below. It is very possible that there can be alternatives and/or targeted solutions we can use that do not require a wholesale change to the engine. Therefore, it would be helpful if you provide background information and context about your usage instead of just showing us small code snippets from your codebase.

http://emberjs.jsbin.com/hedunosumi/edit?html,js,console,output

Might be a duplicate of https://github.com/emberjs/ember.js/issues/11504

has https://github.com/emberjs/ember.js/pull/11525 landed in 1.13.2 yet?

I'm attempting to implement the long-ago RFC'd deprecation of the internal @ember/string package in place of the published addon @ember/string.

This issue is to summarize what I find:

There was an aborted attempt to deprecate import { htmlSafe, isHTMLSafe } from '@ember/string' (with the new import being import { htmlSafe, isHTMLSafe } from@ember/template`).

Current status, on a newly generated app on 4.9.3:

import { htmlSafe } from `@ember/string`;
htmlSafe('foo'); // errors (0, _string.htmlSafe) is not a function

import { htmlSafe } from `@ember/template`;
htmlSafe('foo'); // success

On a newly generated app on 4.9.3, with ember-data removed:

import { htmlSafe } from `@ember/string`;
htmlSafe('foo') // success

import { htmlSafe } from `@ember/template`;
htmlSafe('foo'); // success

If the addon @ember/string is included, it clobbers the internal @ember/string. To solve this, htmlSafe and isHTMLSafe should be added to the addon @ember/string with deprecations pointing to the imports from @ember/template. I have confirmed that the deprecations, when added back to the internal @ember/string, do not trigger when using the @ember/template imports (this was the original issue that led to the deprecation being backed out).

The htmlSafe/isHTMLSafe import from @ember/template was added in 3.8.

Todo

• [x] Add htmlSafe and isHTMLSafe to the addon @ember/string with errors pointing to the imports from @ember/template. https://github.com/emberjs/ember-string/pull/367
• [x] https://github.com/emberjs/ember.js/pull/20341
• [ ] Ember.String.htmlSafe (and all other methods) are still available on Ember when doing import Ember from 'ember'. Deprecate accessing String on the global import.
• [ ] Deprecate the methods on internal @ember/string, tell users to add addon https://github.com/emberjs/ember.js/pull/20344
• [ ] Ember.STRINGS????

Bumps @typescript-eslint/eslint-plugin from 5.38.0 to 5.47.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps puppeteer from 13.5.1 to 19.4.1.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.

Bumps semver from 7.3.7 to 7.3.8.

Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting @dependabot rebase.