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

add type information to the webSocketHandler onConnection callback #457

Open
devoncarew opened this issue Nov 21, 2024 · 2 comments
Open
Labels
next-breaking-release Issues that are worth doing but need to wait for a breaking version bump package:shelf_web_socket

Comments

@devoncarew
Copy link
Member

Currently, the onConnection callback to webSocketHandler is untyped (it's just a Function).

Handler webSocketHandler(Function onConnection,
    {Iterable<String>? protocols,
    Iterable<String>? allowedOrigins,
    Duration? pingInterval})

onConnection is expecting one of two forms:

void Function(WebSocketChannel webSocket)

or

void Function(WebSocketChannel webSocket, String? subprotocol)

If the first form is passed into the param then it is automatically promoted to the 2nd form

  if (onConnection is! void Function(Never, Never)) {
    final innerOnConnection = onConnection;
    // ignore: inference_failure_on_untyped_parameter, avoid_dynamic_calls
    onConnection = (webSocket, _) => innerOnConnection(webSocket);
  }

I'd like to convert the param to include type information. I think it has to be like this:

typedef ConnectionCallback = void Function(
    WebSocketChannel ws, String? subprotocol);

i.e., the caller has to pass in a closure that has two params, even if they never intend to use the subprotocol param. I suspect that 99% of users are currently just passing in a closure w/ one param, so this would require them to update their code.

Even making the typedef into something like typedef ConnectionCallback = void Function(WebSocketChannel ws, [String? subprotocol]); would require their closure to still define the optional param.

Is there any typedef that would let the user not need to have a closure w/ two params?

Or should we specialize webSocketHandler; have the current one take a closure w/ one param (the created websocket), and have a webSocketHandlerSubProtocol() which takes a closure w/ two params?

@devoncarew
Copy link
Member Author

@natebosch - thoughts?

@natebosch
Copy link
Member

There is not clean type system solution for this problem. Adding a signature that specifies both arguments is the right pattern to use. It is breaking, but I think we can manage a breaking version release of shelf pretty easily

@devoncarew devoncarew added the next-breaking-release Issues that are worth doing but need to wait for a breaking version bump label Dec 2, 2024
devoncarew added a commit to dart-lang/test that referenced this issue Dec 3, 2024
…od (#2421)

- add a 2nd argument to the closure passed into
package:shelf_web_socket's `webSocketHandler` method
- widen the dep on package:shelf_web_socket

This will allow us to add more type info to the closure that
`webSocketHandler` expects; it's currently an untyped Function. See also
dart-lang/shelf#457 and
dart-lang/shelf#463.

This forward declares compatibility with `3.0` of
`package:shelf_web_socket`; I _think_ this is necessary - as `dart test`
uses both package:test and package:shelf_web_socket - but happy to hear
otherwise.

---

- [x] I’ve reviewed the contributor guide and applied the relevant
portions to this PR.

<details>
  <summary>Contribution guidelines:</summary><br>

- See our [contributor
guide](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md)
for general expectations for PRs.
- Larger or significant changes should be discussed in an issue before
creating a PR.
- Contributions to our repos should follow the [Dart style
guide](https://dart.dev/guides/language/effective-dart) and use `dart
format`.
- Most changes should add an entry to the changelog and may need to [rev
the pubspec package
version](https://github.com/dart-lang/sdk/blob/main/docs/External-Package-Maintenance.md#making-a-change).
- Changes to packages require [corresponding
tests](https://github.com/dart-lang/.github/blob/main/CONTRIBUTING.md#Testing).

Note that many Dart repos have a weekly cadence for reviewing PRs -
please allow for some latency before initial review feedback.
</details>

---------

Co-authored-by: Jacob MacDonald <jakemac@google.com>
github-merge-queue bot pushed a commit to flutter/flutter that referenced this issue Jan 6, 2025
)

- update the engine and flutter_tools to be forward compatible with the
upcoming shelf_web_socket v3.0

*List which issues are fixed by this PR. You must list at least one
issue. An issue is not required if the PR fixes something trivial like a
typo.*

- dart-lang/shelf#457
- dart-lang/shelf#463

## Pre-launch Checklist

- [x] I read the [Contributor Guide] and followed the process outlined
there for submitting PRs.
- [x] I read the [Tree Hygiene] wiki page, which explains my
responsibilities.
- [x] I read and followed the [Flutter Style Guide], including [Features
we expect every widget to implement].
- [x] I signed the [CLA].
- [x] I listed at least one issue that this PR fixes in the description
above.
- [x] I updated/added relevant documentation (doc comments with `///`).
- [ ] I added new tests to check the change I am making, or this PR is
[test-exempt].
- [x] I followed the [breaking change policy] and added [Data Driven
Fixes] where supported.
- [x] All existing and new tests are passing.

If you need help, consider asking for advice on the #hackers-new channel
on [Discord].

<!-- Links -->
[Contributor Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview
[Tree Hygiene]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md
[test-exempt]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests
[Flutter Style Guide]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md
[Features we expect every widget to implement]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement
[CLA]: https://cla.developers.google.com/
[flutter/tests]: https://github.com/flutter/tests
[breaking change policy]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes
[Discord]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md
[Data Driven Fixes]:
https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
next-breaking-release Issues that are worth doing but need to wait for a breaking version bump package:shelf_web_socket
Projects
None yet
Development

No branches or pull requests

2 participants