-
-
Notifications
You must be signed in to change notification settings - Fork 4.2k
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
Internals should prefer generic array methods over prototype_extensions #10899
Conversation
8699d36
to
34fa990
Compare
|
||
export function removeAt(content, idx, length = 1) { | ||
if (content.removeAt) { return content.removeAt(idx, length); } | ||
return content.splice(idx, length); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
what sends the event here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ah good catch. this needs to use the replace helper
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
cc @thoov
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Taking a look at this
So, this doesn't quite address the issue of Ember.A() and MutableArray replace The standalone method of Ember.replace() should fire the event on a plain array like Ember.set() would do on an object. |
94e34e6
to
a435f5a
Compare
7f8db9e
to
7758c79
Compare
a9eaee5
to
61680ca
Compare
Just catching up to speed on this one. Looking good so far! @stefanpenner - Is this still on your radar? Is there any way to chunk this up (to avoid forever horrible rebase land of large PR's)? I'm mostly wondering if we can land what you have here and open a meta issue to continue... |
yup
its kinda tricky, but possible. But i'll deal with the rebases and cleanup as when i start on this again. Lets leave this open so i don't forget. |
Sounds good, just was doing a bit of PR triage/cleanup over the weekend.. |
thanks |
Do not use prototype extension for `objectAt`. Related to #9269 and based on the work of @stefanpenner in #10899. If this is acceptable, will continue addressing one extension at a time for quicker merging. (cherry picked from commit cd0d186)
@stefanpenner is this PR inactive? Is the a path forward to continue this effort aside from this branch? |
@stefanpenner is this still active? Has it been superseded somehow? |
@Serabe it hasn't been superseded, and would love a champion |
@stefanpenner I might have time, so we can chat about it. |
Closing this in favor of using an Epic #15501 Thank you! |
objectAt
replace
remoteAt
insertAt
The goal here is merely to decouple the internals from the the observable based prototype extensions.
This will hopefully give us the flexibility to make a future call re: prototype extensions in general. This also eases the pain of using ember with prototype extensions disabled.
All this is accomplished without breaking semver in anyway.
More todo: