Skip to content
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

Merged
merged 7 commits into from
Nov 7, 2024
Merged

Conversation

myovchev
Copy link
Contributor

@myovchev myovchev commented Nov 1, 2024

Summary

  • Widget players are now properly invoked when they arrive later in the page load process.
  • It's possible now to target the HMR build when registering via template.append and template.prepend. Use when: 'hmr:public' or when: 'hmr:apos' that will be evaluated against the current asset options.hmr configuration.

What are the specific steps to test this change?

Players should always run during the initial page load.

The following injection:

self.apos.template.prepend({
  where: 'head',
  when: 'hmr:public',
  bundler: 'vite',
  component: 'vite-react:reactRefresh'
});

should inject the component only when HMR is on and the asset module option hmr is set to public. The generic when: 'hmr' still works as expected.

What kind of change does this PR introduce?

(Check at least one)

  • Bug fix
  • New feature
  • Refactor
  • Documentation
  • Build-related changes
  • Other

Make sure the PR fulfills these requirements:

  • It includes a) the existing issue ID being resolved, b) a convincing reason for adding this feature, or c) a clear description of the bug it resolves
  • The changelog is updated
  • Related documentation has been updated
  • Related tests have been updated

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:

@myovchev myovchev requested a review from boutell November 1, 2024 20:12
target[prop] = value;
// run the player if we missed the initial run
if (widgetPlayersConfig.initialized) {
apos.util.runPlayers(document, { [prop]: value });
Copy link
Member

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.

Copy link
Contributor Author

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

Copy link
Contributor Author

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) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should be newPlayers

Copy link
Member

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

Copy link
Contributor Author

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.

Copy link
Contributor Author

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".

Copy link
Contributor Author

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.

@myovchev myovchev requested a review from boutell November 6, 2024 11:36
@myovchev myovchev requested a review from boutell November 6, 2024 14:12
@myovchev myovchev merged commit 46dea7d into main Nov 7, 2024
9 checks passed
@myovchev myovchev deleted the fix-players-and-when branch November 7, 2024 08:15
haroun added a commit that referenced this pull request Nov 11, 2024
* 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)
haroun added a commit that referenced this pull request Nov 12, 2024
* 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)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants