Merge branch 'master' into advance-rfc-0631

README.md

@@ -282,7 +282,8 @@ that RFC.
 
 RFCs in [Final Comment Periods](#final-comment-periods-fcp) are labeled with
 [Final Comment Period](https://github.com/emberjs/rfcs/pulls?q=is%3Apr+is%3Aopen+sort%3Aupdated-desc+label%3A%22Final+Comment+Period%22)
-and are announced on the [Ember twitter account](https://twitter.com/emberjs).
+and are announced in `#news-and-announcements` on [Ember Discord](https://discord.gg/emberjs) and
+on the [Ember twitter account](https://twitter.com/emberjs).
 
 [Quick links](#quick-links-for-pull-requests-for-proposed-and-advancing-rfcs)
 are provided at the top of the README to help you review what you are interested in.
@@ -450,9 +451,9 @@ further guidance.
 
 For certain stage advancements, a _final comment period_ (FCP) is required. This
 is a period lasting 7 days. The beginning of this period will be signaled with a
-comment and tag on the RFC's pull request. Furthermore,
-[Ember's official Twitter account](https://twitter.com/emberjs) will post a
-tweet about the RFC to attract the community's attention.
+comment and tag on the RFC's pull request. Furthermore, a message will be posted in
+`#news-and-announcements` on [Ember Discord](https://discord.gg/emberjs) and on the
+[official Ember Twitter account](https://twitter.com/emberjs) to attract the community's attention.
 
 An RFC can be modified based upon feedback from the [core teams] and community
 during the final comment period. Significant modifications may trigger a new

text/0236-deprecation-ember-string.md

@@ -1,5 +1,5 @@
 ---
-stage: released
+stage: recommended
 start-date: 2017-07-14T00:00:00.000Z
 release-date: 2023-01-12T00:00:00.000Z
 release-versions:
@@ -11,6 +11,7 @@ prs:
   accepted: 'https://github.com/emberjs/rfcs/pull/236'
   ready-for-release: 'https://github.com/emberjs/rfcs/pull/892'
   released: 'https://github.com/emberjs/rfcs/pull/897'
+  recommended: 'https://github.com/emberjs/rfcs/pull/898'
 project-link:
 meta:
   tracking: 'https://github.com/emberjs/ember.js/issues/20340'

text/0331-deprecate-globals-resolver.md

@@ -1,5 +1,5 @@
 ---
-stage: released
+stage: recommended
 start-date: 2018-05-08T00:00:00.000Z
 release-date: 2020-01-20T00:00:00.000Z
 release-versions:

text/0487-custom-model-classes.md

@@ -1,9 +1,9 @@
 ---
 stage: released # FIXME: This may be recommended
 start-date: 2019-05-09T00:00:00.000Z
-release-date: 2019-09-19T00:00:00.000Z
+release-date: 2021-08-20T00:00:00.000Z
 release-versions:
-  ember-source: v3.13.0
+  ember-data: v3.28.0
 
 teams:
   - data

text/0496-handlebars-strict-mode.md

@@ -317,15 +317,15 @@ template string and returning a ready-to-be-consumed template object (the
 output of `createTemplateFactory`), instead of the wire format. This is
 mostly used for compiling templates at runtime, which is pretty rare.
 
-We propose to introduce a new `strict` option to the `precompile` and `compile`
+We propose to introduce a new `strictMode` option to the `precompile` and `compile`
 functions to enable strict mode compilation:
 
 ```js
 import { precompileTemplate } from '@ember/template-compilation';
 
 precompileTemplate('Hello, {{name}}!', {
   moduleName: 'hello.hbs',
-  strict: true
+  strictMode: true
 });
 ```
 
@@ -363,12 +363,13 @@ precompileTemplate(`{{#let this.session.currentUser as |user|}}
   <BlogPost @title={{titleize @model.title}} @body={{@model.body}} @author={{user}} />
 {{/let}}`, {
   moduleName: 'index.hbs',
-  strict: true
+  strictMode: true
 }); /* => `{
   "id": "ANJ73B7b",
   "block": "{\"statements\":[\"...\"]}",
   "meta": { "moduleName": "index.hbs" },
-  "scope": () => [BlogPost, titleize]
+  "scope": () => [BlogPost, titleize],
+  "isStrictMode": true
 }` */
 ```
 
@@ -411,7 +412,8 @@ export default createTemplateFactory({
   "id": "ANJ73B7b",
   "block": "{\"statements\":[\"...\"]}",
   "meta": { "moduleName": "index.hbs" },
-  "scope": () => [BlogPost, titleize]
+  "scope": () => [BlogPost, titleize],
+  "isStrictMode": true
 });
 ```
 
@@ -434,7 +436,8 @@ precompileTemplate(`{{#let this.session.currentUser as |user|}}
 {{/let}}`, {
   moduleName: 'index.hbs',
   strict: true,
-  scope: ['BlogPost', 'titleize']
+  scope: ['BlogPost', 'titleize'],
+  isStrictMode: true
 });
 ```
 
@@ -540,7 +543,7 @@ strict mode semantics at this stage. Instead, the guides should be updated to
 feature template imports or single-file components when they become available.
 
 As for the low-level APIs, we should update the API documentation to cover the
-new flags (`strict` and `scope`). The documentation should cover the details of
+new flags (`strictMode` and `scope`). The documentation should cover the details of
 the "ambient scope" feature discussed in this RFC, and emphasize that it is
 intended for linking static values such as helpers and components.
 
@@ -566,7 +569,7 @@ discussed in the contextual helpers RFC.
 
    By adopting these piecemeal, we will also have to define the interaction and
    combined semantics for any possible combinations of these flags, and tooling
-   will be unable to take advantage of the improved static guarentees without
+   will be unable to take advantage of the improved static guarantees without
    doing a lot of work to account for all these possibilities.
 
 2. Instead of proposing a standalone strict mode, we could just bundle these
@@ -578,7 +581,7 @@ discussed in the contextual helpers RFC.
 
 3. Switch to HTML attributes by default in strict mode.
 
-   Today, Glimmer uses a complicated set of huristics to decide if a bound HTML
+   Today, Glimmer uses a complicated set of heuristics to decide if a bound HTML
    "attribute" syntax should indeed be set using `setAttribute` or set as a
    JavaScript property using `element[...] = ...;`. This does not always work
    well in practice, and it causes a lot of confusion and complexity.

text/0580-destroyables.md

@@ -1,14 +1,14 @@
 ---
-stage: released # FIXME: This may be recommended
+stage: recommended
 start-date: 2020-01-10T00:00:00.000Z
 release-date: 2020-10-05T00:00:00.000Z
 release-versions:
   ember-source: v3.22.0
-
 teams:
   - framework
 prs:
-  accepted: https://github.com/emberjs/rfcs/pull/580
+  accepted: 'https://github.com/emberjs/rfcs/pull/580'
+  recommended: 'https://github.com/emberjs/rfcs/pull/915'
 project-link:
 ---
 

text/0625-helper-managers.md

@@ -1,5 +1,5 @@
 ---
-stage: released # FIXME: This may be a further stage
+stage: recommended
 start-date: 2020-04-28T00:00:00.000Z
 release-date: 2020-11-16T00:00:00.000Z
 release-versions:

text/0637-customizable-test-setups.md

@@ -4,7 +4,7 @@ start-date: 2020-06-01T00:00:00.000Z
 release-date: 2020-05-02T00:00:00.000Z
 release-versions:
   ember-source: v4.4.0
-  # ember-cli: FIXME
+  ember-cli: v4.3.0
 
 teams:
   - framework
@@ -50,7 +50,7 @@ For example:
 
 ```js
   import { module, test } from 'qunit';
-  import setupTest from 'ember-qunit';
+  import { setupTest } from 'ember-qunit';
 
   module('Unit | Service | tomster', function(hooks) {
     setupTest(hooks);
@@ -64,7 +64,7 @@ manually be changed to:
 
 ```js
     import { module, test } from 'qunit';
-    import setupTest from 'my-app/tests/helpers';
+    import { setupTest } from 'my-app/tests/helpers';
 
     module('Unit | Service | tomster', function(hooks) {
       setupTest(hooks);
@@ -77,8 +77,8 @@ or where the setup functions are to be composed, this must be added:
 
 ```js
     import { module, test } from 'qunit';
-    import setupTest from 'ember-qunit';
-    import setupMyTest from 'my-app/tests/helpers';
+    import { setupTest } from 'ember-qunit';
+    import { setupMyTest } from 'my-app/tests/helpers';
 
     module('Unit | Service | tomster', function(hooks) {
       setupTest(hooks);

text/0739-ember-data-deprecate-non-strict-relationships.md

@@ -1,12 +1,15 @@
 ---
-stage: accepted # FIXME: This may be a further stage
+stage: recommended
 start-date: 2021-04-23T00:00:00.000Z
-release-date:
+release-date: 2022-09-06T00:00:00.000Z
 release-versions:
+  ember-data: v4.7.0
 teams:
   - data
 prs:
-  accepted: https://github.com/emberjs/rfcs/pull/739
+  accepted: 'https://github.com/emberjs/rfcs/pull/739'
+  ready-for-release: 'https://github.com/emberjs/rfcs/pull/909'
+  released: 'https://github.com/emberjs/rfcs/pull/924'
 project-link:
 ---
 

text/0756-helper-default-manager.md

@@ -67,13 +67,15 @@ of the three constructs: Helpers, Modifiers, and Components._
 The desired usage of a plain function in a template should be:
  - convenient
  - reduce boilerplate
- - be easily portable to JS for developers' mental model of how template and JS interact.
+ - be easily portable to JS for developers' mental model of how template and JS interact
+ - support normal JavaScript idioms and existing JavaScript functions (from lodash, etc).
 
 Which results in:
  - default to positional parameters
  - all named arguments are grouped into an "options object" as the last parameter.
    this happens to align with the _syntax_ of helper invocation where named arguments may not appear
    before the last positional argument.
+ - if no named arguments are passed in the template, no "options object" is passed to the JS call.
 
 #### Example with mixed params
 
@@ -112,6 +114,26 @@ class A {
 }
 ```
 
+#### Example with consuming tracked data defined outside of the helper
+
+This works with the `helper` and `Helper` from `@ember/component/helper`, as well as plain functions.
+
+```hbs
+<output>{{this.multiply 4}}</output>
+
+<button {{on 'click' this.increment}}>Increment</button>
+```
+```js
+class A {
+  @tracked multiplicand = 5;
+
+  multiply = (passed) => passed * this.multiplicand;
+
+  increment = () => this.multiplicand++;
+}
+```
+When the button is clicked, the text in `<output>` will update, even though the `multiplicand` is not passed to the helper.
+
 #### Example Default Helper Implementation
 
 The implementation for the this function-handling helper-manager could look like this:
@@ -136,8 +158,6 @@ class FunctionHelperManager {
 
     if (Object.keys(args.named).length > 0) {
       argsForFn.push(args.named);
-    } else {
-      argsForFn.push({});
     }
 
     return fn(...argsForFn);
@@ -153,12 +173,61 @@ const DEFAULT_HELPER_MANAGER = new FunctionHelperManager();
 // side-effect -- this file needs to be imported for the helper manager to be installed
 setHelperManager(() => DEFAULT_HELPER_MANAGER, Function.prototype);
 ```
- - when the "helper" is created, the function is not invoked
- - when `getValue` is invoked,
-   - the function is invoked with the named arguments all grouped into the last arg
-   - if no named arguments are given, an empty object is used instead to allow less nullish checking in userland
- - to register this helper manager, it should occur during app boot so developers do not need to import anything to
-   trigger the `setHelperManager` call
+
+- when the "helper" is created, the function is not invoked
+- when `getValue` is invoked,
+  - the function is invoked with the named arguments all grouped into an object in the last arg ("options object")
+  - ~~if no named arguments are given, an empty object is used instead to allow less nullish checking in userland~~ (see notes below)
+  - if no named are passed, the "options object" argument is omitted
+- to register this helper manager, it should occur during app boot so developers do not need to import anything to
+  trigger the `setHelperManager` call
+
+##### Notes regarding the "options object" argument
+
+An earlier version of this RFC initially proposed an "options object" with always be passed
+as the argument, even when no-named arguments are passed. During [implementation](https://github.com/glimmerjs/glimmer-vm/pull/1348)
+this was observed to be problematic.
+
+For instance, given the following JavaScript function:
+
+```js
+function sum(...values) {
+  let total = 0;
+
+  for (let value of values) {
+    total += value;
+  }
+
+  return total;
+}
+```
+
+In the original proposal, an invocation like `{{sum 1 2 3}}` would result in the JS call
+`sum(1, 2, 3, {})`, which would yield surprising and incorrect result.
+
+Another case where this matters is with default arguments:
+
+```js
+function formatDate(date, formatString = "DD MM YYYY hh:mm:ss") {
+  return ...;
+}
+```
+
+In the original proposal, an invocation like `{{formatDate this.now}}` would result in the
+JS call `formatDate(this.now, {})`, which has the effect of overriding the default argument
+`formatString` with an empty object, also leading to surprising and incorrect behavior.
+
+Given the goal of the RFC is to support normal JavaScript idioms and the ability to use a
+large variety of existing JavaScript functions (from packages like lodash) directly in the
+template, the proposal is updated to only pass the "options object" when necessary.
+
+This has the drawback of an arguably less consistent signature. However, in practice, this
+did not appear to be a issue. Base on the semantics and idioms of JavaScript, it is quite
+rare for functions to mix-and-match variable positional arguments or defaulting of positional
+arguments together with "named arguments" ("option object") in a way that would conflict with
+what the updated proposal. Notably, JavaScript does not support `myFunc(...args, options)` in
+the syntax, and functions with these kind of signatures already needs to manually introspect
+the arguments carefully, in ways that should be compatible with the current proposal.
 
 ### Updating highlevel manager choosing algorithm
 

text/0811-element-modifiers.md

@@ -1,13 +1,16 @@
 ---
-stage: accepted
+stage: released
 start-date: 2022-03-29T00:00:00.000Z
-release-date:
+release-date: 2023-03-03T00:00:00.000Z
 release-versions:
-teams: # delete teams that aren't relevant
+  ember-cli: v4.11.0
+teams:
   - cli
   - learning
 prs:
-  accepted: https://github.com/emberjs/rfcs/pull/811
+  accepted: 'https://github.com/emberjs/rfcs/pull/811'
+  ready-for-release: 'https://github.com/emberjs/rfcs/pull/885'
+  released: 'https://github.com/emberjs/rfcs/pull/928'
 project-link:
 ---
 

text/0812-tracked-built-ins.md

@@ -1,13 +1,14 @@
 ---
-stage: accepted
+stage: ready-for-release
 start-date: 2022-03-29T00:00:00.000Z
 release-date:
 release-versions:
-teams: # delete teams that aren't relevant
+teams:
   - cli
   - learning
 prs:
-  accepted: https://github.com/emberjs/rfcs/pull/812
+  accepted: 'https://github.com/emberjs/rfcs/pull/812'
+  ready-for-release: 'https://github.com/emberjs/rfcs/pull/886'
 project-link:
 ---