New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Introduce `<AngleBracketInvocationSyntax />` #311

Merged
merged 7 commits into from May 4, 2018

Conversation

Projects
None yet
@chancancode
Member

chancancode commented Mar 11, 2018

Rendered

chancancode and others added some commits Mar 11, 2018

@sclaxton

This comment has been minimized.

sclaxton commented Mar 11, 2018

I’m pretty opposed to overriding the proposed syntax for passing named blocks structurally, i.e. <@foo></@foo>. In my mind this syntax is pretty important for representing the mental model that named blocks are really just the same as passing the block as an argument. It also seems more natural syntactically that thing inside naked angle brackets should treated as static names rather than dynamic expressions. Could we not instead have dynamic invokation be expressed with curlies? <{{@foo}}></{{@foo}}> seems to convey dynamic-ness to me more than <@foo></@foo>.

@mmun

This comment has been minimized.

Member

mmun commented Mar 11, 2018

In my mind this syntax is pretty important for representing the mental model that named blocks are really just the same as passing the block as an argument.

I strongly agree with this and it's one of the reasons why I prefer the <@foo=>...</@foo> block-passing syntax (with the equal sign) over bare <@foo>...</@foo>. My hunch is that the latter syntax will lead people to assume this syntax behaves like HTML children rather than as arguments for the component.

The second reason is that the <@foo>...</@foo> block-passing syntax prevents us from having a <form.submit>...</form.submit> syntax for invoking contextual components. This feature is very important to me. When I've worked with JSX in the past I've really enjoyed the simplicity of being able to do this.

@sclaxton

This comment has been minimized.

sclaxton commented Mar 11, 2018

@mmun those are fair points. It still feels weird to me to allow dynamic expressions outside of curlies, e.g. <this.someProperty />. With the exception of maybe the ...attributes keyword in glimmer, it seems like we’ve kept dynamic expressions within curlie braces. This seems like a pretty big departure from that. Can someone speak to the rationale behind that decision? @chancancode @wycats

P.s. Thinking out loud: requiring curly-braces for dynamic invocation would also solve the block local variable issue:

<MyForm as |foo|>
  <{{foo}} />
</MyForm>
@tchak

This comment has been minimized.

Member

tchak commented Mar 12, 2018

Is it really not possible to support positional params?

internal block. Since the `yield` keyword is not available in element position,
a dedicated syntax is needed.

> Open Question: Should classic components (`Ember.Component`) implicitly add

This comment has been minimized.

@joukevandermaas

joukevandermaas Mar 12, 2018

I'm assuming 'classic component' is a reference to the component manager RFC? Initially this paragraph was (maybe still is) very confusing to me. I guess I can understand the point of the question if I assume the following:

  1. 'Classic components' (current-day Ember components) do not support ...attributes, so throwing an error when they are not used seems wrong (at least initially)
  2. Glimmer components do support it so they will work as described in the paragraphs above

Can someone please correct my understanding if it's wrong?

This comment has been minimized.

@mmun

mmun Mar 12, 2018

Member

Yes, that seems correct.

I think that classic components should fully support ...attributes and that we should automatically insert ...attributes to the wrapping element if it doesn't appear in the template and tagName: '' hasn't been used.

This would allow people to immediately start using HTML attributes with their classic components and remove the need for hacky add-ons like https://github.com/mmun/ember-component-attributes.

> Open Question: What should `{{has-block}}` return for components invoked with
> the self-closing tag? On one hand, returning true would be quite counter-
> intuitive; on the other hand, returning false would mean self-closing tags and
> not semantically equivalent to an immediately closed tag.

This comment has been minimized.

@joukevandermaas

joukevandermaas Mar 12, 2018

I really don't get this. They are not semantically equivalent. An immediately closed tag has a block, but it's empty. Is there some technical reason why they should be the same?

This comment has been minimized.

@mmun

mmun Mar 12, 2018

Member

I agree. <Foo></Foo> should have a block with no content whereas <Foo /> should not have a block passed at all (similar to {{some-component}}).

This comment has been minimized.

@mmun

mmun Mar 12, 2018

Member

The RFC was alluding to some of the technicalities around self-closing tags in the HTML spec, but I think it's ok to make small refinement to the semantics for angle bracket component invocations.

@mmun

This comment has been minimized.

Member

mmun commented Mar 12, 2018

@tchak My gut feeling is that positional arguments don't really fit well the angle bracket component invocation syntax and should remain a curly component thing (which aren't deprecated!), but I'd be interested to hear compelling use cases or syntax ideas. Keep in mind that any syntax ideas should be compatible with #112.

@averydev

This comment has been minimized.

averydev commented Mar 12, 2018

I'm curious whether the long term goal is for there to only be the angle bracket syntax, or whether there would always be curlies and angle bracket options?

@Gaurav0

This comment has been minimized.

Contributor

Gaurav0 commented Mar 13, 2018

As a practical matter, I would like to be able to convert to angle bracket syntax, especially for the one way binding advantages. However, my large work app has lots of nested components and not being able to traditionally nest components in directories pretty much means we will have most of our components remain curly components indefinitely. I think this is pretty much true of any large enterprise app.

I think a way to invoke components nested in directories globally is absolutely necessary if large enterprise apps are ever going to be able to migrate. While it is possible to hack the resolver, I would prefer a shared solution.

Note: The current RFC draft does not explicitly forbid slashes. This should be added if they are not going to be supported as previously expected.

More generally, the tag name portion can be any path expressions:

```hbs
<this.foo>...</this.foo>

This comment has been minimized.

@sclaxton

sclaxton Mar 15, 2018

What types are permissible for this.foo in this case? Curried component? String?

@courajs

This comment has been minimized.

courajs commented Mar 18, 2018

@chancancode this proposal doesn't include the one-way binding semantics @Gaurav0 mentions, correct? That was part of the original angle brackets proposal, but has been removed here?

@courajs

This comment has been minimized.

courajs commented Mar 18, 2018

I'm slightly concerned about how the capitalization interacts with native HTML elements. Right now, <Button>Press</Button> will render the native browser button tag. Does this need to come with the specification that native elements must always be specified lower-case in templates?

@courajs

This comment has been minimized.

courajs commented Mar 18, 2018

I think {{has-block}} should probably return false for self-closing tags, and true for immediately-closed tags. Then, these would correspond more closely with curly invocation - self-closing is the inline invocation form, and immediately closed is the block form.

Since a lot of components use has-block to render default content, there should be a way to send no block. If it returned true for self-closing tags, we'd need to specify some other way to pass no block. Currently you'd have to do something like <Comp @main={{null}} />, but adding some other additional syntax seems likely to feel awkward as well.

@Panman8201

This comment has been minimized.

Panman8201 commented Mar 19, 2018

I think {{has-block}} should probably return false for self-closing tags, and true for immediately-closed tags.

Agreed, it seems more semantically correct. IMO, if it returns false for immediately-closed tags then it would be more appropriately named {{has-content}}. Perhaps add both for additional information.?.

I'm curious whether the long term goal is for there to only be the angle bracket syntax, or whether there would always be curlies and angle bracket options?

I'd like to add, years back when I first looked into front-end frameworks I wanted angle-bracket components. But now I'm not so sure, curlies seem to be a better fit. Take it as a grain of salt, just my own feelings ATM.

@chancancode

This comment has been minimized.

Member

chancancode commented Mar 21, 2018

I have updated the RFC to reflect a few things we discussed in the EmberConf core team meeting:

  • For now, <Foo /> (where Foo is a local variable) will be the only kind of dynamic invocation allowed. This makes all component invocations uniformly start with a capital letter and allow for more time to collect feedback on what other forms of dynamic invocations should be allowed.

  • Classic components will have ...attributes added to the wrapper element.

  • <Foo /> will have {{has-block}} set to false.

@chancancode

This comment has been minimized.

Member

chancancode commented Mar 21, 2018

I'm slightly concerned about how the capitalization interacts with native HTML elements. Right now, Press will render the native browser button tag. Does this need to come with the specification that native elements must always be specified lower-case in templates?

@courajs That is technically true, but I think it is very rare and almost never happens in practice. If we want to be super careful, we can put in a warning/error now to clear the space before rolling it out. Are you asking because you have seen this in the wild?

@chancancode

This comment has been minimized.

Member

chancancode commented Mar 21, 2018

I'm curious whether the long term goal is for there to only be the angle bracket syntax, or whether there would always be curlies and angle bracket options?

@averydev As stated in the RFC, curly invocation is here to stay. I think in the long term, curlies will be primarily used for things that are like control-flow (e.g. animated-each).

@chancancode

This comment has been minimized.

Member

chancancode commented Mar 21, 2018

this proposal doesn't include the one-way binding semantics @Gaurav0 mentions, correct? That was part of the original angle brackets proposal, but has been removed here?

@Gaurav0 @courajs This proposal does not include the one-way binding semantics from the original proposal. This proposal is really just just an alternative syntax for the existing invocation style (with some feature differences – one has positional arguments, the other has attributes).

The two-way binding semantics generally "doesn't matter" as long as you don't use it in the component classes. In the cases where they matter, they affect curly invocations just as much. Since we are proposing that they are both here to stay and there are good use cases for both, it is not really feasible to fix one but not the other.

I think we have better tools to fix that now (optional features, deprecations, etc), so I am pretty optimistic that we can find a way to fix that broadly. But if we somehow cannot do that, the divergence in semantics between the two invocation styles will be more of a problem in the long term.

@rwjblue

This comment has been minimized.

Member

rwjblue commented Mar 21, 2018

the divergence in semantics between the two invocation styles will be more of a problem in the long term

I strongly agree. The current proposal supports gradual migration and straight-forward interop over broad sweeping changes. This will ultimately translate into fewer "cliffs" for existing applications...

@wycats

This comment has been minimized.

Member

wycats commented Mar 21, 2018

@rwjblue @chancancode I agree with this. Since we don't think we're going to remove "curly invocation", and plan to keep it around for control-flow style abstractions (liquid-if), we're going to have to deprecate auto-mut for those cases anyway.

Additionally, Glimmer component classes do not see two-way bindings, since the Glimmer component manager doesn't create two-way properties on the component class, and also sets an immutable args object. The fact that angle-bracket components still nominally create two-way bindings is more-or-less a consequence of the fact that angle bracket components can be used to invoke classic component classes in this proposal.

(Aside: given this, we will need to decide how <Input> should be written using Glimmer component classes. We don't want to reify mut onto args today because of auto-mut, but maybe we would be willing to reify it after other changes?)

@Gaurav0

This comment has been minimized.

Contributor

Gaurav0 commented Mar 22, 2018

Please specify if <A/b /> or <A/b>...</A/b> will be allowed to invoke nested components.

@rwjblue

This comment has been minimized.

Member

rwjblue commented Mar 22, 2018

Please specify if <A/b /> or <A/b>...</A/b> will be allowed to invoke nested components.

This is not supported, I agree the RFC should be a tad more explicit in the Tag Name section.

@rwjblue

This comment has been minimized.

Member

rwjblue commented Mar 22, 2018

@Gaurav0:

As a practical matter, I would like to be able to convert to angle bracket syntax, especially for the one way binding advantages.

There is no behavior change associated with angle bracket invocation. The support of two way bindings is entirely based on the base class of your component. This RFC does not propose to change that at all.

However, my large work app has lots of nested components and not being able to traditionally nest components in directories pretty much means we will have most of our components remain curly components indefinitely. I think this is pretty much true of any large enterprise app.

I agree that this complicates migration. It seems absolutely fine to continue using curly invocation (with nested directory structures) indefinitely! There is no proposal to deprecate or make curly component invocation "second class".

Please note though, that there are a number of ways that you can obtain grouping behaviors already (and even more on the way!). For example, you could use a file-name prefix along with in repo addons as a mechanism to namespace components (both physically and in the template).

If you look ahead a bit, you can see there are even more tools to aid in this. The new file system layout (being actively pushed forward by the community) provides both lighter weight namespaces and a very clear way to invoke them from the template. In addition to light weight namespaces, we are also adding local lookup capabilities. When leveraging local lookup you can easily scope components to a specific subdirectory so that they are only available within specific routes or components. The combination of these two things provide an even better mechanism for grouping that folders do!

I think a way to invoke components nested in directories globally is absolutely necessary if large enterprise apps are ever going to be able to migrate.

I agree to disagree with you. 😺 I believe the new file system layout with both namespaced packages and local lookup are wonderful paths forward to avoid that nested directory invocation.

While it is possible to hack the resolver, I would prefer a shared solution.

I agree that modifying the resolver is not a good long term strategy.

Note: The current RFC draft does not explicitly forbid slashes.

Yep, absolutely should be updated to make it much clearer.

This should be added if they are not going to be supported as previously expected.

This statement is pretty confusing. I am not aware of any prior proposal that allowed nested directory invocation.

@lmcardle

This comment has been minimized.

lmcardle commented Mar 24, 2018

What’s the plan to support contextual components. I agree with @mmun, this is an important feature with components today.

@mmun

This comment has been minimized.

Member

mmun commented Mar 24, 2018

I still want a follow-up RFC for <f.input> but it needs works and its not necessary for merging the simple angle bracket invocation style. In the mean time {{f.input}} will continue to work...

@lmcardle

This comment has been minimized.

lmcardle commented Mar 24, 2018

@mmun, you can do this in jsx? I’m curious how they accomplish this, do you have a reference by any chance?

@mmun

This comment has been minimized.

Member

mmun commented Mar 24, 2018

@lmcardle It wouldn't be using JSX, just inspired and validated by it. It would be implemented by changing the Glimmer parser.

@chancancode chancancode force-pushed the AngleBracketInvocation branch from 49c8ebe to 9933192 Apr 6, 2018

> [RFC #317](https://github.com/emberjs/rfcs/pull/317) propose to change the
> block-passing syntax to `<@foo=>...</@foo>` to avoid this conflict.
Notably, based on the rules laied out above, the following is perfectly legal:

This comment has been minimized.

@mmun

mmun Apr 6, 2018

Member

typo: laid

as an opt-in to the "new-world" components programming model.

Since then, we have switched to a more iterative approach, favoring smaller
RFCs focusing on one area of improvment at a time. Collectively, these RFCs

This comment has been minimized.

@alexlafroscia

alexlafroscia Apr 6, 2018

Should be improvement


In today's semantics, `{{foo/bar}}` does not try to lookup `this.foo.bar` and
invoke it as a component. Instead, it is used as a filesystem scoping syntax.
Since this feature will be rendered unnecessary with [Module Unification](https://github.com/emberjs/rfcs/blob/master/text/0143-module-unification.md),

This comment has been minimized.

@Gaurav0

Gaurav0 Apr 6, 2018

Contributor

Disagree that this feature is unnecessary. 📁 are the most natural way to organize components and are widely used in large applications. None of the alternatives presented in module unification are intuitive or easily transitioned to.

Recommend "Since this feature will not be permitted with...

@rwjblue

This comment has been minimized.

Member

rwjblue commented Apr 6, 2018

After discussion with the core team this afternoon, we are 👍 on moving this RFC into the final comment period.

@oligriffiths

This comment has been minimized.

oligriffiths commented Apr 10, 2018

Can I ask why <Foo @bar=123 /> is not supported, that the value must be {{123}}?

@chilicoder

This comment has been minimized.

chilicoder commented Apr 10, 2018

<FooBar @foo={{123}} @bar={{this.bar}} />

I can imagine myriad of @ in my components) can I get <FooBar {{foo=123 bar=this.bar}} /> please?

Moreover, I see no point of having this @ just write <FooBar aria-role="some" {{foo=123}}/> how we do now for static HTML elements and use @ for something else).

@mikkopaderes

This comment has been minimized.

mikkopaderes commented Apr 17, 2018

@chancancode I didn't see anything that mentions {{yield to="inverse"}}. I'm guessing syntax would be the same?

e.g.

<Grid as |item|>
  <GridItem @item={{item}}>
{{else}}
  No item available
</Grid>
@rwjblue

This comment has been minimized.

Member

rwjblue commented May 4, 2018

@rmmmp:

I didn't see anything that mentions {{yield to="inverse"}}. I'm guessing syntax would be the same?

Quoting from the RFC:

There is no dedicated syntax for passing an "else" block directly. If needed, that can be passed using the named blocks syntax.

@chadhietala

This comment has been minimized.

Member

chadhietala commented May 4, 2018

Since 14 days have passed with no additional unaddressed comments, I'm going to merge this RFC.

@chadhietala chadhietala merged commit b8dbf42 into master May 4, 2018

1 check passed

continuous-integration/travis-ci/pr The Travis CI build passed
Details

@rwjblue rwjblue deleted the AngleBracketInvocation branch May 4, 2018

@bravo-kernel

This comment has been minimized.

bravo-kernel commented Jul 8, 2018

Should the label not be removed?

Turbo87 added a commit to ember-cli/ember-cli-eslint that referenced this pull request Oct 17, 2018

Bump ember-source from 2.18.2 to 3.5.0 (#281)
Bumps [ember-source](https://github.com/emberjs/ember.js) from 2.18.2 to 3.5.0.
<details>
<summary>Release notes</summary>

*Sourced from [ember-source's releases](https://github.com/emberjs/ember.js/releases).*

> ## v3.5.0
> ### CHANGELOG
> 
> - [#16978](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16978) [BUGFIX] Properly teardown alias
> - [#16877](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16877) [CLEANUP] Allow routes to be named "array" and "object"
> 
> ## v3.5.0-beta.4
> ### CHANGELOG
> 
> - [#17003](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17003) / [#17013](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17013) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')`
> 
> ## v3.5.0-beta.3
> ### CHANGELOG
> 
> - [#16978](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16978) [BUGFIX] Properly teardown alias
> - [#16999](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16999) [BUGFIX] Fix mouseEnter/Leave event delegation w/o jQuery
> 
> ## v3.5.0-beta.2
> ### CHANGELOG
> 
> - [#16933](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16933) [BUGFIX] Update glimmer-vm packages to 0.38.8
> - [#16860](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16860) [BUGFIX] Clear chains in ProxyMixin when destroyed
> 
> ## v3.5.0-beta.1
> ### CHANGELOG
> 
> - [#16877](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16877) [CLEANUP] Allow routes to be named "array" and "object"
> - [#16907](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16907) Upgrade to TypeScript 3.0
> 
> ## v3.4.5
> ### CHANGELOG
> 
> - [#17029](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17029) [BUGFIX] Update backburner.js to 2.4.0.
> 
> ## v3.4.4
> ### CHANGELOG
> 
> - [#17013](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17013) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')` in IE11
> 
> ## v3.4.3
> ### CHANGELOG
> 
> - [#17003](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17003) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')`
> 
> ## v3.4.2
> ### CHANGELOG 
> 
> - [#16860](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16860) [BUGFIX] Clear chains in ProxyMixin when destroyed
> - [#16999](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16999) [BUGFIX] Fix mouseEnter/Leave event delegation without jQuery
> 
></table> ... (truncated)
</details>
<details>
<summary>Changelog</summary>

*Sourced from [ember-source's changelog](https://github.com/emberjs/ember.js/blob/master/CHANGELOG.md).*

> ### v3.5.0 (October 8, 2018)
> 
> - [#16978](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16978) [BUGFIX] Properly teardown alias
> - [#16877](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16877) [CLEANUP] Allow routes to be named "array" and "object"
> 
> ### v3.4.5 (October 4, 2018)
> 
> - [#17029](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17029) [BUGFIX] Update backburner.js to 2.4.0.
> 
> ### v3.4.4 (September 27, 2018)
> 
> - [#17013](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17013) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')` in IE11
> 
> ### v3.4.3 (September 25, 2018)
> 
> - [#17003](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17003) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')`
> 
> ### v3.4.2 (September 24, 2018)
> 
> - [#16860](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16860) [BUGFIX] Clear chains in ProxyMixin when destroyed
> - [#16999](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16999) [BUGFIX] Fix mouseEnter/Leave event delegation without jQuery
> 
> ### v3.4.1 (September 10, 2018)
> 
> - [#16933](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16933) [BUGFIX] Update glimmer-vm packages to 0.35.8
> 
> ### v3.4.0 (August 27, 2018)
> 
> - [#16603](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16603) [BUGFIX] Support mouseEnter/Leave events w/o jQuery
> - [#16857](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16857) [BUGFIX] Prevents the recursive redefinition of root chains
> - [#16854](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16854) [BUGFIX] Don't thread FactoryManager through createComponent
> - [#16773](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16773) [FEATURE] Custom component manager (see [emberjs/rfcs#213](https://github.com/emberjs/rfcs/blob/master/text/0213-custom-components.md) for more details)
> - [#16708](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16708) [FEATURE] Angle bracket component invocation (see [emberjs/rfcs#311](https://github.com/emberjs/rfcs/blob/master/text/0311-angle-bracket-invocation.md) for more details)
> - [#16744](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16744) [DEPRECATION] Deprecate `component#sendAction` (see [emberjs/rfcs#335](https://github.com/emberjs/rfcs/blob/master/text/0335-deprecate-send-action.md) for more details)
> - [#16720](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16720) Upgrade `backburner.js` to 2.3.0
> - [#16783](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16783) [BUGFIX] Allow setting length on ArrayProxy.
> - [#16785](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16785) [BUGFIX] Ensure `ArrayMixin#invoke` returns an Ember.A.
> - [#16784](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16784) [BUGFIX] Setting ArrayProxy#content in willDestroy resets length.
> - [#16794](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16794) [BUGFIX] Fix instance-initializer-test blueprint for new QUnit testing API ([emberjs/rfcs#232](https://github-redirect.dependabot.com/emberjs/rfcs/pull/232))
> - [#16797](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16797) [BUGFIX] Drop autorun assertion
> 
> ### v3.3.2 (August 20, 2018)
> 
> - [#16853](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16853) [BUGFIX] Allow ArrayProxy#pushObjects to accept ArrayProxy again
> - [#16870](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16870) [BUGFIX] Enable @ember/object#get to be called with an empty string
> 
> ### v3.3.1 (July 23, 2018)
> 
> - [#16836](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16836/commits) [DOC] Fix Broken 3.3 API Documentation
> 
></table> ... (truncated)
</details>
<details>
<summary>Commits</summary>

- [`db6a5de`](emberjs/ember.js@db6a5de) Release v3.5.0
- [`cae13d4`](emberjs/ember.js@cae13d4) Add v3.5.0 to CHANGELOG
- [`5da9996`](emberjs/ember.js@5da9996) Fix typo on line 75
- [`b41d933`](emberjs/ember.js@b41d933) Fixup CHANGELOG
- [`48ad148`](emberjs/ember.js@48ad148) Add v3.4.5 to CHANGELOG
- [`d37a42e`](emberjs/ember.js@d37a42e) Release v3.5.0-beta.4
- [`942fdb7`](emberjs/ember.js@942fdb7) Add v3.5.0-beta.4 to CHANGELOG
- [`16225e8`](emberjs/ember.js@16225e8) [DOC RELEASE] [DOC 3.3] [DOC 3.4] Fix missing docs
- [`e90e1c6`](emberjs/ember.js@e90e1c6) Fix rendering of empty content with `{{{...}}}` in IE11
- [`d752b94`](emberjs/ember.js@d752b94) Merge pull request [#17004](https://github-redirect.dependabot.com/emberjs/ember.js/issues/17004) from emberjs/beta-triple-curlies-bugfix
- Additional commits viewable in [compare view](emberjs/ember.js@v2.18.2...v3.5.0)
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=ember-source&package-manager=npm_and_yarn&previous-version=2.18.2&new-version=3.5.0)](https://dependabot.com/compatibility-score.html?dependency-name=ember-source&package-manager=npm_and_yarn&previous-version=2.18.2&new-version=3.5.0)

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

Dependabot will **not** automatically merge this PR because it includes a major update to a development dependency.

---

**Note:** This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking `Bump now` in your [Dependabot dashboard](https://app.dependabot.com).

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>

Turbo87 added a commit to emberjs/ember-qunit that referenced this pull request Oct 17, 2018

Bump ember-source from 2.18.2 to 3.5.0 (#357)
Bumps [ember-source](https://github.com/emberjs/ember.js) from 2.18.2 to 3.5.0.
<details>
<summary>Release notes</summary>

*Sourced from [ember-source's releases](https://github.com/emberjs/ember.js/releases).*

> ## v3.5.0
> ### CHANGELOG
> 
> - [#16978](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16978) [BUGFIX] Properly teardown alias
> - [#16877](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16877) [CLEANUP] Allow routes to be named "array" and "object"
> 
> ## v3.5.0-beta.4
> ### CHANGELOG
> 
> - [#17003](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17003) / [#17013](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17013) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')`
> 
> ## v3.5.0-beta.3
> ### CHANGELOG
> 
> - [#16978](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16978) [BUGFIX] Properly teardown alias
> - [#16999](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16999) [BUGFIX] Fix mouseEnter/Leave event delegation w/o jQuery
> 
> ## v3.5.0-beta.2
> ### CHANGELOG
> 
> - [#16933](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16933) [BUGFIX] Update glimmer-vm packages to 0.38.8
> - [#16860](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16860) [BUGFIX] Clear chains in ProxyMixin when destroyed
> 
> ## v3.5.0-beta.1
> ### CHANGELOG
> 
> - [#16877](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16877) [CLEANUP] Allow routes to be named "array" and "object"
> - [#16907](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16907) Upgrade to TypeScript 3.0
> 
> ## v3.4.5
> ### CHANGELOG
> 
> - [#17029](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17029) [BUGFIX] Update backburner.js to 2.4.0.
> 
> ## v3.4.4
> ### CHANGELOG
> 
> - [#17013](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17013) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')` in IE11
> 
> ## v3.4.3
> ### CHANGELOG
> 
> - [#17003](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17003) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')`
> 
> ## v3.4.2
> ### CHANGELOG 
> 
> - [#16860](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16860) [BUGFIX] Clear chains in ProxyMixin when destroyed
> - [#16999](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16999) [BUGFIX] Fix mouseEnter/Leave event delegation without jQuery
> 
></table> ... (truncated)
</details>
<details>
<summary>Changelog</summary>

*Sourced from [ember-source's changelog](https://github.com/emberjs/ember.js/blob/master/CHANGELOG.md).*

> ### v3.5.0 (October 8, 2018)
> 
> - [#16978](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16978) [BUGFIX] Properly teardown alias
> - [#16877](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16877) [CLEANUP] Allow routes to be named "array" and "object"
> 
> ### v3.4.5 (October 4, 2018)
> 
> - [#17029](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17029) [BUGFIX] Update backburner.js to 2.4.0.
> 
> ### v3.4.4 (September 27, 2018)
> 
> - [#17013](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17013) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')` in IE11
> 
> ### v3.4.3 (September 25, 2018)
> 
> - [#17003](https://github-redirect.dependabot.com/emberjs/ember.js/pull/17003) [BUGFIX] Fix rendering of empty content with `{{{...}}}` or `{{...}}` with `htmlSafe('')`
> 
> ### v3.4.2 (September 24, 2018)
> 
> - [#16860](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16860) [BUGFIX] Clear chains in ProxyMixin when destroyed
> - [#16999](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16999) [BUGFIX] Fix mouseEnter/Leave event delegation without jQuery
> 
> ### v3.4.1 (September 10, 2018)
> 
> - [#16933](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16933) [BUGFIX] Update glimmer-vm packages to 0.35.8
> 
> ### v3.4.0 (August 27, 2018)
> 
> - [#16603](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16603) [BUGFIX] Support mouseEnter/Leave events w/o jQuery
> - [#16857](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16857) [BUGFIX] Prevents the recursive redefinition of root chains
> - [#16854](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16854) [BUGFIX] Don't thread FactoryManager through createComponent
> - [#16773](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16773) [FEATURE] Custom component manager (see [emberjs/rfcs#213](https://github.com/emberjs/rfcs/blob/master/text/0213-custom-components.md) for more details)
> - [#16708](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16708) [FEATURE] Angle bracket component invocation (see [emberjs/rfcs#311](https://github.com/emberjs/rfcs/blob/master/text/0311-angle-bracket-invocation.md) for more details)
> - [#16744](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16744) [DEPRECATION] Deprecate `component#sendAction` (see [emberjs/rfcs#335](https://github.com/emberjs/rfcs/blob/master/text/0335-deprecate-send-action.md) for more details)
> - [#16720](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16720) Upgrade `backburner.js` to 2.3.0
> - [#16783](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16783) [BUGFIX] Allow setting length on ArrayProxy.
> - [#16785](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16785) [BUGFIX] Ensure `ArrayMixin#invoke` returns an Ember.A.
> - [#16784](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16784) [BUGFIX] Setting ArrayProxy#content in willDestroy resets length.
> - [#16794](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16794) [BUGFIX] Fix instance-initializer-test blueprint for new QUnit testing API ([emberjs/rfcs#232](https://github-redirect.dependabot.com/emberjs/rfcs/pull/232))
> - [#16797](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16797) [BUGFIX] Drop autorun assertion
> 
> ### v3.3.2 (August 20, 2018)
> 
> - [#16853](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16853) [BUGFIX] Allow ArrayProxy#pushObjects to accept ArrayProxy again
> - [#16870](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16870) [BUGFIX] Enable @ember/object#get to be called with an empty string
> 
> ### v3.3.1 (July 23, 2018)
> 
> - [#16836](https://github-redirect.dependabot.com/emberjs/ember.js/pull/16836/commits) [DOC] Fix Broken 3.3 API Documentation
> 
></table> ... (truncated)
</details>
<details>
<summary>Commits</summary>

- [`db6a5de`](emberjs/ember.js@db6a5de) Release v3.5.0
- [`cae13d4`](emberjs/ember.js@cae13d4) Add v3.5.0 to CHANGELOG
- [`5da9996`](emberjs/ember.js@5da9996) Fix typo on line 75
- [`b41d933`](emberjs/ember.js@b41d933) Fixup CHANGELOG
- [`48ad148`](emberjs/ember.js@48ad148) Add v3.4.5 to CHANGELOG
- [`d37a42e`](emberjs/ember.js@d37a42e) Release v3.5.0-beta.4
- [`942fdb7`](emberjs/ember.js@942fdb7) Add v3.5.0-beta.4 to CHANGELOG
- [`16225e8`](emberjs/ember.js@16225e8) [DOC RELEASE] [DOC 3.3] [DOC 3.4] Fix missing docs
- [`e90e1c6`](emberjs/ember.js@e90e1c6) Fix rendering of empty content with `{{{...}}}` in IE11
- [`d752b94`](emberjs/ember.js@d752b94) Merge pull request [#17004](https://github-redirect.dependabot.com/emberjs/ember.js/issues/17004) from emberjs/beta-triple-curlies-bugfix
- Additional commits viewable in [compare view](emberjs/ember.js@v2.18.2...v3.5.0)
</details>
<br />

[![Dependabot compatibility score](https://api.dependabot.com/badges/compatibility_score?dependency-name=ember-source&package-manager=npm_and_yarn&previous-version=2.18.2&new-version=3.5.0)](https://dependabot.com/compatibility-score.html?dependency-name=ember-source&package-manager=npm_and_yarn&previous-version=2.18.2&new-version=3.5.0)

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

Dependabot will **not** automatically merge this PR because it includes an out-of-range update to a development dependency.

---

**Note:** This repo was added to Dependabot recently, so you'll receive a maximum of 5 PRs for your first few update runs. Once an update run creates fewer than 5 PRs we'll remove that limit.

You can always request more updates by clicking `Bump now` in your [Dependabot dashboard](https://app.dependabot.com).

<details>
<summary>Dependabot commands and options</summary>
<br />

You can trigger Dependabot actions by commenting on this PR:
- `@dependabot rebase` will rebase this PR
- `@dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `@dependabot merge` will merge this PR after your CI passes on it
- `@dependabot cancel merge` will cancel a previously requested merge
- `@dependabot reopen` will reopen this PR if it is closed
- `@dependabot ignore this [patch|minor|major] version` will close this PR and stop Dependabot creating any more for this minor/major version (unless you reopen the PR or upgrade to it yourself)
- `@dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
- `@dependabot use these labels` will set the current labels as the default for future PRs for this repo and language
- `@dependabot use these reviewers` will set the current reviewers as the default for future PRs for this repo and language
- `@dependabot use these assignees` will set the current assignees as the default for future PRs for this repo and language
- `@dependabot use this milestone` will set the current milestone as the default for future PRs for this repo and language
- `@dependabot badge me` will comment on this PR with code to add a "Dependabot enabled" badge to your readme

Additionally, you can set the following in your Dependabot [dashboard](https://app.dependabot.com):
- Update frequency (including time of day and day of week)
- Automerge options (never/patch/minor, and dev/runtime dependencies)
- Pull request limits (per update run and/or open at any time)
- Out-of-range updates (receive only lockfile updates, if desired)
- Security updates (receive only security updates, if desired)

Finally, you can contact us by mentioning @dependabot.

</details>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment