[Discussion] Make this library more "Darty"

[ThinkDigitalSoftware]

Is it more important to stay true to the JavaScript style of the library or should this port take into account the standard Dart style which is less error-prone than checking Strings? For example ,

socket.on('connect', (_) {});

would be

socket.onConnect((_) {});

etc

[jumperchen]

Yes, agree with that, we could make a high level API to forward it to the original API.

[millievn]

Maybe we can take advantage of stream

[Ascenio]

I like the idea. For now we could redirect the .on calls to their corresponding .onSomething(), while tagging the former as deprecated.

[jodinathan]

Our company has a need to make DataChannel messages ackable, we are pondering in adding DataChannel as a transport in this package.
If we are going to do it, we may also add pedantic analaysis_options, fix the lints, try to remove the use of Maps and add some streams to events (as a high level api).

What do you think?

I like the idea. For now we could redirect the .on calls to their corresponding .onSomething(), while tagging the former as deprecated.

How would you deprecate on('disconnect') but not on('myCustomCommand') ?

[jumperchen]

FYI: https://github.com/rikulo/socket.io-client-dart#usage-with-stream-and-streambuilder-in-flutter
And could integrate with https://dart.dev/guides/language/extension-methods for the socket object.

[ailabs-software]

I am grateful this port of the client to Dart exists.

If you replace the opts object (which is a Dart map at the moment) with a class with properly typed fields, that would make the library easier to use in my opinion.

Cheers

[jumperchen]

@BPILOT we could consider to use Builder Pattern for the opts object without changing existing code.