-
-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
init options bug #1761
base: develop
Are you sure you want to change the base?
init options bug #1761
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change | ||
---|---|---|---|---|
@@ -0,0 +1,18 @@ | ||||
export default function(options, defaults) { | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Is this not just merging the two objects? In which case we can just use the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. yep, it is! We have two options with multiple properties the current implementation will break if the initialization is like const player = new Plyr('#player', {
speed: {
selected: 2
}
}); it will break here since the user has not provided the options Line 1057 in 39558cb
the above code just makes sure that incorrect options don't break the code, it wasn't breaking previously since we were overriding user's config |
||||
if (!options) { | ||||
return defaults; | ||||
} | ||||
|
||||
const normalizedOptions = {}; | ||||
|
||||
Object.keys(defaults) | ||||
.forEach(key => { | ||||
if (Object.prototype.hasOwnProperty.call(options, key)) { | ||||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Why not use There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more.
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Readability > a probably very minor speed increase. You'll notice the rest of the code we use that style so let's stick with that. It's the sort of thing browsers will optimise anyway. |
||||
normalizedOptions[key] = options[key]; | ||||
} else { | ||||
normalizedOptions[key] = defaults[key]; | ||||
} | ||||
}); | ||||
|
||||
return normalizedOptions; | ||||
} |
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -28,10 +28,7 @@ export function extend(target = {}, ...sources) { | |
|
||
Object.keys(source).forEach(key => { | ||
if (is.object(source[key])) { | ||
if (!Object.keys(target).includes(key)) { | ||
Object.assign(target, { [key]: {} }); | ||
} | ||
|
||
Comment on lines
-31
to
-34
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. What's the reason behind this change? You could potentially overwrite an existing value rather than merge. There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I felt like extending an object should extend it unconditionally, rather than checking for the existence of keys in loop There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Did you test it? From looking at it, happens with your change will be that if the i.e. const obj1 = { a: { b: 2, c: 3 }};
const obj2 = { a: { d: 4, e: 5 }};
const obj3 = extend(obj1, obj2); You would expect obj3 to be |
||
Object.assign(target, { [key]: {} }); | ||
extend(target[key], source[key]); | ||
} else { | ||
Object.assign(target, { [key]: source[key] }); | ||
|
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.
Why do we need this as a getter?
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.
my bad we don't need a getter, but the current implementation is unreadable as well, it confuses the editor that the code below this line is not reachable
I guess we can have a method say
parseJSON(jsonString)
to handle thisThere 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.
Yeah, it could just be a util really.