8000 fix(useWebSocket): urlRef changes were not being tracked by ferferga · Pull Request #3870 · vueuse/vueuse · GitHub
[go: up one dir, main page]
More Web Proxy on the site http://driver.im/
Skip to content

fix(useWebSocket): urlRef changes were not being tracked #3870

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
May 27, 2024
Merged

fix(useWebSocket): urlRef changes were not being tracked #3870

merged 1 commit into from
May 27, 2024

Conversation

ferferga
Copy link
Member
@ferferga ferferga commented Mar 17, 2024 •
edited
Loading

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

  • Read the Contributing Guidelines.
  • Read the Pull Request Guidelines.
  • Check that there isn't already a PR that solves the problem the same way to avoid creating a duplicate.
  • Provide a description in this PR that addresses what the PR is solving, or reference the issue that it solves (e.g. fixes #123).
  • Ideally, include relevant tests that fail without this PR but pass with it.
⚠️ Slowing down new functions

Warning: Slowing down new functions

As the VueUse audience continues to grow, we have been inundated with an overwhelming number of feature requests and pull requests. As a result, maintaining the project has become increasingly challenging and has stretched our capacity to its limits. As such, in the near future, we may need to slow down our acceptance of new features and prioritize the stability and quality of existing functions. Please note that new features for VueUse may not be accepted at this time. If you have any new ideas, we suggest that you first incorporate them into your own codebase, iterate on them to suit your needs, and assess their generalizability. If you strongly believe that your ideas are beneficial to the community, you may submit a pull request along with your use cases, and we would be happy to review and discuss them. Thank you for your understanding.

Description

URLRef changes were not being tracked inside useWebSocket

@ferferga
fix(useWebSocket): urlRef changes were not being tracked
a7b6b02 
Signed-off-by: GitHub <noreply@github.com>
@dosubot dosubot bot added the size:XS This PR changes 0-9 lines, ignoring generated files. label Mar 17, 2024
@ferferga ferferga mentioned this pull request Mar 17, 2024
Closed
@ferferga ferferga mentioned this pull request Apr 7, 2024
Closed
5 tasks
@GarlandQian
Copy link

If I haven't opened the WebSocket, I believe it shouldn't be opened directly when the URL changes. It should maintain the current state. Even when the immediate parameter is set to false, I think regardless of the current WebSocket state, it should be closed directly.

@ferferga
Copy link
Member Author

@GarlandQian In that case, what's the benefit of using useWebSocket instead of the "raw" WebSocket instance?

This is a regression, not a new feature.

@antfu antfu merged commit c2f9295 into vueuse:main May 27, 2024
@abdullahkabakk abdullahkabakk mentioned this pull request Jun 17, 2024
Open
@Anomaly-1 Anomaly-1 mentioned this pull request Jun 18, 2024
Open
@ferferga ferferga deleted the fix-websocket-url-reactivity branch June 21, 2024 12:04
This was referenced Jul 3, 2024
Open
Open
This was referenced Jul 24, 2024
Open
Open
@Samad2011s Samad2011s mentioned this pull request Jul 28, 2024
Open
@Anomaly-1 Anomaly-1 mentioned this pull request Aug 30, 2024
Open
@DrColossos
Copy link

Sorry to jump in here: this just arose as a "bug" in our internal app. I was surprised with the behavior, especially since I use immediate: false. This is somehow unexpected since we have another server that retrieves the current websocket URL and passes it on to useWebsocket to be triggered at a later point in time.

@ferferga
Copy link
Member Author
ferferga commented Sep 2, 2024

@DrColossos First of all, this PR fixed a regression, so that behaviour worked in your application by "taking advantage" of that regression. But according to what's stated in the docs, what you say is the behaviour that it should have.

In either case, in my opinion the docs are incorrect and the implementation is right: in all other composables, immediate just controls if the composable starts at the beginning or not, instead of whether "reacting to effects" is enabled or not. Having the option to disable the "reactivity" makes no sense in this library, since the sole reason to exist is to make common APIs easy to use reactively.

In your case, I think your logic can easily be simplified: why not have that URL be computed (or computedAsync from this library if it's fetched from a server with reactive params) and pass that to this composable? If that computedref is turned nullish, the socket will disconnect, if the URL changes, the socket will point to the new one accordingly, in the same way you expect a component's DOM to update when it's reactive dependencies are updated.

@DrColossos
Copy link
DrColossos commented Sep 2, 2024 •
edited
Loading

Thank you for you info. I was reading the immediate flag "Automatically open a connection" from the source of the types. Looking at the rest of the online docs, I see the full description of the flag states what you say. I was only looking at the types.

Anyways, thanks for clarification!

@ferferga ferferga mentioned this pull request Sep 5, 2024
Merged
5 tasks
This was referenced Sep 11, 2024
Open
Open
Open
Open
Open
Open
This was referenced Sep 18, 2024
Open
Open
Open
@m0hs1ne m0hs1ne mentioned this pull request Sep 21, 2024
Open
@m0hs1ne m0hs1ne mentioned this pull request Sep 22, 2024
Open
This was referenced Sep 22, 2024
Open
Open
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers
No reviews
Assignees
No one assigned
Labels
size:XS This PR changes 0-9 lines, ignoring generated files.
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
4 participants
@ferferga @GarlandQian @DrColossos @antfu
0