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

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants