Sorry no, you’ve done far too much and most of it is wrong.
Can you please just do the simple small thing that has been asked of you, which is to move the addEventListener to the init function. Nothing more.
You will get an console error saying: “Uncaught ReferenceError: body is not defined”
That is when you place a copy of the body variable in the init function.
There are a few other good ways to deal with that.
One way is to add a body variable to the init function. That does though result in us having a body variable in two places, one in resetPage, and one in init. That doesn’t become a problem until we have three such duplicates in the one module. If that occurs we can then move one of them up to a higher level, such as to the top of the module, and use that single body variable from all other places instead.
Another way to solve that is to use a technique called “inline the variable” where the body variable is removed and we instead use what it refers to instead in the code, that being document.body.
However, none of that needs to be solved right now. It’s perfectly good and okay to have two body variables in different places, especially when there’s no good way for one of them to refer to the other. It’s when three-such examples occur though that concern is merited.
After doing that we get a new error message: “Uncaught ReferenceError: onAnimationEnd is not defined”
The onAnimationEnd variable isn’t doing anything useful. We already know that it’s for the animationend event, and it’s just acting as an indirect pass-through to the fadeResetHandler function. Here we get rid of that indirection, and just use fadeResetHandler instead of onAnimationEnd.
The init function is now happy, and there is some cleaning up to do, but the bulk of the work is done.
There are I think two main reasons why the code is not functioning. One of them is that your code is still removing the event listener. The update we made to the code is so that only one event listener is needed which means not removing it.
A second reason for trouble is that the fadeResetHandler is triggered on all types of animations that occur, and only one of them is the one that we want to use. The only animation that we want to reset the page on is when the fadingOut animation is being used. There is a problem though, and that is that the fadingOut animation is used when starting a video too. That means that the animationend event is not the correct technique to use. There is instead a much simpler solution that solves all of those problems.
However, first to the cleanup, where the removeeventlistener code is removed, helping to solve one of the issues.
Well let’s see what currently happens in the code to cause the code in the handler to run.
resetPage ads a classname of fadingOut to the body
the animationend event triggers
the code in fadeResetHandler is run
Does fadingOut cause any CSS to occur? Yes it does. We can’t remove that.
Can the fadeResetHandler code be run without needing to wait for the event? No it can’t, for it must wait until the end of the animation.
I’ve added a little bit of code at the top of the fadeResetHandler code, to let me see the animationName when the animationend event triggers.
const name = evt.animationName;
There are several animation events that end up triggering the animationend event.
It’s only the fadingOut animation that we want the code to run on, so a guard clause can be handy there. If it’s not fadingOut then we return immediately out of the function.
It’s a guard clause that protects the rest of the code in its area, so it gets placed as early as possible in the code.
There is one last problem and that is the body variable. The evt.target property does not refer to the body element. What does work is using document.body.
However, that is the third time we’ve used document.body in the same area (within the manageUI code), so really reduce that duplication by moving those body variables to a single body variable at the top of the manageUI code instead.