-
-
Notifications
You must be signed in to change notification settings - Fork 141
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
RFC: Use es6 proxy #245
Comments
That would be nice, my only question is what do we do about IE11? |
could this be something where we could base it off of the Proxy object, but fall back to a polyfill like https://github.com/GoogleChrome/proxy-polyfill |
This is great 🙂 I think we could continue the bug-fixing efforts with nested keys and get a release out, then focus on integrating validated-proxy? It'll be easier since we'll already have defined nested keys behavior. |
This isn't a mandate by any means, I'm using |
Having looked through validated-proxy a bit more, I think it’d be interesting to explore use cases. An obvious one is using validated-proxy with Redux, where you’d emit actions only when data is valid. Since we’re not coupled to Ember anymore, maybe an Express middleware for validated-proxy would be useful too. I’m curious what people have used Ecto.Changeset for, since all those use cases would apply here. As an aside, one of my goals is to capture UI use cases in ember-changeset’s wiki going forward. Implementation-wise, I’m all for having ember-changeset consume validated-proxy. We’d still need some Ember-specific stuff like relays, but it’d definitely clean up the code. Not to mention the TypeScript typings look really nice. |
This sounds awesome! Would this help with the issues around 'deep set'? Proxy seems to have great browser support :https://caniuse.com/#search=proxy IE 11 is quickly on its way out: Something "opt-in" that people with min browser requirements > IE 11 could use would be lovely 😄 |
Didn't have time to write up an actual RFC. Here's a quick proof of concept where we are just naively trapping
proxy.set
to validate prior to setting the value on the target object.If we go down this route, we should implement that as a separate JS library and then have this addon consume that.
The text was updated successfully, but these errors were encountered: