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.

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

Consider rename of normalizeOptions into toPlainObject #57

Open
medikoo opened this issue Feb 23, 2017 · 0 comments
Open

Consider rename of normalizeOptions into toPlainObject #57

medikoo opened this issue Feb 23, 2017 · 0 comments
Assignees

Comments

@medikoo
Copy link
Owner

medikoo commented Feb 23, 2017

  1. normalizeOptions when created, it was assumed that probably it doesn't address any other case as normalizing input options. However now there are few cases when it's used not specifically for that.
  2. It's technically about copying and unifing many objects also across their prototype chain, into one plain object.

One controversy is that we have to* functions which in case of input matching the output, return it directly (and not its copy), while here (at least in case of options normalization) we're always after copy.
Maybe we should have both toPlainObject and normalizeOptions where latter will just ensure we have the copy. Or maybe we should make all to* functions return a copy.

Additional note: both toPlainObject and normalizeOptions should copy only enumerable properties. On one side it's controversial as on not transformed options object non-emurable properties remain visible and can be read normally as an options, while after transformation it's not the case. So it makes technically both options objects not equivalent.
Still non-enumerable properties, if any (unlikely case) in most cases will be meta properties (e.g. containers for listeners of event emitter, or container of weak map polyfill), copying those opens door to some very hard to track bugs.


Extra notes:

  1. Let's make it one argument taking, as in use cases we have it's only one object we need to copy deep the prototype chain. So multi args handling can be solved as:
Object.assign({}, defaultOptions, toPlainObject(inputOptions));
  1. Support propertyKeys (or only) option, where list of names (including symbols) can be passed and in such case only those properties are copied. Additionally they should be copied even if they're not enumerable
@medikoo medikoo self-assigned this Feb 23, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant