npm - ember-source - Versions diffs - 4.0.0-beta.7 → 4.0.0-beta.8 - Mend

ember-source 4.0.0-beta.7 → 4.0.0-beta.8

This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.

Files changed (28) hide show

package/docs/data.json CHANGED Viewed

@@ -3,7 +3,7 @@
     "name": "The Ember API",
     "description": "The Ember API: a framework for building ambitious web applications",
     "url": "https://emberjs.com/",
-    "version": "4.0.0-beta.7"
+    "version": "4.0.0-beta.8"
   },
   "files": {
     "node_modules/rsvp/lib/rsvp/promise/all.js": {
@@ -2501,7 +2501,7 @@
       "namespace": "",
       "file": "packages/@ember/-internals/glimmer/lib/components/checkbox.ts",
       "line": 13,
-      "description": "The internal class used to create text inputs when the `{{input}}`\nhelper is used with `type` of `checkbox`.\n\nSee [Ember.Templates.helpers.input](/ember/release/classes/Ember.Templates.helpers/methods/input?anchor=input)  for usage details.\n\n## Direct manipulation of `checked`\n\nThe `checked` attribute of an `Checkbox` object should always be set\nthrough the Ember object or by interacting with its rendered element\nrepresentation via the mouse, keyboard, or touch. Updating the value of the\ncheckbox via jQuery will result in the checked value of the object and its\nelement losing synchronization.\n\n## Layout and LayoutName properties\n\nBecause HTML `input` elements are self closing `layout` and `layoutName`\nproperties will not be applied.",
+      "description": "The internal class used to create text inputs when the `{{input}}`\nhelper is used with `type` of `checkbox`.\n\nSee [Ember.Templates.helpers.input](/ember/release/classes/Ember.Templates.helpers/methods/input?anchor=input)  for usage details.\n\n## Direct manipulation of `checked`\n\nThe `checked` attribute of an `Checkbox` object should always be set\nthrough the Ember object or by interacting with its rendered element\nrepresentation via the mouse, keyboard, or touch. Updating the value of the\ncheckbox programmatically will result in the checked value of the object and its\nelement losing synchronization.\n\n## Layout and LayoutName properties\n\nBecause HTML `input` elements are self closing `layout` and `layoutName`\nproperties will not be applied.",
       "extends": "Component",
       "access": "public",
       "tagname": ""
@@ -3585,7 +3585,7 @@
       "namespace": "",
       "file": "packages/@ember/application/lib/application.js",
       "line": 30,
-      "description": "An instance of `Application` is the starting point for every Ember\napplication. It instantiates, initializes and coordinates the\nobjects that make up your app.\n\nEach Ember app has one and only one `Application` object. Although\nEmber CLI creates this object implicitly, the `Application` class\nis defined in the `app/app.js`. You can define a `ready` method on the\n`Application` class, which will be run by Ember when the application is\ninitialized.\n\n```app/app.js\nconst App = Application.extend({\n  ready() {\n    // your code here\n  }\n})\n```\n\nBecause `Application` ultimately inherits from `Ember.Namespace`, any classes\nyou create will have useful string representations when calling `toString()`.\nSee the `Ember.Namespace` documentation for more information.\n\nWhile you can think of your `Application` as a container that holds the\nother classes in your application, there are several other responsibilities\ngoing on under-the-hood that you may want to understand. It is also important\nto understand that an `Application` is different from an `ApplicationInstance`.\nRefer to the Guides to understand the difference between these.\n\n### Event Delegation\n\nEmber uses a technique called _event delegation_. This allows the framework\nto set up a global, shared event listener instead of requiring each view to\ndo it manually. For example, instead of each view registering its own\n`mousedown` listener on its associated element, Ember sets up a `mousedown`\nlistener on the `body`.\n\nIf a `mousedown` event occurs, Ember will look at the target of the event and\nstart walking up the DOM node tree, finding corresponding views and invoking\ntheir `mouseDown` method as it goes.\n\n`Application` has a number of default events that it listens for, as\nwell as a mapping from lowercase events to camel-cased view method names. For\nexample, the `keypress` event causes the `keyPress` method on the view to be\ncalled, the `dblclick` event causes `doubleClick` to be called, and so on.\n\nIf there is a bubbling browser event that Ember does not listen for by\ndefault, you can specify custom events and their corresponding view method\nnames by setting the application's `customEvents` property:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  customEvents: {\n    // add support for the paste event\n    paste: 'paste'\n  }\n});\n```\n\nTo prevent Ember from setting up a listener for a default event,\nspecify the event name with a `null` value in the `customEvents`\nproperty:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  customEvents: {\n    // prevent listeners for mouseenter/mouseleave events\n    mouseenter: null,\n    mouseleave: null\n  }\n});\n```\n\nBy default, the application sets up these event listeners on the document\nbody. However, in cases where you are embedding an Ember application inside\nan existing page, you may want it to set up the listeners on an element\ninside the body.\n\nFor example, if only events inside a DOM element with the ID of `ember-app`\nshould be delegated, set your application's `rootElement` property:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  rootElement: '#ember-app'\n});\n```\n\nThe `rootElement` can be either a DOM element or a jQuery-compatible selector\nstring. Note that *views appended to the DOM outside the root element will\nnot receive events.* If you specify a custom root element, make sure you only\nappend views inside it!\n\nTo learn more about the events Ember components use, see\n\n[components/handling-events](https://guides.emberjs.com/release/components/handling-events/#toc_event-names).\n\n### Initializers\n\nTo add behavior to the Application's boot process, you can define initializers in\nthe `app/initializers` directory, or with `ember generate initializer` using Ember CLI.\nThese files should export a named `initialize` function which will receive the created `application`\nobject as its first argument.\n\n```javascript\nexport function initialize(application) {\n  // application.inject('route', 'foo', 'service:foo');\n}\n```\n\nApplication initializers can be used for a variety of reasons including:\n\n- setting up external libraries\n- injecting dependencies\n- setting up event listeners in embedded apps\n- deferring the boot process using the `deferReadiness` and `advanceReadiness` APIs.\n\n### Routing\n\nIn addition to creating your application's router, `Application` is\nalso responsible for telling the router when to start routing. Transitions\nbetween routes can be logged with the `LOG_TRANSITIONS` flag, and more\ndetailed intra-transition logging can be logged with\nthe `LOG_TRANSITIONS_INTERNAL` flag:\n\n```javascript\nimport Application from '@ember/application';\n\nlet App = Application.create({\n  LOG_TRANSITIONS: true, // basic logging of successful transitions\n  LOG_TRANSITIONS_INTERNAL: true // detailed logging of all routing steps\n});\n```\n\nBy default, the router will begin trying to translate the current URL into\napplication state once the browser emits the `DOMContentReady` event. If you\nneed to defer routing, you can call the application's `deferReadiness()`\nmethod. Once routing can begin, call the `advanceReadiness()` method.\n\nIf there is any setup required before routing begins, you can implement a\n`ready()` method on your app that will be invoked immediately before routing\nbegins.",
+      "description": "An instance of `Application` is the starting point for every Ember\napplication. It instantiates, initializes and coordinates the\nobjects that make up your app.\n\nEach Ember app has one and only one `Application` object. Although\nEmber CLI creates this object implicitly, the `Application` class\nis defined in the `app/app.js`. You can define a `ready` method on the\n`Application` class, which will be run by Ember when the application is\ninitialized.\n\n```app/app.js\nconst App = Application.extend({\n  ready() {\n    // your code here\n  }\n})\n```\n\nBecause `Application` ultimately inherits from `Ember.Namespace`, any classes\nyou create will have useful string representations when calling `toString()`.\nSee the `Ember.Namespace` documentation for more information.\n\nWhile you can think of your `Application` as a container that holds the\nother classes in your application, there are several other responsibilities\ngoing on under-the-hood that you may want to understand. It is also important\nto understand that an `Application` is different from an `ApplicationInstance`.\nRefer to the Guides to understand the difference between these.\n\n### Event Delegation\n\nEmber uses a technique called _event delegation_. This allows the framework\nto set up a global, shared event listener instead of requiring each view to\ndo it manually. For example, instead of each view registering its own\n`mousedown` listener on its associated element, Ember sets up a `mousedown`\nlistener on the `body`.\n\nIf a `mousedown` event occurs, Ember will look at the target of the event and\nstart walking up the DOM node tree, finding corresponding views and invoking\ntheir `mouseDown` method as it goes.\n\n`Application` has a number of default events that it listens for, as\nwell as a mapping from lowercase events to camel-cased view method names. For\nexample, the `keypress` event causes the `keyPress` method on the view to be\ncalled, the `dblclick` event causes `doubleClick` to be called, and so on.\n\nIf there is a bubbling browser event that Ember does not listen for by\ndefault, you can specify custom events and their corresponding view method\nnames by setting the application's `customEvents` property:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  customEvents: {\n    // add support for the paste event\n    paste: 'paste'\n  }\n});\n```\n\nTo prevent Ember from setting up a listener for a default event,\nspecify the event name with a `null` value in the `customEvents`\nproperty:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  customEvents: {\n    // prevent listeners for mouseenter/mouseleave events\n    mouseenter: null,\n    mouseleave: null\n  }\n});\n```\n\nBy default, the application sets up these event listeners on the document\nbody. However, in cases where you are embedding an Ember application inside\nan existing page, you may want it to set up the listeners on an element\ninside the body.\n\nFor example, if only events inside a DOM element with the ID of `ember-app`\nshould be delegated, set your application's `rootElement` property:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  rootElement: '#ember-app'\n});\n```\n\nThe `rootElement` can be either a DOM element or a CSS selector\nstring. Note that *views appended to the DOM outside the root element will\nnot receive events.* If you specify a custom root element, make sure you only\nappend views inside it!\n\nTo learn more about the events Ember components use, see\n\n[components/handling-events](https://guides.emberjs.com/release/components/handling-events/#toc_event-names).\n\n### Initializers\n\nTo add behavior to the Application's boot process, you can define initializers in\nthe `app/initializers` directory, or with `ember generate initializer` using Ember CLI.\nThese files should export a named `initialize` function which will receive the created `application`\nobject as its first argument.\n\n```javascript\nexport function initialize(application) {\n  // application.inject('route', 'foo', 'service:foo');\n}\n```\n\nApplication initializers can be used for a variety of reasons including:\n\n- setting up external libraries\n- injecting dependencies\n- setting up event listeners in embedded apps\n- deferring the boot process using the `deferReadiness` and `advanceReadiness` APIs.\n\n### Routing\n\nIn addition to creating your application's router, `Application` is\nalso responsible for telling the router when to start routing. Transitions\nbetween routes can be logged with the `LOG_TRANSITIONS` flag, and more\ndetailed intra-transition logging can be logged with\nthe `LOG_TRANSITIONS_INTERNAL` flag:\n\n```javascript\nimport Application from '@ember/application';\n\nlet App = Application.create({\n  LOG_TRANSITIONS: true, // basic logging of successful transitions\n  LOG_TRANSITIONS_INTERNAL: true // detailed logging of all routing steps\n});\n```\n\nBy default, the router will begin trying to translate the current URL into\napplication state once the browser emits the `DOMContentReady` event. If you\nneed to defer routing, you can call the application's `deferReadiness()`\nmethod. Once routing can begin, call the `advanceReadiness()` method.\n\nIf there is any setup required before routing begins, you can implement a\n`ready()` method on your app that will be invoked immediately before routing\nbegins.",
       "extends": "Engine",
       "uses": [
         "RegistryProxyMixin"
@@ -6953,29 +6953,6 @@
     {
       "file": "packages/@ember/-internals/glimmer/lib/component.ts",
       "line": 1003,
-      "description": "Returns a jQuery object for this component's element. If you pass in a selector\nstring, this method will return a jQuery object, using the current element\nas its buffer.\n\nFor example, calling `component.$('li')` will return a jQuery object containing\nall of the `li` elements inside the DOM element of this component.\n\nPlease note that jQuery integration is off by default and this feature will\nnot work properly. To enable this feature, you can read the instructions in\nthe [jquery-integration optional feature guide](https://guides.emberjs.com/release/configuring-ember/optional-features/#toc_jquery-integration).",
-      "itemtype": "method",
-      "name": "$",
-      "params": [
-        {
-          "name": "selector",
-          "description": "a jQuery-compatible selector string",
-          "type": "String",
-          "optional": true
-        }
-      ],
-      "return": {
-        "description": "the jQuery object for the DOM node",
-        "type": "JQuery"
-      },
-      "access": "public",
-      "tagname": "",
-      "class": "Component",
-      "module": "@ember/component"
-    },
-    {
-      "file": "packages/@ember/-internals/glimmer/lib/component.ts",
-      "line": 1020,
       "description": "The HTML `id` of the component's element in the DOM. You can provide this\nvalue yourself but it must be unique (just as in HTML):\n\n```handlebars\n{{my-component elementId=\"a-really-cool-id\"}}\n```\n\n```handlebars\n<MyComponent @elementId=\"a-really-cool-id\" />\n```\nIf not manually set a default value will be provided by the framework.\nOnce rendered an element's `elementId` is considered immutable and you\nshould never change it. If you need to compute a dynamic value for the\n`elementId`, you should do this when the component or element is being\ninstantiated:\n\n```javascript\nexport default Component.extend({\n  init() {\n    this._super(...arguments);\n\n    var index = this.get('index');\n    this.set('elementId', `component-id${index}`);\n  }\n});\n```",
       "itemtype": "property",
       "name": "elementId",
@@ -8123,8 +8100,8 @@
       "access": "private",
       "tagname": "Marks a property as tracked.\n\nBy default, a component's properties are expected to be static,\nmeaning you are not able to update them and have the template update accordingly.\nMarking a property as tracked means that when that property changes,\na rerender of the component is scheduled so the template is kept up to date.\n\nThere are two usages for the `@tracked` decorator, shown below.",
       "example": [
-        " No dependencies\n\nIf you don't pass an argument to `@tracked`, only changes to that property\nwill be tracked:\n\n```typescript\nimport Component, { tracked } from '@glimmer/component';\n\nexport default class MyComponent extends Component {\n  @tracked\n  remainingApples = 10\n}\n```\n\nWhen something changes the component's `remainingApples` property, the rerender\nwill be scheduled.",
-        " Dependents\n\nIn the case that you have a computed property that depends other\nproperties, you want to track both so that when one of the\ndependents change, a rerender is scheduled.\n\nIn the following example we have two properties,\n`eatenApples`, and `remainingApples`.\n\n```typescript\nimport Component, { tracked } from '@glimmer/component';\n\nconst totalApples = 100;\n\nexport default class MyComponent extends Component {\n  @tracked\n  eatenApples = 0\n\n  @tracked('eatenApples')\n  get remainingApples() {\n    return totalApples - this.eatenApples;\n  }\n\n  increment() {\n    this.eatenApples = this.eatenApples + 1;\n  }\n}\n```"
+        " No dependencies\n\nIf you don't pass an argument to `@tracked`, only changes to that property\nwill be tracked:\n\n```typescript\nimport Component from '@glimmer/component';\nimport { tracked } from '@glimmer/tracking';\n\nexport default class MyComponent extends Component {\n  @tracked\n  remainingApples = 10\n}\n```\n\nWhen something changes the component's `remainingApples` property, the rerender\nwill be scheduled.",
+        " Dependents\n\nIn the case that you have a computed property that depends other\nproperties, you want to track both so that when one of the\ndependents change, a rerender is scheduled.\n\nIn the following example we have two properties,\n`eatenApples`, and `remainingApples`.\n\n```typescript\nimport Component from '@glimmer/component';\nimport { tracked } from '@glimmer/tracking';\n\nconst totalApples = 100;\n\nexport default class MyComponent extends Component {\n  @tracked\n  eatenApples = 0\n\n  @tracked('eatenApples')\n  get remainingApples() {\n    return totalApples - this.eatenApples;\n  }\n\n  increment() {\n    this.eatenApples = this.eatenApples + 1;\n  }\n}\n```"
       ],
       "params": [
         {
@@ -14213,7 +14190,6 @@
     {
       "file": "packages/@ember/-internals/utils/lib/guid.ts",
       "line": 8,
-      "description": "Previously we used `Ember.$.uuid`, however `$.uuid` has been removed from\njQuery master. We'll just bootstrap our own uuid now.",
       "access": "private",
       "tagname": "",
       "return": {
@@ -14225,7 +14201,7 @@
     },
     {
       "file": "packages/@ember/-internals/utils/lib/guid.ts",
-      "line": 17,
+      "line": 14,
       "description": "Generates a universally unique identifier. This method\nis used internally by Ember for assisting with\nthe generation of GUID's and other unique identifiers.",
       "access": "public",
       "tagname": "",
@@ -14238,7 +14214,7 @@
     },
     {
       "file": "packages/@ember/-internals/utils/lib/guid.ts",
-      "line": 29,
+      "line": 26,
       "description": "Prefix used for guids through out Ember.",
       "access": "private",
       "tagname": "",
@@ -14251,7 +14227,7 @@
     },
     {
       "file": "packages/@ember/-internals/utils/lib/guid.ts",
-      "line": 42,
+      "line": 39,
       "description": "A unique key used to assign guids and other private metadata to objects.\nIf you inspect an object in your browser debugger you will often see these.\nThey can be safely ignored.\n\nOn browsers that support it, these properties are added with enumeration\ndisabled so they won't show up when you iterate over your properties.",
       "access": "private",
       "tagname": "",
@@ -14264,7 +14240,7 @@
     },
     {
       "file": "packages/@ember/-internals/utils/lib/guid.ts",
-      "line": 58,
+      "line": 55,
       "description": "Generates a new guid, optionally saving the guid to the object that you\npass in. You will rarely need to use this method. Instead you should\ncall `guidFor(obj)`, which return an existing guid if available.",
       "access": "private",
       "tagname": "",
@@ -14294,7 +14270,7 @@
     },
     {
       "file": "packages/@ember/-internals/utils/lib/guid.ts",
-      "line": 86,
+      "line": 83,
       "description": "Returns a unique id for the object. If the object does not yet have a guid,\none will be assigned to it. You can call this on any object,\n`EmberObject`-based or not.\n\nYou can also use this method on DOM Element objects.",
       "access": "public",
       "tagname": "",
@@ -14719,8 +14695,8 @@
       "params": [
         {
           "name": "A",
-          "description": "selector, element, HTML string, or jQuery object",
-          "type": "String|DOMElement|jQuery"
+          "description": "selector, element, HTML string",
+          "type": "String|DOMElement"
         }
       ],
       "return": {
@@ -14839,7 +14815,7 @@
     {
       "file": "packages/@ember/-internals/views/lib/mixins/view_support.js",
       "line": 346,
-      "description": "Tag name for the view's outer element. The tag name is only used when an\nelement is first created. If you change the `tagName` for an element, you\nmust destroy and recreate the view element.\n\nBy default, the render buffer will use a `<div>` tag for views.\n\nIf the tagName is `''`, the view will be tagless, with no outer element.\nComponent properties that depend on the presence of an outer element, such\nas `classNameBindings` and `attributeBindings`, do not work with tagless\ncomponents. Tagless components cannot implement methods to handle events,\nand have no associated jQuery object to return with `$()`.",
+      "description": "Tag name for the view's outer element. The tag name is only used when an\nelement is first created. If you change the `tagName` for an element, you\nmust destroy and recreate the view element.\n\nBy default, the render buffer will use a `<div>` tag for views.\n\nIf the tagName is `''`, the view will be tagless, with no outer element.\nComponent properties that depend on the presence of an outer element, such\nas `classNameBindings` and `attributeBindings`, do not work with tagless\ncomponents. Tagless components cannot implement methods to handle events,\nand their `element` property has a `null` value.",
       "itemtype": "property",
       "name": "tagName",
       "type": "String",
@@ -15203,7 +15179,7 @@
     {
       "file": "packages/@ember/application/lib/application.js",
       "line": 185,
-      "description": "The root DOM element of the Application. This can be specified as an\nelement or a\n[jQuery-compatible selector string](http://api.jquery.com/category/selectors/).\n\nThis is the element that will be passed to the Application's,\n`eventDispatcher`, which sets up the listeners for event delegation. Every\nview in your application should be a child of the element you specify here.",
+      "description": "The root DOM element of the Application. This can be specified as an\nelement or a [selector string](https://developer.mozilla.org/en-US/docs/Learn/CSS/Building_blocks/Selectors#reference_table_of_selectors).\n\nThis is the element that will be passed to the Application's,\n`eventDispatcher`, which sets up the listeners for event delegation. Every\nview in your application should be a child of the element you specify here.",
       "itemtype": "property",
       "name": "rootElement",
       "type": "DOMElement",
@@ -15215,7 +15191,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 201,
+      "line": 200,
       "itemtype": "property",
       "name": "_document",
       "type": "Document | null",
@@ -15227,7 +15203,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 210,
+      "line": 209,
       "description": "The `Ember.EventDispatcher` responsible for delegating events to this\napplication's views.\n\nThe event dispatcher is created by the application at initialization time\nand sets up event listeners on the DOM element described by the\napplication's `rootElement` property.\n\nSee the documentation for `Ember.EventDispatcher` for more information.",
       "itemtype": "property",
       "name": "eventDispatcher",
@@ -15240,7 +15216,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 227,
+      "line": 226,
       "description": "The DOM events for which the event dispatcher should listen.\n\nBy default, the application's `Ember.EventDispatcher` listens\nfor a set of standard DOM events, such as `mousedown` and\n`keyup`, and delegates them to your application's `Ember.View`\ninstances.\n\nIf you would like additional bubbling events to be delegated to your\nviews, set your `Application`'s `customEvents` property\nto a hash containing the DOM event name as the key and the\ncorresponding view method name as the value. Setting an event to\na value of `null` will prevent a default event listener from being\nadded for that event.\n\nTo add new events to be listened to:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  customEvents: {\n    // add support for the paste event\n    paste: 'paste'\n  }\n});\n```\n\nTo prevent default events from being listened to:\n\n```app/app.js\nimport Application from '@ember/application';\n\nlet App = Application.extend({\n  customEvents: {\n    // remove support for mouseenter / mouseleave events\n    mouseenter: null,\n    mouseleave: null\n  }\n});\n```",
       "itemtype": "property",
       "name": "customEvents",
@@ -15253,7 +15229,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 275,
+      "line": 274,
       "description": "Whether the application should automatically start routing and render\ntemplates to the `rootElement` on DOM ready. While default by true,\nother environments such as FastBoot or a testing harness can set this\nproperty to `false` and control the precise timing and behavior of the boot\nprocess.",
       "itemtype": "property",
       "name": "autoboot",
@@ -15266,7 +15242,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 289,
+      "line": 288,
       "description": "Whether the application should be configured for the legacy \"globals mode\".\nUnder this mode, the Application object serves as a global namespace for all\nclasses.\n\n```javascript\nimport Application from '@ember/application';\nimport Component from '@ember/component';\n\nlet App = Application.create({\n  ...\n});\n\nApp.Router.reopen({\n  location: 'none'\n});\n\nApp.Router.map({\n  ...\n});\n\nApp.MyComponent = Component.extend({\n  ...\n});\n```\n\nThis flag also exposes other internal APIs that assumes the existence of\na special \"default instance\", like `App.__container__.lookup(...)`.\n\nThis option is currently not configurable, its value is derived from\nthe `autoboot` flag – disabling `autoboot` also implies opting-out of\nglobals mode support, although they are ultimately orthogonal concerns.\n\nSome of the global modes features are already deprecated in 1.x. The\nexistence of this flag is to untangle the globals mode code paths from\nthe autoboot code paths, so that these legacy features can be reviewed\nfor deprecation/removal separately.\n\nForcing the (autoboot=true, _globalsMode=false) here and running the tests\nwould reveal all the places where we are still relying on these legacy\nbehavior internally (mostly just tests).",
       "itemtype": "property",
       "name": "_globalsMode",
@@ -15279,7 +15255,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 338,
+      "line": 337,
       "description": "An array of application instances created by `buildInstance()`. Used\ninternally to ensure that all instances get destroyed.",
       "itemtype": "property",
       "name": "_applicationInstances",
@@ -15292,7 +15268,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 378,
+      "line": 377,
       "description": "Create an ApplicationInstance for this application.",
       "access": "public",
       "tagname": "",
@@ -15307,7 +15283,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 401,
+      "line": 400,
       "description": "Start tracking an ApplicationInstance for this application.\nUsed when the ApplicationInstance is created.",
       "access": "private",
       "tagname": "",
@@ -15318,7 +15294,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 412,
+      "line": 411,
       "description": "Stop tracking an ApplicationInstance for this application.\nUsed when the ApplicationInstance is about to be destroyed.",
       "access": "private",
       "tagname": "",
@@ -15329,7 +15305,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 423,
+      "line": 422,
       "description": "Enable the legacy globals mode by allowing this application to act\nas a global namespace. See the docs on the `_globalsMode` property\nfor details.\n\nMost of these features are already deprecated in 1.x, so we can\nstop using them internally and try to remove them.",
       "access": "private",
       "tagname": "",
@@ -15340,7 +15316,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 467,
+      "line": 466,
       "description": "Automatically kick-off the boot process for the application once the\nDOM has become ready.\n\nThe initialization itself is scheduled on the actions queue which\nensures that code-loading finishes before booting.\n\nIf you are asynchronously loading code, you should call `deferReadiness()`\nto defer booting, and then call `advanceReadiness()` once all of your code\nhas finished loading.",
       "access": "private",
       "tagname": "",
@@ -15351,7 +15327,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 494,
+      "line": 493,
       "description": "This is the autoboot flow:\n\n1. Boot the app by calling `this.boot()`\n2. Create an instance (or use the `__deprecatedInstance__` in globals mode)\n3. Boot the instance by calling `instance.boot()`\n4. Invoke the `App.ready()` callback\n5. Kick-off routing on the instance\n\nIdeally, this is all we would need to do:\n\n```javascript\n_autoBoot() {\n  this.boot().then(() => {\n    let instance = (this._globalsMode) ? this.__deprecatedInstance__ : this.buildInstance();\n    return instance.boot();\n  }).then((instance) => {\n    App.ready();\n    instance.startRouting();\n  });\n}\n```\n\nUnfortunately, we cannot actually write this because we need to participate\nin the \"synchronous\" boot process. While the code above would work fine on\nthe initial boot (i.e. DOM ready), when `App.reset()` is called, we need to\nboot a new instance synchronously (see the documentation on `_bootSync()`\nfor details).\n\nBecause of this restriction, the actual logic of this method is located\ninside `didBecomeReady()`.",
       "access": "private",
       "tagname": "",
@@ -15362,8 +15338,8 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 539,
-      "description": "Use this to defer readiness until some condition is true.\n\nExample:\n\n```javascript\nimport Application from '@ember/application';\n\nlet App = Application.create();\n\nApp.deferReadiness();\n\n// $ is a reference to the jQuery object/function\nimport $ from 'jquery;\n\n$.getJSON('/auth-token', function(token) {\n  App.token = token;\n  App.advanceReadiness();\n});\n```\n\nThis allows you to perform asynchronous setup logic and defer\nbooting your application until the setup has finished.\n\nHowever, if the setup requires a loading UI, it might be better\nto use the router for this purpose.",
+      "line": 538,
+      "description": "Use this to defer readiness until some condition is true.\n\nExample:\n\n```javascript\nimport Application from '@ember/application';\n\nlet App = Application.create();\n\nApp.deferReadiness();\n\nfetch('/auth-token')\n.then(response => response.json())\n.then(data => {\n  App.token = data.token;\n  App.advanceReadiness();\n});\n```\n\nThis allows you to perform asynchronous setup logic and defer\nbooting your application until the setup has finished.\n\nHowever, if the setup requires a loading UI, it might be better\nto use the router for this purpose.",
       "itemtype": "method",
       "name": "deferReadiness",
       "access": "public",
@@ -15373,7 +15349,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 590,
+      "line": 588,
       "description": "Call `advanceReadiness` after any asynchronous setup logic has completed.\nEach call to `deferReadiness` must be matched by a call to `advanceReadiness`\nor the application will never become ready and routing will not begin.",
       "itemtype": "method",
       "name": "advanceReadiness",
@@ -15387,7 +15363,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 627,
+      "line": 625,
       "description": "Initialize the application and return a promise that resolves with the `Application`\nobject when the boot process is complete.\n\nRun any application initializers and run the application load hook. These hooks may\nchoose to defer readiness. For example, an authentication hook might want to defer\nreadiness until the auth token has been retrieved.\n\nBy default, this method is called automatically on \"DOM ready\"; however, if autoboot\nis disabled, this is automatically called when the first application instance is\ncreated via `visit`.",
       "access": "public",
       "tagname": "",
@@ -15402,7 +15378,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 665,
+      "line": 663,
       "description": "Unfortunately, a lot of existing code assumes the booting process is\n\"synchronous\". Specifically, a lot of tests assumes the last call to\n`app.advanceReadiness()` or `app.reset()` will result in the app being\nfully-booted when the current runloop completes.\n\nWe would like new code (like the `visit` API) to stop making this assumption,\nso we created the asynchronous version above that returns a promise. But until\nwe have migrated all the code, we would have to expose this method for use\n*internally* in places where we need to boot an app \"synchronously\".",
       "access": "private",
       "tagname": "",
@@ -15411,7 +15387,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 704,
+      "line": 702,
       "description": "Reset the application. This is typically used only in tests. It cleans up\nthe application in the following order:\n\n1. Deactivate existing routes\n2. Destroy all objects in the container\n3. Create a new application container\n4. Re-route to the existing url\n\nTypical Example:\n\n```javascript\nimport Application from '@ember/application';\nlet App;\n\nrun(function() {\n  App = Application.create();\n});\n\nmodule('acceptance test', {\n  setup: function() {\n    App.reset();\n  }\n});\n\ntest('first test', function() {\n  // App is freshly reset\n});\n\ntest('second test', function() {\n  // App is again freshly reset\n});\n```\n\nAdvanced Example:\n\nOccasionally you may want to prevent the app from initializing during\nsetup. This could enable extra configuration, or enable asserting prior\nto the app becoming ready.\n\n```javascript\nimport Application from '@ember/application';\nlet App;\n\nrun(function() {\n  App = Application.create();\n});\n\nmodule('acceptance test', {\n  setup: function() {\n    run(function() {\n      App.reset();\n      App.deferReadiness();\n    });\n  }\n});\n\ntest('first test', function() {\n  ok(true, 'something before app is initialized');\n\n  run(function() {\n    App.advanceReadiness();\n  });\n\n  ok(true, 'something after app is initialized');\n});\n```",
       "itemtype": "method",
       "name": "reset",
@@ -15422,7 +15398,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 807,
+      "line": 805,
       "access": "private",
       "tagname": "",
       "itemtype": "method",
@@ -15432,7 +15408,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 857,
+      "line": 855,
       "description": "Called when the Application has become ready, immediately before routing\nbegins. The call will be delayed until the DOM has become ready.",
       "itemtype": "event",
       "name": "ready",
@@ -15443,8 +15419,8 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 882,
-      "description": "Boot a new instance of `ApplicationInstance` for the current\napplication and navigate it to the given `url`. Returns a `Promise` that\nresolves with the instance when the initial routing and rendering is\ncomplete, or rejects with any error that occurred during the boot process.\n\nWhen `autoboot` is disabled, calling `visit` would first cause the\napplication to boot, which runs the application initializers.\n\nThis method also takes a hash of boot-time configuration options for\ncustomizing the instance's behavior. See the documentation on\n`ApplicationInstance.BootOptions` for details.\n\n`ApplicationInstance.BootOptions` is an interface class that exists\npurely to document the available options; you do not need to construct it\nmanually. Simply pass a regular JavaScript object containing of the\ndesired options:\n\n```javascript\nMyApp.visit(\"/\", { location: \"none\", rootElement: \"#container\" });\n```\n\n### Supported Scenarios\n\nWhile the `BootOptions` class exposes a large number of knobs, not all\ncombinations of them are valid; certain incompatible combinations might\nresult in unexpected behavior.\n\nFor example, booting the instance in the full browser environment\nwhile specifying a foreign `document` object (e.g. `{ isBrowser: true,\ndocument: iframe.contentDocument }`) does not work correctly today,\nlargely due to Ember's jQuery dependency.\n\nCurrently, there are three officially supported scenarios/configurations.\nUsages outside of these scenarios are not guaranteed to work, but please\nfeel free to file bug reports documenting your experience and any issues\nyou encountered to help expand support.\n\n#### Browser Applications (Manual Boot)\n\nThe setup is largely similar to how Ember works out-of-the-box. Normally,\nEmber will boot a default instance for your Application on \"DOM ready\".\nHowever, you can customize this behavior by disabling `autoboot`.\n\nFor example, this allows you to render a miniture demo of your application\ninto a specific area on your marketing website:\n\n```javascript\nimport MyApp from 'my-app';\n\n$(function() {\n  let App = MyApp.create({ autoboot: false });\n\n  let options = {\n    // Override the router's location adapter to prevent it from updating\n    // the URL in the address bar\n    location: 'none',\n\n    // Override the default `rootElement` on the app to render into a\n    // specific `div` on the page\n    rootElement: '#demo'\n  };\n\n  // Start the app at the special demo URL\n  App.visit('/demo', options);\n});\n```\n\nOr perhaps you might want to boot two instances of your app on the same\npage for a split-screen multiplayer experience:\n\n```javascript\nimport MyApp from 'my-app';\n\n$(function() {\n  let App = MyApp.create({ autoboot: false });\n\n  let sessionId = MyApp.generateSessionID();\n\n  let player1 = App.visit(`/matches/join?name=Player+1&session=${sessionId}`, { rootElement: '#left', location: 'none' });\n  let player2 = App.visit(`/matches/join?name=Player+2&session=${sessionId}`, { rootElement: '#right', location: 'none' });\n\n  Promise.all([player1, player2]).then(() => {\n    // Both apps have completed the initial render\n    $('#loading').fadeOut();\n  });\n});\n```\n\nDo note that each app instance maintains their own registry/container, so\nthey will run in complete isolation by default.\n\n#### Server-Side Rendering (also known as FastBoot)\n\nThis setup allows you to run your Ember app in a server environment using\nNode.js and render its content into static HTML for SEO purposes.\n\n```javascript\nconst HTMLSerializer = new SimpleDOM.HTMLSerializer(SimpleDOM.voidMap);\n\nfunction renderURL(url) {\n  let dom = new SimpleDOM.Document();\n  let rootElement = dom.body;\n  let options = { isBrowser: false, document: dom, rootElement: rootElement };\n\n  return MyApp.visit(options).then(instance => {\n    try {\n      return HTMLSerializer.serialize(rootElement.firstChild);\n    } finally {\n      instance.destroy();\n    }\n  });\n}\n```\n\nIn this scenario, because Ember does not have access to a global `document`\nobject in the Node.js environment, you must provide one explicitly. In practice,\nin the non-browser environment, the stand-in `document` object only needs to\nimplement a limited subset of the full DOM API. The `SimpleDOM` library is known\nto work.\n\nSince there is no access to jQuery in the non-browser environment, you must also\nspecify a DOM `Element` object in the same `document` for the `rootElement` option\n(as opposed to a selector string like `\"body\"`).\n\nSee the documentation on the `isBrowser`, `document` and `rootElement` properties\non `ApplicationInstance.BootOptions` for details.\n\n#### Server-Side Resource Discovery\n\nThis setup allows you to run the routing layer of your Ember app in a server\nenvironment using Node.js and completely disable rendering. This allows you\nto simulate and discover the resources (i.e. AJAX requests) needed to fulfill\na given request and eagerly \"push\" these resources to the client.\n\n```app/initializers/network-service.js\nimport BrowserNetworkService from 'app/services/network/browser';\nimport NodeNetworkService from 'app/services/network/node';\n\n// Inject a (hypothetical) service for abstracting all AJAX calls and use\n// the appropriate implementation on the client/server. This also allows the\n// server to log all the AJAX calls made during a particular request and use\n// that for resource-discovery purpose.\n\nexport function initialize(application) {\n  if (window) { // browser\n    application.register('service:network', BrowserNetworkService);\n  } else { // node\n    application.register('service:network', NodeNetworkService);\n  }\n};\n\nexport default {\n  name: 'network-service',\n  initialize: initialize\n};\n```\n\n```app/routes/post.js\nimport Route from '@ember/routing/route';\nimport { inject as service } from '@ember/service';\n\n// An example of how the (hypothetical) service is used in routes.\n\nexport default class IndexRoute extends Route {\n  @service network;\n\n  model(params) {\n    return this.network.fetch(`/api/posts/${params.post_id}.json`);\n  }\n\n  afterModel(post) {\n    if (post.isExternalContent) {\n      return this.network.fetch(`/api/external/?url=${post.externalURL}`);\n    } else {\n      return post;\n    }\n  }\n}\n```\n\n```javascript\n// Finally, put all the pieces together\n\nfunction discoverResourcesFor(url) {\n  return MyApp.visit(url, { isBrowser: false, shouldRender: false }).then(instance => {\n    let networkService = instance.lookup('service:network');\n    return networkService.requests; // => { \"/api/posts/123.json\": \"...\" }\n  });\n}\n```",
+      "line": 880,
+      "description": "Boot a new instance of `ApplicationInstance` for the current\napplication and navigate it to the given `url`. Returns a `Promise` that\nresolves with the instance when the initial routing and rendering is\ncomplete, or rejects with any error that occurred during the boot process.\n\nWhen `autoboot` is disabled, calling `visit` would first cause the\napplication to boot, which runs the application initializers.\n\nThis method also takes a hash of boot-time configuration options for\ncustomizing the instance's behavior. See the documentation on\n`ApplicationInstance.BootOptions` for details.\n\n`ApplicationInstance.BootOptions` is an interface class that exists\npurely to document the available options; you do not need to construct it\nmanually. Simply pass a regular JavaScript object containing of the\ndesired options:\n\n```javascript\nMyApp.visit(\"/\", { location: \"none\", rootElement: \"#container\" });\n```\n\n### Supported Scenarios\n\nWhile the `BootOptions` class exposes a large number of knobs, not all\ncombinations of them are valid; certain incompatible combinations might\nresult in unexpected behavior.\n\nFor example, booting the instance in the full browser environment\nwhile specifying a foreign `document` object (e.g. `{ isBrowser: true,\ndocument: iframe.contentDocument }`) does not work correctly today,\nlargely due to Ember's jQuery dependency.\n\nCurrently, there are three officially supported scenarios/configurations.\nUsages outside of these scenarios are not guaranteed to work, but please\nfeel free to file bug reports documenting your experience and any issues\nyou encountered to help expand support.\n\n#### Browser Applications (Manual Boot)\n\nThe setup is largely similar to how Ember works out-of-the-box. Normally,\nEmber will boot a default instance for your Application on \"DOM ready\".\nHowever, you can customize this behavior by disabling `autoboot`.\n\nFor example, this allows you to render a miniture demo of your application\ninto a specific area on your marketing website:\n\n```javascript\nimport MyApp from 'my-app';\n\n$(function() {\n  let App = MyApp.create({ autoboot: false });\n\n  let options = {\n    // Override the router's location adapter to prevent it from updating\n    // the URL in the address bar\n    location: 'none',\n\n    // Override the default `rootElement` on the app to render into a\n    // specific `div` on the page\n    rootElement: '#demo'\n  };\n\n  // Start the app at the special demo URL\n  App.visit('/demo', options);\n});\n```\n\nOr perhaps you might want to boot two instances of your app on the same\npage for a split-screen multiplayer experience:\n\n```javascript\nimport MyApp from 'my-app';\n\n$(function() {\n  let App = MyApp.create({ autoboot: false });\n\n  let sessionId = MyApp.generateSessionID();\n\n  let player1 = App.visit(`/matches/join?name=Player+1&session=${sessionId}`, { rootElement: '#left', location: 'none' });\n  let player2 = App.visit(`/matches/join?name=Player+2&session=${sessionId}`, { rootElement: '#right', location: 'none' });\n\n  Promise.all([player1, player2]).then(() => {\n    // Both apps have completed the initial render\n    $('#loading').fadeOut();\n  });\n});\n```\n\nDo note that each app instance maintains their own registry/container, so\nthey will run in complete isolation by default.\n\n#### Server-Side Rendering (also known as FastBoot)\n\nThis setup allows you to run your Ember app in a server environment using\nNode.js and render its content into static HTML for SEO purposes.\n\n```javascript\nconst HTMLSerializer = new SimpleDOM.HTMLSerializer(SimpleDOM.voidMap);\n\nfunction renderURL(url) {\n  let dom = new SimpleDOM.Document();\n  let rootElement = dom.body;\n  let options = { isBrowser: false, document: dom, rootElement: rootElement };\n\n  return MyApp.visit(options).then(instance => {\n    try {\n      return HTMLSerializer.serialize(rootElement.firstChild);\n    } finally {\n      instance.destroy();\n    }\n  });\n}\n```\n\nIn this scenario, because Ember does not have access to a global `document`\nobject in the Node.js environment, you must provide one explicitly. In practice,\nin the non-browser environment, the stand-in `document` object only needs to\nimplement a limited subset of the full DOM API. The `SimpleDOM` library is known\nto work.\n\nSince there is no DOM access in the non-browser environment, you must also\nspecify a DOM `Element` object in the same `document` for the `rootElement` option\n(as opposed to a selector string like `\"body\"`).\n\nSee the documentation on the `isBrowser`, `document` and `rootElement` properties\non `ApplicationInstance.BootOptions` for details.\n\n#### Server-Side Resource Discovery\n\nThis setup allows you to run the routing layer of your Ember app in a server\nenvironment using Node.js and completely disable rendering. This allows you\nto simulate and discover the resources (i.e. AJAX requests) needed to fulfill\na given request and eagerly \"push\" these resources to the client.\n\n```app/initializers/network-service.js\nimport BrowserNetworkService from 'app/services/network/browser';\nimport NodeNetworkService from 'app/services/network/node';\n\n// Inject a (hypothetical) service for abstracting all AJAX calls and use\n// the appropriate implementation on the client/server. This also allows the\n// server to log all the AJAX calls made during a particular request and use\n// that for resource-discovery purpose.\n\nexport function initialize(application) {\n  if (window) { // browser\n    application.register('service:network', BrowserNetworkService);\n  } else { // node\n    application.register('service:network', NodeNetworkService);\n  }\n};\n\nexport default {\n  name: 'network-service',\n  initialize: initialize\n};\n```\n\n```app/routes/post.js\nimport Route from '@ember/routing/route';\nimport { inject as service } from '@ember/service';\n\n// An example of how the (hypothetical) service is used in routes.\n\nexport default class IndexRoute extends Route {\n  @service network;\n\n  model(params) {\n    return this.network.fetch(`/api/posts/${params.post_id}.json`);\n  }\n\n  afterModel(post) {\n    if (post.isExternalContent) {\n      return this.network.fetch(`/api/external/?url=${post.externalURL}`);\n    } else {\n      return post;\n    }\n  }\n}\n```\n\n```javascript\n// Finally, put all the pieces together\n\nfunction discoverResourcesFor(url) {\n  return MyApp.visit(url, { isBrowser: false, shouldRender: false }).then(instance => {\n    let networkService = instance.lookup('service:network');\n    return networkService.requests; // => { \"/api/posts/123.json\": \"...\" }\n  });\n}\n```",
       "access": "public",
       "tagname": "",
       "itemtype": "method",
@@ -15470,7 +15446,7 @@
     },
     {
       "file": "packages/@ember/application/lib/application.js",
-      "line": 1103,
+      "line": 1101,
       "description": "This creates a registry with the default Ember naming conventions.\n\nIt also configures the registry:\n\n* registered views are created every time they are looked up (they are\n  not singletons)\n* registered templates are not factories; the registered value is\n  returned directly.\n* the router receives the application as its `namespace` property\n* all controllers receive the router as their `target` and `controllers`\n  properties\n* all controllers receive the application as their `namespace` property\n* the application view receives the application controller as its\n  `controller` property\n* the application view receives the application template as its\n  `defaultTemplate` property",
       "itemtype": "method",
       "name": "buildRegistry",
@@ -16474,7 +16450,7 @@
     {
       "file": "packages/@ember/engine/index.js",
       "line": 305,
-      "description": "Instance initializers run after all initializers have run. Because\ninstance initializers run after the app is fully set up. We have access\nto the store, container, and other items. However, these initializers run\nafter code has loaded and are not allowed to defer readiness.\n\nInstance initializer receives an object which has the following attributes:\n`name`, `before`, `after`, `initialize`. The only required attribute is\n`initialize`, all others are optional.\n\n* `name` allows you to specify under which name the instanceInitializer is\nregistered. This must be a unique name, as trying to register two\ninstanceInitializer with the same name will result in an error.\n\n```app/initializer/named-instance-initializer.js\nimport { debug } from '@ember/debug';\n\nexport function initialize() {\n  debug('Running named-instance-initializer!');\n}\n\nexport default {\n  name: 'named-instance-initializer',\n  initialize\n};\n```\n\n* `before` and `after` are used to ensure that this initializer is ran prior\nor after the one identified by the value. This value can be a single string\nor an array of strings, referencing the `name` of other initializers.\n\n* See Application.initializer for discussion on the usage of before\nand after.\n\nExample instanceInitializer to preload data into the store.\n\n```app/initializer/preload-data.js\nimport $ from 'jquery';\n\nexport function initialize(application) {\n    var userConfig, userConfigEncoded, store;\n    // We have a HTML escaped JSON representation of the user's basic\n    // configuration generated server side and stored in the DOM of the main\n    // index.html file. This allows the app to have access to a set of data\n    // without making any additional remote calls. Good for basic data that is\n    // needed for immediate rendering of the page. Keep in mind, this data,\n    // like all local models and data can be manipulated by the user, so it\n    // should not be relied upon for security or authorization.\n\n    // Grab the encoded data from the meta tag\n    userConfigEncoded = $('head meta[name=app-user-config]').attr('content');\n\n    // Unescape the text, then parse the resulting JSON into a real object\n    userConfig = JSON.parse(unescape(userConfigEncoded));\n\n    // Lookup the store\n    store = application.lookup('service:store');\n\n    // Push the encoded JSON into the store\n    store.pushPayload(userConfig);\n}\n\nexport default {\n  name: 'named-instance-initializer',\n  initialize\n};\n```",
+      "description": "Instance initializers run after all initializers have run. Because\ninstance initializers run after the app is fully set up. We have access\nto the store, container, and other items. However, these initializers run\nafter code has loaded and are not allowed to defer readiness.\n\nInstance initializer receives an object which has the following attributes:\n`name`, `before`, `after`, `initialize`. The only required attribute is\n`initialize`, all others are optional.\n\n* `name` allows you to specify under which name the instanceInitializer is\nregistered. This must be a unique name, as trying to register two\ninstanceInitializer with the same name will result in an error.\n\n```app/initializer/named-instance-initializer.js\nimport { debug } from '@ember/debug';\n\nexport function initialize() {\n  debug('Running named-instance-initializer!');\n}\n\nexport default {\n  name: 'named-instance-initializer',\n  initialize\n};\n```\n\n* `before` and `after` are used to ensure that this initializer is ran prior\nor after the one identified by the value. This value can be a single string\nor an array of strings, referencing the `name` of other initializers.\n\n* See Application.initializer for discussion on the usage of before\nand after.\n\nExample instanceInitializer to preload data into the store.\n\n```app/initializer/preload-data.js\n\nexport function initialize(application) {\n    var userConfig, userConfigEncoded, store;\n    // We have a HTML escaped JSON representation of the user's basic\n    // configuration generated server side and stored in the DOM of the main\n    // index.html file. This allows the app to have access to a set of data\n    // without making any additional remote calls. Good for basic data that is\n    // needed for immediate rendering of the page. Keep in mind, this data,\n    // like all local models and data can be manipulated by the user, so it\n    // should not be relied upon for security or authorization.\n\n    // Grab the encoded data from the meta tag\n    userConfigEncoded = document.querySelector('head meta[name=app-user-config]').attr('content');\n\n    // Unescape the text, then parse the resulting JSON into a real object\n    userConfig = JSON.parse(unescape(userConfigEncoded));\n\n    // Lookup the store\n    store = application.lookup('service:store');\n\n    // Push the encoded JSON into the store\n    store.pushPayload(userConfig);\n}\n\nexport default {\n  name: 'named-instance-initializer',\n  initialize\n};\n```",
       "itemtype": "method",
       "name": "instanceInitializer",
       "params": [
@@ -16490,7 +16466,7 @@
     },
     {
       "file": "packages/@ember/engine/index.js",
-      "line": 379,
+      "line": 378,
       "description": "This creates a registry with the default Ember naming conventions.\n\nIt also configures the registry:\n\n* registered views are created every time they are looked up (they are\n  not singletons)\n* registered templates are not factories; the registered value is\n  returned directly.\n* the router receives the application as its `namespace` property\n* all controllers receive the router as their `target` and `controllers`\n  properties\n* all controllers receive the application as their `namespace` property\n* the application view receives the application controller as its\n  `controller` property\n* the application view receives the application template as its\n  `defaultTemplate` property",
       "itemtype": "method",
       "name": "buildRegistry",
@@ -16513,7 +16489,7 @@
     },
     {
       "file": "packages/@ember/engine/index.js",
-      "line": 419,
+      "line": 418,
       "description": "Set this to provide an alternate class to `DefaultResolver`",
       "itemtype": "property",
       "name": "resolver",
@@ -16524,7 +16500,7 @@
     },
     {
       "file": "packages/@ember/engine/index.js",
-      "line": 428,
+      "line": 427,
       "description": "This function defines the default lookup rules for container lookups:\n\n* templates are looked up on `Ember.TEMPLATES`\n* other names are looked up on the application after classifying the name.\n  For example, `controller:post` looks up `App.PostController` by default.\n* if the default lookup fails, look for registered classes on the container\n\nThis allows the application to register default injections in the container\nthat could be overridden by the normal naming convention.",
       "access": "private",
       "tagname": "",
@@ -19191,12 +19167,12 @@
       "line": " packages/@ember/-internals/runtime/types/observable.d.ts:67"
     },
     {
-      "message": "Missing item type\nPreviously we used `Ember.$.uuid`, however `$.uuid` has been removed from\njQuery master. We'll just bootstrap our own uuid now.",
+      "message": "Missing item type",
       "line": " packages/@ember/-internals/utils/lib/guid.ts:8"
     },
     {
       "message": "Missing item type\nGenerates a universally unique identifier. This method\nis used internally by Ember for assisting with\nthe generation of GUID's and other unique identifiers.",
-      "line": " packages/@ember/-internals/utils/lib/guid.ts:17"
+      "line": " packages/@ember/-internals/utils/lib/guid.ts:14"
     },
     {
       "message": "Missing item type\nStrongly hint runtimes to intern the provided string.\n\nWhen do I need to use this function?\n\nFor the most part, never. Pre-mature optimization is bad, and often the\nruntime does exactly what you need it to, and more often the trade-off isn't\nworth it.\n\nWhy?\n\nRuntimes store strings in at least 2 different representations:\nRopes and Symbols (interned strings). The Rope provides a memory efficient\ndata-structure for strings created from concatenation or some other string\nmanipulation like splitting.\n\nUnfortunately checking equality of different ropes can be quite costly as\nruntimes must resort to clever string comparison algorithms. These\nalgorithms typically cost in proportion to the length of the string.\nLuckily, this is where the Symbols (interned strings) shine. As Symbols are\nunique by their string content, equality checks can be done by pointer\ncomparison.\n\nHow do I know if my string is a rope or symbol?\n\nTypically (warning general sweeping statement, but truthy in runtimes at\npresent) static strings created as part of the JS source are interned.\nStrings often used for comparisons can be interned at runtime if some\ncriteria are met.  One of these criteria can be the size of the entire rope.\nFor example, in chrome 38 a rope longer then 12 characters will not\nintern, nor will segments of that rope.\n\nSome numbers: http://jsperf.com/eval-vs-keys/8\n\nKnown Trick™",
@@ -19204,7 +19180,7 @@
     },
     {
       "message": "Missing item type\nUnfortunately, a lot of existing code assumes the booting process is\n\"synchronous\". Specifically, a lot of tests assumes the last call to\n`app.advanceReadiness()` or `app.reset()` will result in the app being\nfully-booted when the current runloop completes.\n\nWe would like new code (like the `visit` API) to stop making this assumption,\nso we created the asynchronous version above that returns a promise. But until\nwe have migrated all the code, we would have to expose this method for use\n*internally* in places where we need to boot an app \"synchronously\".",
-      "line": " packages/@ember/application/lib/application.js:665"
+      "line": " packages/@ember/application/lib/application.js:663"
     },
     {
       "message": "Missing item type\nOverrides the base `EngineInstance._bootSync` method with concerns relevant\nto booting application (instead of engine) instances.\n\nThis method should only contain synchronous boot concerns. Asynchronous\nboot concerns should eventually be moved to the `boot` method, which\nreturns a promise.\n\nUntil all boot code has been made asynchronous, we need to continue to\nexpose this method for use *internally* in places where we need to boot an\ninstance synchronously.",

package/package.json CHANGED Viewed

@@ -1,6 +1,6 @@
 {
   "name": "ember-source",
-  "version": "4.0.0-beta.7",
+  "version": "4.0.0-beta.8",
   "description": "A JavaScript framework for creating ambitious web applications",
   "keywords": [
     "ember-addon"
@@ -156,7 +156,7 @@
   "ember-addon": {
     "after": "ember-cli-legacy-blueprints"
   },
-  "_originalVersion": "4.0.0-beta.7",
+  "_originalVersion": "4.0.0-beta.8",
   "_versionPreviouslyCalculated": true,
   "publishConfig": {
     "tag": "beta"