add scrollTop and scrollLeft bindings

[Rich-Harris]

fixes #3780. The binding code gets hairier and hairier... at some point it will probably need a bit of a spring clean

[Rich-Harris]

Actually, I don't think this is quite right. The timeout (which is designed to prevent scroll being set in response to a scroll event) is preventing spring/tweened values from controlling scroll, which isn't what we want. This might also affect <svelte:window>? More work needed

[freedmand]

What about an approach where you simply set an ignore flag that's cleared in the scroll handler, following https://stackoverflow.com/a/1386750

[xylobol]

What about an approach where you simply set an ignore flag that's cleared in the scroll handler, following https://stackoverflow.com/a/1386750

I've implemented something like this for one of my projects. It's determined whether the scroll was user-triggered or script-triggered. We can tell because scripts have to set a variable when trying to scroll.

[stale]

This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated
svelte-dev-2	❌ Failed (Inspect)			Mar 2, 2023 at 11:53AM (UTC)

[Imran-imtiaz48]

Review and Improvement Suggestions:
Error Handling: The refactoring introduces a more consistent approach to error handling by returning errors directly from the function where appropriate. This can improve clarity and maintainability, as each condition now directly returns an error message.

Functionality: Ensure that compiler_errors.invalid_binding(binding.name) correctly generates the error message for invalid bindings. It's important that this function correctly encapsulates the logic for generating error messages based on the binding name.

Readability: Both versions are similar in terms of structure and logic flow, which is good for readability and understanding. Continue to maintain this clarity throughout your codebase.

Testing: After making changes to error handling, it's crucial to test the code to verify that errors are properly thrown and handled under different scenarios.

Documentation: Consider documenting error handling strategies, especially if they involve custom error messages or specific conditions that might not be immediately obvious to others reading the code.

By following these suggestions, you can ensure that your error handling is robust and consistent across your codebase, leading to better maintainability and understanding for future development and maintenance tasks.

[Rich-Harris]

Closing Svelte 4 PR as stale