bjunc / apollo-link-phx-ws

Phoenix websocket link for Apollo 2.0
7 stars 1 forks source link

Existing socket as an option #1

Closed harmon25 closed 6 years ago

harmon25 commented 6 years ago

Hi! Been testing this out in a pretty big app - working great! Kinda missing the redux logging i was getting... any idea how can i log all queries/mutations?

Also had other channels alongside the absinthe channel, the previous implementation took an existing socket object as an option, rather than building the socket object inside the constructor - could make that an option.

Just created a fork, going to test it out.

Created this branch in my fork

Passing socket as an option - it fixed the issue i was having, my existing channels are now working as expected alongside the absinthe channel.

Removed the ssr websocket for my own implementation anyway, also attached socket as a class variable rather than just local to the constructor.

Do not need to pass it to the _joinChannel method now, it can be accessed from this.

bjunc commented 6 years ago

Glad it's working for you!

Per logging, I think that'd probably be better served through a separate "link". Apollo 2.0 chains links together, so instead of putting all logic into one Network Interface (Apollo 1.x), you'd simply add another link. Here's an example on how to create your own: Creating an Apollo Link

I'll take a look at your branch, and see if there are things that should be adopted. To be honest, mine was an initial prototype, so I'm sure there is plenty of opportunity for refinement. Passing in the socket makes sense. I also think an SSR flag/check would be good since the Phoenix socket lib references window.

bjunc commented 6 years ago

@harmon25 I pushed an update worth checking out (v0.3.2).

First, I added some JSDoc to help with reading through it.

Second, you can pass an already instantiated PhoenixSocket. Otherwise, it will instantiate a new one.

W3CWebSocket is no longer bundled. If you need SSR, just use the npm websocket lib and assign W3CWebSocket as the transport option.

I left the _joinChannel(socket) as I think that's a better design pattern (dependency injection and better testing... when I get to that).

Let me know what you think, and if this works for you.

harmon25 commented 6 years ago

Installed the new version off GitHub, fixes my original issues, thanks! Allows you to connect to other channels with the same socket - as intended

I may take a look at getting subscriptions to work, also will look into the logging via link you posted. I am not currently using them in my app either, but seems like it would be ideal for certain features - near real-time notifications, messaging etc... and to replace the places where i am using polling to keep UI in sync.

Will keep updated, and possibly create another branch based off your master to play around with it