-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
chore: Remove state engine #5752
Conversation
So this is still a work in progress. I'll need to do a lot more manual testing to make sure things aren't broken, I need to re-write the JSDoc of a lot of functions so they no longer mentions the state engine, and I'll definitely need to update a lot of tests. |
The state engine mechanism, designed for the player class, was over-engineered. The structure of the class makes debugging player errors unnecessarily annoying, by obfuscating the code-patch the error followed. This changes the player to use an async-await setup for the top-level operations, laying things out much more clearly and linearly.
1268ed1
to
edb3d72
Compare
…er.EXTENSIONS_TO_MIME_TYPES_
Incremental code coverage: 91.12% |
It looks like the tests hang forever, probably because of the new mutexes. Just canceling the workflow for now to avoid wasting time, and I'll look into the tests on my local machine. |
…into noMoStateEngineBranch
d18d5c8
to
0b2fca6
Compare
…into noMoStateEngineBranch
Looks like this was just introduced in #5752
The state engine mechanism, designed for the player class, was over-engineered. The structure of the class makes debugging player errors unnecessarily annoying, by obfuscating the code-path the error followed, and in general has created a significant amount of technical debt. This changes the player to use an async-await setup for the top-level operations, laying things out much more cleanly and linearly. --------- Co-authored-by: Álvaro Velad Galván <ladvan91@hotmail.com>
Looks like this was just introduced in shaka-project#5752
The state engine mechanism, designed for the player class, was over-engineered. The structure of the class makes debugging player errors unnecessarily annoying, by obfuscating the code-path the error followed, and in general
has created a significant amount of technical debt.
This changes the player to use an async-await setup for the top-level operations, laying things out much more cleanly
and linearly.