It can help to get some visibility on the issue. Just before the managePlayer.init line add a new line that says debugger;
With the browser console open, run the code, and the debugger should open in the console. You can then click on line numbers to set breakpoints. I find it useful to set breakpoints at the start of functions, so I can see what happening there. In this case, breakpoints at the start of the init function, the addPlayer functions, the createCoverClickHandler function, and the createPlayer function are good places.
Then when you press the ResumeScriptExecution button code execution should stop at the start of the init function. This is where a second useful thing can be done, which is to watch a variable. In this case we want to add a watch to the playerOptions variable, so that we can easily see what happens to it.
After addng a watch for the playerOptions variable, I also unfurl it, so that all parts of playerOptions are easily visible in the watch area. I can then resume script execution.
When scrit execution pauses at the next breakpoint in the addPlayerRandomVideo function, I find that settings
was used in there instead of playerOptions. Letās rename that to playerOptions right now in both of the addPlayer functions.
On running the code again we donāt need that debugger statement thanks to the breakpoints we have in the code, so remove that debugger statement from earlier and run the code again.
The debugger pauses the script at the start of the init function, and we see in the watch area that playerVars has controls and fs properties. We can then press the step over next function call
so that playerOptions is added to defaults, and we can hover over that defaults variable to investigate it.
There we find a problem. The defaults object inappropriately has a playerOptions object inside of it. We resolved this earlier by reducing that to be just a defaultOptions object, so letās restructure that now. In the jsFiddle JS code pane update the defaults code structure so defaults and playerOptions are combined to be just defaultOptions, and defaults elsewhere lower in the code is renamed to be defaultOptions, and we can run the code again.
On running the code again the breakpoints are in different places. They are still at the same line numbers, but weāve changed the lines in the code, so we need to update those breakpoints so that they are at the top of the function again. After updating that we can run the code again and step over the object.assign.
On doing that we can hover on the defaultOptions variable and confirm that playerVars has been updated. It hasnāt kept the previous default values that were in there. Object.assign is not the right way to do things when we have nested objects. That is why we have the combinePlayerOptions function instead. So replace Object.assign with using combinePlayerOptions, and use let
instead of const
on playerDefaults so that the init function can update that variable.
Run the code again, the breakpoint stops at the start of the init function. Step over that function call and confirm that defaultOptions is correct, and the process continues from there.