-
Notifications
You must be signed in to change notification settings - Fork 596
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
HMR condition argument and widget player fix #4794
Conversation
target[prop] = value; | ||
// run the player if we missed the initial run | ||
if (widgetPlayersConfig.initialized) { | ||
apos.util.runPlayers(document, { [prop]: value }); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
runPlayers doesn't take a second argument. It sounds like you're suggesting one unofficially but I'd rather we not have this bite us later if we add one without looking at this. The lack of specificity won't hurt because elements already played won't get played again.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is a guard against attempting all players again. The internal player guard is not working well in many cases. We also need to look at the refresh calls in the Context Vue component someday, it causes some of the issues I observe @boutell
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
See apos.util.runPlayers = function (el, newPlayer) {
. We end up with players being called back to back and breaking a lot of stuff. Again, now we have a lot more room for racing conditions and it bites us (mostly in edit mode, when we have also ajax dom updates from what it seems and manipulate the dom while players are attempting to run).
@@ -184,24 +197,24 @@ export default () => { | |||
// DON'T try to find all the widgets. DO just enhance `el`. | |||
// This is a computer science principle known as "separation of concerns." | |||
|
|||
apos.util.runPlayers = function(el) { | |||
const players = apos.util.widgetPlayers; | |||
apos.util.runPlayers = function (el, newPlayer) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should be newPlayers
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I still think we're fighting ghosts here, the real problem is players that replace the element completely, which we should document you should not do because it prevents tracking if players have been run (or your player must check that on its own if it insists on replacing the element)
But fine with this optimization if we name the parameter better
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I tested on players that are not replacing the element, but mounting (inserting child nodes). The player guard itself is mostly not working because the rapid event fire and DOM changes racing conditions. I spent a good amount of time debugging the whole. I think with this change, players are doing good on itself, eliminating the same tick executions during initialization. The next thing we might want to insect someday is the Vue context component refresh
calls, that in some cases are spamming the refresh event - it should be probably better computed and/or slightly throttled.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I came up with a better strategy I think. I like it more because it gives no "freedom" to pass any player outside of already registered, but still does improve the performance and guards against "player spamming".
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Did some more testing and debugging... and reverted the whole new players thing. The performance gain is questionable, we need a more clear strategy for improvement here.
* main: fix vue warnings (#4797) Pro 6694 breakpoint preview vite ready (#4789) Resolve yaml dependency conflicts (#4801) PRO-6775: External frontend support, docs cleanup (#4799) sort glob result (#4796) HMR condition argument and widget player fix (#4794) fix permission grid tooltip display (#4792) Fix extra bundle detection (#4791) release 4.9.0 (#4788) Pro 6535 revision (#4787)
* main: changelog (#4802) fixes modals deep selectors (#4795) fix vue warnings (#4797) Pro 6694 breakpoint preview vite ready (#4789) Resolve yaml dependency conflicts (#4801) PRO-6775: External frontend support, docs cleanup (#4799) sort glob result (#4796) HMR condition argument and widget player fix (#4794) fix permission grid tooltip display (#4792) Fix extra bundle detection (#4791) release 4.9.0 (#4788) Pro 6535 revision (#4787)
Summary
template.append
andtemplate.prepend
. Usewhen: 'hmr:public'
orwhen: 'hmr:apos'
that will be evaluated against the current assetoptions.hmr
configuration.What are the specific steps to test this change?
Players should always run during the initial page load.
The following injection:
should inject the component only when HMR is on and the asset module option
hmr
is set topublic
. The genericwhen: 'hmr'
still works as expected.What kind of change does this PR introduce?
(Check at least one)
Make sure the PR fulfills these requirements:
If adding a new feature without an already open issue, it's best to open a feature request issue first and wait for approval before working on it.
Other information: