-
Notifications
You must be signed in to change notification settings - Fork 7.5k
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
Refactor TextTrackSettings #3570
Refactor TextTrackSettings #3570
Conversation
let values; | ||
|
||
try { | ||
[err, values] = safeParseTuple(window.localStorage.getItem('vjs-text-track-settings')); |
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.
I still think it's nice to use safeParseTuple. I think the reason why this is wrapped in a try/catch is to make sure that the call to localStorage doesn't break.
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.
It seems like overkill to have two try
blocks (even if one is hidden in a dependency). This way we only have one.
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.
probably not necessary here but it allows us to more easily differentiate between the two errors.
Also, I wonder if safeJSONparse is used anywhere else.
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.
I don't know that it does allow us to easily differentiate. Either way, you have an Error
object that gets logged to the console. I suppose before it was sometimes logged as an error and sometimes as a warning, but... that doesn't seem like a significant benefit.
It's used in the Player
. I dunno if it's worth including it at all since it's basically just a small wrapper around try
/catch
... but that's for another discussion/PR.
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.
Also, the other benefit of safejsonparse is encapsulation. Yeah, not much help here but I think it does help in general. Supposedly, try/catch don't hurt much anymore in the latest and greatest js engines but older engines still have issues with deoping the entire function.
I guess the other parts of the proposal are still to come? |
Also, maybe make each part a separate PR? |
c8c7bda
to
5c7fa90
Compare
Yeah, this part is going to be focused on DRYness. |
ce4ccba
to
38c83c0
Compare
* A callback function which is called for each key in the object. It | ||
* receives the value and key as arguments. | ||
*/ | ||
export function each(object, fn) { |
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.
how much space would it take to bring in lodash here instead? (could provide some lodash code sharing between projects if it is not a lot more)
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.
I think it'd be a lot more. I'm willing to check to see how much more, but I suspect it's quite a bit (comparatively).
Other than that LGTM |
Doc block is updated. As for adding lodash, we already have lodash-compat in place. Using its methods - |
ok yeah maybe we can revisit it at a later time, when we have a better way to share dependencies between projects |
@@ -352,18 +358,18 @@ class TextTrackSettings extends Component { | |||
const values = this.getValues(); | |||
|
|||
try { | |||
if (Object.getOwnPropertyNames(values).length > 0) { | |||
window.localStorage.setItem('vjs-text-track-settings', JSON.stringify(values)); | |||
if (values) { |
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 remove the check for the size of values?
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.
The default return value for getValues
is an object which is truthy, so, we'll never enter the else
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.
Good catch. That was from some earlier work where getValues()
was not always returning an object.
I don't see any changes that impact a11y. LGTM. (Hoping we get rid of that chunk of HTML for the dialog at some point soon, too ;-) ) |
@OwenEdwards Yep! That's the next PR! |
Fixes videojs#3587. Some commented out css was removed as it is no longer necessary and potentially causes issues.
ISSUE_TEMPLATE and PULL_REQUEST_TEMPLATE were both moved to a .github/ folder to clean up the root of the project a bit. CONTRIBUTING.md was kept at the top level because it is generic enough and contains useful information.
Updates `object.assign` to the latest, and uses a semver range so that consumers can `npm dedupe`.
58c241f
to
f693dd3
Compare
Going to close this and re-open against master when the other branch gets included. |
Description
The
TextTrackSettings
component has a lot of limitations: a large, hard-coded HTML string, repetitive code~~, and does not inherit fromModalDialog
(which would provide accessibility benefits and more)~~.This is the first in a series of 2 PRs. This one is focused on reducing repetitive code and making the component DRYer overall. The second PR will be focused on replacing the large HTML string with DOM generation methods.
And the third PR will be focused on inheriting fromModalDialog
instead ofComponent
.Update: I think that inheriting from
ModalDialog
would be ideal, but it would also mean too much backward-incompatibility (and too much workaround code to achieve backward-compatibility). Let's reserve that for 6.0.Requirements Checklist