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

fix: make media bindings more robust #12206

Merged
merged 1 commit into from
Jun 28, 2024
Merged

fix: make media bindings more robust #12206

merged 1 commit into from
Jun 28, 2024

Conversation

dummdidumm
Copy link
Member

The media bindings where fragile because the "prevent rerun if update in progress"-logic was flawed: It didn't (re)set the updating flag correctly, because it assumed an event and a render effect would always directly follow each other, with one always being first - but that's not true.
It's much more robust to instead compare the value with what's currently present in the DOM. For the very fast-firing current-time-binding a variable is used to not invoke the DOM getter as much, for the others this is not necessary.
Lastly, the playback-rate-binding contained another bug where the listener was setup inside the effect - turns out we can rework the whole binding a bit now that render effects fire synchronously on first run.

Noticed these bugs while working on the Svelte site, and tested these fixes there.

Before submitting the PR, please make sure you do the following

  • It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
  • Prefix your PR title with feat:, fix:, chore:, or docs:.
  • This message body should clearly illustrate what problems it solves.
  • Ideally, include a test that fails without this PR but passes with it.

Tests and linting

  • Run the tests with pnpm test and lint the project with pnpm lint

The media bindings where fragile because the "prevent rerun if update in progress"-logic was flawed: It didn't (re)set the `updating` flag correctly, because it assumed an event and a render effect would always directly follow each other, with one always being first - but that's not true.
It's much more robust to instead compare the value with what's currently present in the DOM. For the very fast-firing current-time-binding a variable is used to not invoke the DOM getter as much, for the others this is not necessary.
Lastly, the playback-rate-binding contained another bug where the listener was setup inside the effect and therefore reinitialized on each binding change - it needs to move into a different effect.
Copy link

changeset-bot bot commented Jun 27, 2024

🦋 Changeset detected

Latest commit: 7b5efdd

The changes in this PR will be included in the next version bump.

This PR includes changesets to release 1 package
Name Type
svelte Patch

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

@@ -34,22 +35,21 @@ export function bind_current_time(media, get_value, update) {
raf_id = requestAnimationFrame(callback);
Copy link
Contributor

Choose a reason for hiding this comment

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

I wonder if a rAF loop is right here because media should play when off tab, but the rAF will not run at all.

Copy link
Member Author

Choose a reason for hiding this comment

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

should be fine because once you switch back to the tab it continues to loop, and while you're off tab whatever the binding update causes wouldn't be of interest anyway

@dummdidumm dummdidumm merged commit d959d4a into main Jun 28, 2024
9 checks passed
@dummdidumm dummdidumm deleted the media-binding-fixes branch June 28, 2024 07:19
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