[Proposal] enable debug logs as soon as __RX_PLAYER_DEBUG_MODE__ is set
#1626
+37
−30
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Today the `RX_PLAYER_DEBUG_MODE__` global boolean only enable debug logs
if it is set **BEFORE** the RxPlayer files are evaluated / initially
executed.
This is difficult to explain to people not used to that kind of tricks.
In this commit, I propose to perform an ugly `Object.defineProperty`
trick on the global scope (`window` / `globalThis`) so we enable debug
mode even if the RxPlayer was already imported.
This way:
1. any application running with the RxPlayer could just at any time
set something like `window.RX_PLAYER_DEBUG_MODE__ = true` in the
console to obtain debug logs
2. [RxPaired](https://github.com/canalplus/RxPaired/)'s client script
could be included in the console at any time without asking users
to pass as argument the RxPlayer class if it's done at runtime.
This can be seen as hacky and unusual, we would also mess ourselves
with global scope which we usually don't like to do as a library.
However reserving the `__RX_PLAYER_DEBUG_MODE__` global property and
reacting on it still doesn't seems outlandish to me.
---
Note that executing two times the RxPlayer files will make only the
last one react to that property. I think this is not an issue because
applications should never execute two times the same RxPlayer file in
a given JavaScript realm (if it does, they rely on a bundler or
user-agent not respecting ECMAScript's specification regarding
module evaluation, so it's OK IMO to not support that case).
peaBerberian
force-pushed
the
misc/listen-to-debug-mode
branch
from
17fb6af to
fb3df48
Compare
peaBerberian
changed the title
__RX_PLAYER_DEBUG_MODE____RX_PLAYER_DEBUG_MODE__ is set
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Today the
RX_PLAYER_DEBUG_MODE__global boolean only enable debug logs if it is set BEFORE the RxPlayer files are evaluated / initially executed.This is difficult to explain to people not used to that kind of tricks.
In this commit, I propose to perform an ugly
Object.definePropertytrick on the global scope (window/globalThis) so we enable debug mode even if the RxPlayer was already imported.This way:
any application running with the RxPlayer could just at any time set something like
window.RX_PLAYER_DEBUG_MODE__ = truein the console to obtain debug logsRxPaired's client script could be included in the console at any time without asking users to pass as argument the RxPlayer class if it's done at runtime.
This can be seen as hacky and unusual, we would also mess ourselves with global scope which we usually don't like to do as a library.
However reserving the
__RX_PLAYER_DEBUG_MODE__global property and reacting on it still doesn't seems outlandish to me.Note that executing two times the RxPlayer files will make only the last one react to that property. I think this is not an issue because applications should never execute two times the same RxPlayer file in a given JavaScript realm (if it does, they rely on a bundler or user-agent not respecting ECMAScript's specification regarding module evaluation, so it's OK IMO to not support that case).