Created a video synchronization platform with javascript! I would love feedback!
14 comments · 81% upvoted · source · other discussions
14 comments · 81% upvoted · source · other discussions
Cool, I'm definitely going to check out your code. I have something kinda similar that I have been using as an exploratory project for a bunch of different libraries/frameworks (Elm, Phoenix, Node, React, etc) if you want to check it out! https://github.com/rawhat/playlistr Hopefully we can learn some stuff from each other :)
edit: also, my code is like, super experimental and/or I didn't know shit about the stuff I was working with until I started using it. Sad preface to this, but hey, it's all for fun!
Maybe use classes, interfaces and some inheritance to get rid of all the repeated switch statements? Polymorphism is a good thing. Also unit tests.
kyle8998 [OP] 1 points · Jun 2018
Thanks for the suggestion! I definitely need to clean up my code, I don't like the switch statements everywhere either haha.
Also unit tests are on my to-do list. I can't get by just manually testing anymore!
[deleted] 2 points · Jun 2018
I always wait too long to start adding tests and regret it; it's a hard discipline to adhere to. I guess that's why in true TDD you're supposed to write the test before you write the code :)
monsto 1 points · Jun 2018
I know this is a zombie post, but it's been bugging me since I first read this...
In this context, how would he replace those switches with prototypes? I mean at some point he still has to choose the player.
I understand prototyping (and classes) and inheritance, generally speaking, but I don't get what kind of organization are you advocating here?
[deleted] 1 points · Jun 2018
Sure, you'd need to choose a player type at some point, but then just pass that type around. In C# you'd just use an interface or abstract base class, all of your derived types would have the same methods as what you inherit from, and then you pass the interface or abstract around or use dependency injection. In JavaScript I guess you would just pass the object itself (compose it when you make the decision.) That way you wouldn't be having to figure out what type of player you have every time you call a method/perform an action.
[deleted] 1 points · Jun 2018
class Player { constructor(url) { this.url = url; } }
class Youtube extends Player { play() { console.log("Youtube is playing:" + this.url); } }
class Vimeo extends Player { play() { console.log("Vimeo is playing." + this.url); } }
function somemethod(player) { player.play(); }
let myPlayer; let playerChoice = 'youtube';
if (playerChoice === 'youtube') myPlayer = new Youtube('someurl'); else myPlayer = new Vimeo('someurl');
somemethod(myPlayer);
Run this in node:
node player.js
Youtube is playing:someurl
TheInfestation -3 points · Jun 2018
No, god, why, no don't do this.
[deleted] 1 points · Jun 2018
I'll bite - why not?
[deleted] -6 points · Jun 2018
Don't be the guy who uses polymorphism in everything just because he learned about it from a book yesterday.
[deleted] 5 points · Jun 2018
How about as a very simple means to remove all that duplicated code? Have a player 'class' and extend it for each instance (youtube, vimeo, etc.) Now you don't need switch statements everywhere. Since when is reading a book or using a concept a bad thing?
Maxincredible52 1 points · Jun 2018
composition over inheritance
[deleted] 1 points · Jun 2018
Yeah that would be more in the spirit of FP. I guess you would probably decide using is-a and has-a. Which actually in this case sounds more like a need for inheritance.
steeleb88 1 points · Jun 2018
they're annoying af