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

Refactor TextTrackSettings #3570

Closed

Conversation

misteroneill
Copy link
Member

@misteroneill misteroneill commented Aug 24, 2016

Description

The TextTrackSettings component has a lot of limitations: a large, hard-coded HTML string, repetitive code~~, and does not inherit from ModalDialog (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 from ModalDialog instead of Component.

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

  • Feature implemented / Bug fixed
  • Reviewed by Two Core Contributors

let values;

try {
[err, values] = safeParseTuple(window.localStorage.getItem('vjs-text-track-settings'));
Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

Copy link
Member Author

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.

Copy link
Member

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.

@gkatsev
Copy link
Member

gkatsev commented Aug 24, 2016

I guess the other parts of the proposal are still to come?

@gkatsev
Copy link
Member

gkatsev commented Aug 24, 2016

Also, maybe make each part a separate PR?

@misteroneill
Copy link
Member Author

Yeah, this part is going to be focused on DRYness.

@misteroneill misteroneill changed the base branch from master to refactor-tts-complete August 25, 2016 15:55
* 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) {
Copy link
Contributor

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)

Copy link
Member Author

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).

@misteroneill misteroneill added patch This PR can be added to a patch release. needs: LGTM Needs one or more additional approvals labels Aug 25, 2016
@brandonocasey
Copy link
Contributor

brandonocasey commented Aug 25, 2016

  • need to add a description to the mentioned doc block
  • need to check how much size lodash will add gzipped

Other than that LGTM

@misteroneill
Copy link
Member Author

Doc block is updated.

As for adding lodash, we already have lodash-compat in place. Using its methods - each() and reduce() - adds 2.5kb to the gzipped size. Removing lodash-compat and using lodash 4 instead adds 6.5kb. This is likely because lodash has multiple internal dependencies.

@brandonocasey
Copy link
Contributor

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) {
Copy link
Member

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?

Copy link
Member

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

Copy link
Member Author

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.

@OwenEdwards
Copy link
Member

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 ;-) )

@misteroneill
Copy link
Member Author

@OwenEdwards Yep! That's the next PR!

@gkatsev gkatsev added this to the 5.12 milestone Sep 27, 2016
@misteroneill
Copy link
Member Author

Going to close this and re-open against master when the other branch gets included.

@misteroneill misteroneill deleted the refactor-tts branch October 11, 2016 19:53
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
confirmed patch This PR can be added to a patch release.
Projects
None yet
Development

Successfully merging this pull request may close these issues.