-
-
Notifications
You must be signed in to change notification settings - Fork 408
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
Tracked Maps and Sets #577
Conversation
I'd prefer this to be in a separate package rather than part of |
tree shaking can work on multiple imports of the same package |
I am unaware of how this works. Right now we can only do "manual tree shaking" in ember-cli; i.e. not load a package. While Embroider may change this someday, we must work with what we have now. Once Ember core is property separated into real separate packages, with today's ember-cli we will be able to only load or not load the entire package. |
This would not be implemented as a separate package either way, so manual treeshaking would not be possible. We should build for automatic treeshaking. |
Sorry, why not? It is in a separate addon now. |
|
Yes. I would like this to be separate from |
@Gaurav0 I think we have too many imports as is. |
@NullVoxPopuli Why? The imports went through the RFC process and were agreed to by the community. |
@Gaurav0 I just mean that I feel like we have too many imports as is -- not that there is anything we can do about it -- all the imports make sense. |
@Gaurav0 for pragmatic purposes, this would not be implemented as a separate addon for the time being, which is my overall point. |
IMHO, I disagree. The The only additional thing I think should be added to the |
EDIT: Seems like I have misunderstood the role of proxies here. I still think support for IE 11 should be dropped, but that isn't relevant to this discussion. I'm very much in favour of this RFC! PREVIOUS COMMENT: Good suggestion, I really like this idea! However, I think designing something proxy-based would be much better and browser support is excellent. Let's come up with something modern, with longer shelf-life. IE 11 is in rapid decline and only have a few percentage points of usage these days. Many large software companies has already stopped supporting it, for example:
The days where IE11 was the only browser installed on a computer are long gone. Ember should drop IE 11 support and focus time on using the modern JS toolset to provide a nice framework. Any Ember user that need to extend support a while longer, e.g. end of 2020, could simply linger on an Ember LTS a while longer. It doesn't need to hold back new framework development. Regarding the performance drawback with proxies, I don't think it would be a big problem under most real-world scenarios. |
@sandstrom these classes do not require a proxy to wrap transparently, since all access is done through methods, unlike arrays. Ultimately, the exact implementation should likely be whatever is most performant, and whether or not that is a subclass or a proxy should be an implementation detail. |
Would these tracked classes be iterable by {{#each ...}} in a template or would that require wrapping in a Proxy (and dropping IE11 support)? If yes, can we expose the underlying mechanism so that libraries like EmberData can provide custom iterables without the Proxy wrapper requirement? |
A proxy is not necessary for this either way, and they should be iterable as is.
Yes, but I believe that should be a separate RFC specifically dedicated to outlining our support of native iterables. I also think that, because native iterables rely on Symbol, we will still need to wait for IE11 support to be fully dropped before we can deprecate alternatives to native iterables, but we can introduce support immediately in the meantime. |
IE11 is now dropped, so what's left for this RFC? |
I believe this should be closed with the same rationale as #569 (comment). If I'm mistaken, please let me know and we can work to get this moving again. |
Rendered