You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
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:
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:
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
The text was updated successfully, but these errors were encountered:
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.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
andnormalizeOptions
where latter will just ensure we have the copy. Or maybe we should make allto*
functions return a copy.Additional note: both
toPlainObject
andnormalizeOptions
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:
propertyKeys
(oronly
) 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 enumerableThe text was updated successfully, but these errors were encountered: