Feature: support socket.io - [INS-5024]
https://github.com/user-attachments/assets/1fc87bb7-82e0-407b-8f3c-ed6add076142
Support Socket.io
Feature list:
- socket.io request creation
- socket.io request payload (multiple args support)
- event listeners
- Response event log preview
Changes:
- add new package:
socket.io-clientas socket.io client - new db model:
socket-io-requestsocket-io-responsesocket-io-payload - new UI components under
packages/insomnia/src/ui/components/socket-iodirectory - new IPC bridge for socket.io
const socketIO: SocketIOBridgeAPI = {
open: options => ipcRenderer.invoke('socketIO.open', options),
readyState: {
getCurrent: options => ipcRenderer.invoke('socketIO.readyState', options),
},
close: options => ipcRenderer.send('socketIO.close', options),
closeAll: () => ipcRenderer.send('socketIO.closeAll'),
event: {
findMany: options => ipcRenderer.invoke('socketIO.event.findMany', options),
send: options => ipcRenderer.invoke('socketIO.event.send', options),
on: options => ipcRenderer.send('socketIO.event.on', options),
off: options => ipcRenderer.send('socketIO.event.off', options),
},
};
What have you scoped out? What else should be done? What else could be done? Is this a first pass or a complete feature with no futher ux changes required? It there any refactoring you considered doing but didn't? Do you have any other ideas you would like to explore try if you took a second pass?
What have you scoped out? What else should be done? What else could be done? Is this a first pass or a complete feature with no futher ux changes required? It there any refactoring you considered doing but didn't? Do you have any other ideas you would like to explore try if you took a second pass?
@jackkav This pr implements basic support for the socket protocol, and I think this is ready for a beta version. There are some UX optimizations that can be done later, such as adding a loading state for the connection button, and others can be continuously optimized based on user feedback. Other things I can think of are:
- Abstract some functions and components similar to WebSocket for reuse
- Encapsulate some basic components, such as buttons/switches/forms, etc., to improve the efficiency of other features and the consistency of UI
- ts type optimization (adding a new request requires modifying many type definitions now)
@CurryYangxx Good work so far.
Can you explain the difference between open close and on off somewhere in the PR. The usage is quite ambiguous, is it possible to eliminate either of them or do they have special differences?
Secondly I would encourage you to reuse the websocket components rather than duplciating them all. Thankfully there is an earlier PR which adds the realtime protocol SSE. https://github.com/Kong/insomnia/pull/6147
Its much cheaper to do right away in this scope than leave it until later. If its not viable to do in this scope please list where the ui deviates enough to justify 1500 lines of what appears to be largely duplication.
Thanks.
Can you explain the difference between open close and on off somewhere in the PR. The usage is quite ambiguous, is it possible to eliminate either of them or do they have special differences?
@jackkav Socket.io is event-based communication, when the connection is established, the client side can subscribe or unsubscribe to an event to control which event messages will be received from the server side. The open&close is used for connection, and the on & off is for event subscription. You can get more details from here: https://socket.io/docs/v4/listening-to-events/
Secondly I would encourage you to reuse the websocket components rather than duplciating them all. Thankfully there is an earlier PR which adds the realtime protocol SSE. #6147
I agree, I will try to reuse websocket components as much as possible, and I think this may need some UI abstraction.
@jackkav I reused websocket components in #8828 and removed most of the repeated code. Please let me know if you have any feedback.