reasonml-community / bs-socket.io

Bindings to socket.io
MIT License
50 stars 13 forks source link

Socket has hardcoded "message" event #9

Open graforlock opened 6 years ago

graforlock commented 6 years ago

I believe Socket.on is not generic enough, as it stand now it is:

let on = (socket, func) =>
      _on(socket, "message", obj => func(Json.fromValidJson(obj)));

But looking at the docs Socket.IO Documentation, socket.io should support different types of events:

io.on('connection', function(socket){
  socket.emit('request', /* */); // emit an event to the socket
  io.emit('broadcast', /* */); // emit an event to all connected sockets
  socket.on('reply', function(){ /* */ }); // listen to the event
});

So the above would be like this:

let on = (socket, event, func) =>
      _on(socket, event, obj => func(Json.fromValidJson(obj)));

The design decision here is however to support switch statement match; shouldn't user have option to do it the standard way through optional parameter?

bsansouci commented 6 years ago

Hey! Yup the design is to enable pattern matching, and socket.io’s design is closely tied to JS and it’s semantics. Why would you like to send stringly-typed messages?

One good reason could be to communicate with an existent backend/frontend. In which case I could imagine exposing some unsafe functions.

graforlock commented 6 years ago

Yes that is correct, if either is in another language or stack, the API should provide some flexibility for such case.