Skip to content
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.

Sign up for GitHub

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

Update on RFC #1

Merged
merged 2 commits into from
Aug 10, 2017
Merged

Update on RFC #1

Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
77f7305
Update on RFC
Serabe Aug 6, 2017
dcadbc1
Fix addon name
Serabe Aug 10, 2017
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 3 additions & 7 deletions text/0000-deprecation-ember-string.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4,7 +4,7 @@

# Summary

This PR proposes the deprecation of `Ember.String`. The following methods will be moved to an addon:
This PR proposes the deprecation of extending `String` with the methods in `Ember.String` and accessing those directly. Furthermore, the following methods will be moved to a new `@ember/string` addon.

- `camelize`
- `capitalize`
Expand All @@ -18,13 +18,11 @@ This PR proposes the deprecation of `Ember.String`. The following methods will b

The remaining methods (`htmlSafe` and `isHTMLSafe`) will be moved to `@ember/component`.

In both cases, the String prototype won't be extended anymore.

# Motivation

`Ember.String` was introduced long ago, even before 1.0 was released. It was a time without the current ecosystem of addons. There were no ES6 modules, no Ember CLI and no Ember addons. Global mode was the way to go and prototypes of classes like `String`, `Array` and `Function` were being extended.

A lot of nice-to-have functionality was added at that time but now Ember is lifting weight. These functions belong in an addon, where it can be maintained and evolve without being tied to the core of the framework.
A lot of nice-to-have functionality was added at that time but now Ember has a better ecosystem. These functions belong in an addon, where it can be maintained and evolve without being tied to the core of the framework.

Also, this would let people swap the function for similar implementations but different behaviour in edge cases.

Expand All @@ -43,8 +41,6 @@ Ember guides' section on _disabling prototype extension_ would need to remove re

Main usage of these functions are in blueprints or connecting to APIs where converting the type of case of keys was needed. It is also used in Ember Data.

Furthermore, when people have moved to the new shims, moving to an addon would be as easy as to change the import path.

For `htmlSafe` and `isHTMLSafe`, the move is easier since the methods are easier related to components than to strings.

In any case, a basic Ember Watson recipe would be easy to provide.
Expand All @@ -53,7 +49,7 @@ In any case, a basic Ember Watson recipe would be easy to provide.

A lot of addons that deal with names depend on this behaviour, so they will need to install the addon. Also, Ember Data and some external serializers require these functions.

`htmlSafe` and `isHTMLSafe` would need to change packages as well, thus the reason to try and provide an Ember Watson recipe.
`htmlSafe` and `isHTMLSafe` would need to change packages, thus the reason to try and provide an Ember Watson recipe.

# Alternatives

Expand Down