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

Custom Components API #213

Merged
merged 14 commits into from Mar 21, 2018

Conversation

@chancancode
Member

chancancode commented Mar 13, 2017

rendered

@joukevandermaas

This comment has been minimized.

Show comment
Hide comment
@joukevandermaas

joukevandermaas Apr 3, 2017

I have a question on the scope of this RFC. Given the announcements at EmberConf, I sort of assume that the Glimmer/Ember integration can use this RFC as a building block. However, from the text in this RFC it appears that the layout/template of a component is an opaque thing, while Glimmer components also introduce new template syntax/semantics:

  • using @ to mark component parameters vs. DOM attributes
  • using angle-bracket syntax to invoke components
  • maybe more(?)

Is supporting that kind of semantics change in scope of this RFC? If so, how would I do something like that?

joukevandermaas commented Apr 3, 2017

I have a question on the scope of this RFC. Given the announcements at EmberConf, I sort of assume that the Glimmer/Ember integration can use this RFC as a building block. However, from the text in this RFC it appears that the layout/template of a component is an opaque thing, while Glimmer components also introduce new template syntax/semantics:

  • using @ to mark component parameters vs. DOM attributes
  • using angle-bracket syntax to invoke components
  • maybe more(?)

Is supporting that kind of semantics change in scope of this RFC? If so, how would I do something like that?

@locks

This comment has been minimized.

Show comment
Hide comment
@locks

locks Apr 3, 2017

Contributor

I have a question on the scope of this RFC. Given the announcements at EmberConf, I sort of assume that the Glimmer/Ember integration can use this RFC as a building block.

That's exactly what this is ;) I think Tom and Yehuda mentioned in the keynote that the more successful experimentations in the Ember ecosystem came by providing primitives from which third-parties can build on, namely fastboot and engines.

This RFC is the primitive that will unlock the possibility of using different kinds of components, one of them is angle bracket components, whose details you mention will likely be discussed in a follow-up RFC. You will notice that Glimmer.js components are very barebones at the moment, partially due to this.

Contributor

locks commented Apr 3, 2017

I have a question on the scope of this RFC. Given the announcements at EmberConf, I sort of assume that the Glimmer/Ember integration can use this RFC as a building block.

That's exactly what this is ;) I think Tom and Yehuda mentioned in the keynote that the more successful experimentations in the Ember ecosystem came by providing primitives from which third-parties can build on, namely fastboot and engines.

This RFC is the primitive that will unlock the possibility of using different kinds of components, one of them is angle bracket components, whose details you mention will likely be discussed in a follow-up RFC. You will notice that Glimmer.js components are very barebones at the moment, partially due to this.

@NLincoln

This comment has been minimized.

Show comment
Hide comment
@NLincoln

NLincoln Apr 3, 2017

Would it be out of scope for this RFC to support changes to how components are rendered?

For example, say I have a google maps component that works like this:

{{#google-map as |map|}}
  {{#map.marker as |marker|}}
    {{#marker.info-window}}
      This is rendered in the markers info window
    {{/marker.info-window}}
  {{/map.marker}}
{{/google-map}}

Currently the info window content is rendered into the DOM, and then google maps moves the element into its own internal structure. elements for markers, etc are also rendered. It would be amazing if there was a way to control how the element is inserted into the DOM, possibly like this?

class MapsComponentManager {
  render(/* dom, element: HTMLElement */) {
    // no-op since we don't want these rendered
  }
}

// components/google-map/info-window.js
Ember.Component.extend({
  didInsertElement() {
    this._super(...arguments);
    // despite the component not being directly rendered, it's element 
    // is still available as a property on the component itself as usual
    assert(this.element);
  }
});

The render api could also be exposed on components instead of component managers instead.

NLincoln commented Apr 3, 2017

Would it be out of scope for this RFC to support changes to how components are rendered?

For example, say I have a google maps component that works like this:

{{#google-map as |map|}}
  {{#map.marker as |marker|}}
    {{#marker.info-window}}
      This is rendered in the markers info window
    {{/marker.info-window}}
  {{/map.marker}}
{{/google-map}}

Currently the info window content is rendered into the DOM, and then google maps moves the element into its own internal structure. elements for markers, etc are also rendered. It would be amazing if there was a way to control how the element is inserted into the DOM, possibly like this?

class MapsComponentManager {
  render(/* dom, element: HTMLElement */) {
    // no-op since we don't want these rendered
  }
}

// components/google-map/info-window.js
Ember.Component.extend({
  didInsertElement() {
    this._super(...arguments);
    // despite the component not being directly rendered, it's element 
    // is still available as a property on the component itself as usual
    assert(this.element);
  }
});

The render api could also be exposed on components instead of component managers instead.

@MiguelMadero

This comment has been minimized.

Show comment
Hide comment
@MiguelMadero

MiguelMadero Apr 3, 2017

@chancancode this looks super useful and I like the idea of providing the primitives and to allow experimentation outside of ember core. However, while in this case, I think the primitives look right, is only once we start building on top of those that we realize if they work or not. I think we may need some time to experiment with this a throw a few different use cases to them before solidifying this or "committing" to an API. I'm mainly thinking of my use case for ember-cli-hot-loader, but I think the same would apply to liquid-fire and angle brackets...
What do you think?

How could we get a "POC" of this or something on the alpha channel to start playing? Is there something we could help with?

MiguelMadero commented Apr 3, 2017

@chancancode this looks super useful and I like the idea of providing the primitives and to allow experimentation outside of ember core. However, while in this case, I think the primitives look right, is only once we start building on top of those that we realize if they work or not. I think we may need some time to experiment with this a throw a few different use cases to them before solidifying this or "committing" to an API. I'm mainly thinking of my use case for ember-cli-hot-loader, but I think the same would apply to liquid-fire and angle brackets...
What do you think?

How could we get a "POC" of this or something on the alpha channel to start playing? Is there something we could help with?

@twokul

This comment has been minimized.

Show comment
Hide comment
@twokul

twokul May 23, 2017

Member

First pass on registering custom component manager landed in Ember (emberjs/ember.js#15254) and allows one to do the following:

{{use-component-manager "nyan-cat"}}

{{nyan-cat}}

where {{nyan-cat}} component management (parsing arguments, (re)rendering, destruction) is going to be deferred to nyan-cat component manager. This should work both for classic and module unification layouts resolvable under component-managers/nyan-cat.

Member

twokul commented May 23, 2017

First pass on registering custom component manager landed in Ember (emberjs/ember.js#15254) and allows one to do the following:

{{use-component-manager "nyan-cat"}}

{{nyan-cat}}

where {{nyan-cat}} component management (parsing arguments, (re)rendering, destruction) is going to be deferred to nyan-cat component manager. This should work both for classic and module unification layouts resolvable under component-managers/nyan-cat.

@knownasilya

This comment has been minimized.

Show comment
Hide comment
@knownasilya

knownasilya May 23, 2017

Contributor

Is there a glimmer component manager yet?

Contributor

knownasilya commented May 23, 2017

Is there a glimmer component manager yet?

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue
Member

rwjblue commented May 23, 2017

Yes

@knownasilya

This comment has been minimized.

Show comment
Hide comment
@knownasilya

knownasilya May 23, 2017

Contributor

I'm assuming this has to be imported manually to work, and isn't included in ember yet.

Contributor

knownasilya commented May 23, 2017

I'm assuming this has to be imported manually to work, and isn't included in ember yet.

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue May 23, 2017

Member

Yep, the only thing landed in ember (behind a feature flag that is disabled by default) is the ability to specify a custom manager.

Member

rwjblue commented May 23, 2017

Yep, the only thing landed in ember (behind a feature flag that is disabled by default) is the ability to specify a custom manager.

@knownasilya

This comment has been minimized.

Show comment
Hide comment
@knownasilya

knownasilya May 23, 2017

Contributor

Great 👍 So you can also use curly components in a glimmerjs app?

Contributor

knownasilya commented May 23, 2017

Great 👍 So you can also use curly components in a glimmerjs app?

@mmun mmun added the T-components label Aug 1, 2017

@auvipy

This comment has been minimized.

Show comment
Hide comment
@auvipy

auvipy Sep 13, 2017

sorry for noise, just curious if there is any further development on this?

auvipy commented Sep 13, 2017

sorry for noise, just curious if there is any further development on this?

@twokul

This comment has been minimized.

Show comment
Hide comment
@twokul

twokul Dec 8, 2017

Member

@dbbk yes, currently blocked by emberjs/ember.js#15828. This and this will be the last steps to land this functionality behind a feature flag.

Member

twokul commented Dec 8, 2017

@dbbk yes, currently blocked by emberjs/ember.js#15828. This and this will be the last steps to land this functionality behind a feature flag.

@simonihmig

This comment has been minimized.

Show comment
Hide comment
@simonihmig

simonihmig Dec 8, 2017

Contributor

@twokul your references seem to address the implementation of this RFC, but shouldn't the RFC itself enter FCP/be adopted, at some point? :)

Contributor

simonihmig commented Dec 8, 2017

@twokul your references seem to address the implementation of this RFC, but shouldn't the RFC itself enter FCP/be adopted, at some point? :)

@twokul

This comment has been minimized.

Show comment
Hide comment
@twokul

twokul Dec 8, 2017

Member

@simonihmig on that, Good Sir, I have no intel :P

Member

twokul commented Dec 8, 2017

@simonihmig on that, Good Sir, I have no intel :P

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Dec 10, 2017

Member

We are actively working through a few prerequisites to this RFC during the core team face to face meeting this weekend. There will be some updates here to cleanup verbiage, address unanswered questions, and add additional required capabilities in the next couple of weeks.

Member

rwjblue commented Dec 10, 2017

We are actively working through a few prerequisites to this RFC during the core team face to face meeting this weekend. There will be some updates here to cleanup verbiage, address unanswered questions, and add additional required capabilities in the next couple of weeks.

@tomdale tomdale referenced this pull request Feb 28, 2018

Open

[QUEST] Glimmer Components in Ember #16301

2 of 57 tasks complete
@chancancode

This comment has been minimized.

Show comment
Hide comment
@chancancode

chancancode Mar 5, 2018

Member

Hello everyone! Sorry for the delay. We had some new breakthroughs at the December core team face-to-face meeting. I updated the RFC to reflect the new development and this should be ready for another round of review, and hopefully FCP soon.

CHANGELOG:

✂️ typescript
✂️ component definitions
✂️ other overly abstract stuff
✂️ ember inspector stuff (seems like we can just do it automatically)
✂️ open/unresolved questions
✔️ #embraceTheObjectModel
added nwe typos

You can read the current version here. The previous version is still available here, for reference.

Member

chancancode commented Mar 5, 2018

Hello everyone! Sorry for the delay. We had some new breakthroughs at the December core team face-to-face meeting. I updated the RFC to reflect the new development and this should be ready for another round of review, and hopefully FCP soon.

CHANGELOG:

✂️ typescript
✂️ component definitions
✂️ other overly abstract stuff
✂️ ember inspector stuff (seems like we can just do it automatically)
✂️ open/unresolved questions
✔️ #embraceTheObjectModel
added nwe typos

You can read the current version here. The previous version is still available here, for reference.

@rwjblue

I love the update! Thanks for putting so much time into it!

I left a number of inline comments / questions, but I had additional question that didn't really fit in a specific section:

  • In the Capabilities section, we describe a future where these capabilities can and will be iterated, but do not mention how that iteration will happen. Is it safe to assume any changes (new capabilities, optional flags, etc) will be made via this same RFC process? How will these capabilities be discoverable? API docs only? Do we anticipate guides?
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
Show outdated Hide outdated text/0000-custom-components.md
do not expect the guides need to be updated for this feature (at least not the
components section).
For documentation purposes, each Ember.js release will only document the latest

This comment has been minimized.

@rwjblue

rwjblue Mar 6, 2018

Member

I don't think this is good enough. We need to maintain a canonical list of capabilities that are supported (and any options that were allowed with each).

@rwjblue

rwjblue Mar 6, 2018

Member

I don't think this is good enough. We need to maintain a canonical list of capabilities that are supported (and any options that were allowed with each).

@chancancode

This comment has been minimized.

Show comment
Hide comment
@chancancode

chancancode Mar 9, 2018

Member

I think I have addressed all the feedback so far!

Member

chancancode commented Mar 9, 2018

I think I have addressed all the feedback so far!

smfoote added a commit to smfoote/ember-rfc176-data that referenced this pull request Mar 9, 2018

@chancancode

This comment has been minimized.

Show comment
Hide comment
@chancancode

chancancode Mar 9, 2018

Member

I updated the RFC to add some details about the support policy of component manager APIs

Member

chancancode commented Mar 9, 2018

I updated the RFC to add some details about the support policy of component manager APIs

@rwjblue

This comment has been minimized.

Show comment
Hide comment
@rwjblue

rwjblue Mar 9, 2018

Member

This was discussed in todays core team call, and with the last round of updates we are happy to get this moved into final comment period.

Please take a 🆕 👀 .....

Member

rwjblue commented Mar 9, 2018

This was discussed in todays core team call, and with the last round of updates we are happy to get this moved into final comment period.

Please take a 🆕 👀 .....

@chancancode

This comment has been minimized.

Show comment
Hide comment
@chancancode

chancancode Mar 9, 2018

Member

I would like to point out that this is not intended to be the ultimate API that solves every use case. Rather, this is the MVP of the framework that allows adding extensions that would solve those use cases. So I would appreciate feedback to focus on whether that framework is flexible enough to eventually support the use case you have in mind, rather than whether it is sufficient to support that today as proposed.

Member

chancancode commented Mar 9, 2018

I would like to point out that this is not intended to be the ultimate API that solves every use case. Rather, this is the MVP of the framework that allows adding extensions that would solve those use cases. So I would appreciate feedback to focus on whether that framework is flexible enough to eventually support the use case you have in mind, rather than whether it is sufficient to support that today as proposed.

@runspired

This comment has been minimized.

Show comment
Hide comment
@runspired

runspired Mar 9, 2018

Contributor

I think to avoid confusion we should remove the theoretical flexi-sustain implementation from the RFC as its not an adequate implementation.

I chatted with @chancancode a bit this morning about the current state of this RFC and have no objections to it; however, I do want to document that while it hopes to be a primitive upon which things such as flexi-sustain could be built, additional RFCs would be needed on top of this MVP.

Contributor

runspired commented Mar 9, 2018

I think to avoid confusion we should remove the theoretical flexi-sustain implementation from the RFC as its not an adequate implementation.

I chatted with @chancancode a bit this morning about the current state of this RFC and have no objections to it; however, I do want to document that while it hopes to be a primitive upon which things such as flexi-sustain could be built, additional RFCs would be needed on top of this MVP.

@chancancode

This comment has been minimized.

Show comment
Hide comment
@chancancode

chancancode Mar 9, 2018

Member

I updated it to remove the mention

Member

chancancode commented Mar 9, 2018

I updated it to remove the mention

@rwwagner90

This comment has been minimized.

Show comment
Hide comment
@rwwagner90

rwwagner90 Mar 10, 2018

Member

I'd love to see some support for flexi-sustain and similiar things, but I realize it might be out of scope here.

Member

rwwagner90 commented Mar 10, 2018

I'd love to see some support for flexi-sustain and similiar things, but I realize it might be out of scope here.

@wycats

This comment has been minimized.

Show comment
Hide comment
@wycats

wycats Mar 21, 2018

Member

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

Member

wycats commented Mar 21, 2018

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

@wycats wycats merged commit c7c3332 into master Mar 21, 2018

1 check passed

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

@chancancode chancancode deleted the custom-components branch Mar 21, 2018

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment