WebSocket client

[mudont]

Even though still a WIP, this project has been a great help to me already.

I am adding a websocket client in my app, and would have loved to see an example of that doing idiomatically.

What I have done so far is add a ws service and ws feature with actions and epics.
The server pushes 4 (for now) kinds of objects, and and the ws client turns the incoming data into actions and the the data end up in the redux store.
I am reasonably comfortable (though far from certain) that this approach broadly is idiomatic and reasonable.
But one detail seems like a hack. The ws service needs the Redux dispatch function to be able to generate redux actions from the server pushed data. My solution so far has been to call the ws service's initialization function from store/index.ts explicitly passing store.dispatch to it.

I am wondering how to improve this. Maybe I should use react-redux connect() to wrap the websocket initialization function and call it from App.tsx ?

The other challenge that I haven't yet tried to implement, is I would would like to implement a semi-synchronous-feeling request/response/error/timeout flow over websockets similar to how REST API requests work . I suspect I have to deal with a mux/demux issue as there can be more than one request active, and need to match responses to the right requests. I will come up with something, but I suspect others have already invented clever ways of doing it that will never occur to me.

[mudont]

This was more of a comment rather than an issue. I apologize if I didn't follow the right protocol. This is my fist such post on github though I have been a passive user of many open source projects for a while. Piotr's are my favorites.

[piotrwitek]

Hey and welcome @mudont 🙌

Your suggestions are welcomed here :)

I like the idea of WebSocket client, and from top of my head, I feel I would create a WSService and I would inject it with other services to the epic. From there I could emit new actions to redux with a clean architecture.

The second part is more challenging I will think about it later when I have some free time to do that.

[mudont]

Thanks Piotr.
I do pass the service to the epic, and out going websocket messages are handled there. I did try to initiate web socket setup from the epic. At first I wanted to use the redux @@init action, but was mildly shattered to read Dan Abramov tweeting this was an anti pattern. Then I thought about the Rx js operator first() to do the one time setup. But it felt like epics are not a natural place for initialization. The reason connect occurred to me is that it is the one blessed way of getting (still safe) access to global redux store. May be you just have to do this when you have external sources of redux actions (Users are one such source, we sockets are another.), Rather than inserting a call in some path that currently has access to the store. That was my thought process. But I will take your advice as I am no expert at this paradigm, being an old school imperative non-ui programmer.

[mudont]

I think this can be closed. At least as far as I am concerned. Thanks for the advice. I see you plan implement a WebSocket client. Great. I look forward to seeing that.

I tried to move my WS initialization to the epic, but I couldn't figure out how to get hold of the disppatch function to pass it from the epic to the websocket service. Maybe have the store pass it to the Epics like how services are passed?

I also see you are implementing authentication. How I wish I had stared my project after you were done with this. I struggled with auth (though I didn't mind learning about it) and managed to get Auth0 authentication working inside this framework, though code is not as clean as your example.