WebSocket API

From Discord discussion:

sergiodxa — hoy a las 11:17
actually I would probably prefer this
```ts
// use this to get the initial data
export async function loader({ request }) {
  let data = await getData(request)
  return json(data)
}

// use this to mutate and broadcast data to WS subscribers
export async function action({ request, broadcast }) {
  let formData = await request.formData();
  let something = await doSomething(formData);
  await broadcast(something); // this should pass data from action to the socket
  return redirect("path")
}

// use this to get the data from the action and send it to subscriber
export async function socket({ data }) { // this data came from the action broadcast
  let actualData = await getActualData(data) // here you can use the action data to get more things if needed
  return actualData; // and return what you want to send to users
}

export default function Route() {
  let initialData = useLoaderData();
  let { data } = useSocketData(); // the data here should probably be an array, every return from socket should append new items
  // ...
}
```

Alex 🚀 — hoy a las 11:23
Something worth considering is whether you need subscription filters too. Route-by-route subscriptions help, since you could automatically be unsubscribed from a specific route's publishes when you leave that route. 

But then there might be circumstances where only specific clients want to get the subscription publishes based on parameters they provide to the server somehow.
Also, actions from one route need the ability to trigger broadcasts on another route

sergiodxa — hoy a las 11:26
what I was thinking is the broadcast from an action only trigger the socket function on the same file/route, so let's say you have a route /chat/:chatId/messages/new, there you have an action to create new chat messages for a specific chat, you can do useSocketData("/chat/1/messages/new") and subscribe to the data broadcasted from the action on that route, so you subscribe to new messages on the chat 1 basically 
if you don't pass anything to useSocketData it could try to subscribe to the WS on the same route of the component
this way, you could have routes with only socket and action if you want, the action do something and the socket let users subscribe to know when that something happens
another option is that broadcast could receive the data to broadcast and a path, then the socket function on that path can receive the data
so you can have socket and action in different routes

garand — hoy a las 11:29
Something to consider if the data from useSocketData is an array... I have an app using websockets and it's sending a JSON object every 200ms, and I have the app open for 8 hours a day. Storing that would fill up memory pretty fast I think.

sergiodxa — hoy a las 11:29
and a final idea, the socket function may not be required at all, if it's not defined whatever you pass to broadcast from action could be what subscribers will receive, if you define one you could use it to get more data or to reduce the data you sent

sergiodxa — hoy a las 11:30
let's say you are doing a chat, loader returns the messages at the moment the page load, useSocketData should give you every new message from that moment, if data returned from useSocketData is not an array it means you will only have the latest message on the chat, so you should store each message as they arrive in a state?

garand — hoy a las 11:31
I would think it's up to the user to store it if they want depending on the use case.

sergiodxa — hoy a las 11:32
🤔 maybe it makes more sense, you could also limit the number of messages you store that way

garand — hoy a las 11:32
Right, I keep a rolling 60 or so data points
For instance, the react-use-websocket package I use returns a key called lastJsonMessage

sergiodxa — hoy a las 11:35
yeah, that makes sense, and is not that hard anyway to keep messages on state
```ts
let initialData = useLoaderData();
let [messages, setMessages] = useState(initialData.messages);
let { data } = useSocketData();
useEffect(() => setMessages(current => current.concat(data)), [data]);
// render messages here
```

[sergiodxa]

From Ryan’s comment

ryanflorence — hoy a las 11:07
we'll have a table of "features supported by each adapter"
and if you try to use one with a platform that's not supported we'll throw

So yeah, it’s something you are going to be able to use based on the adaptar you are using, if you use Express for example you can use it, Vercel or CF will not be able to use it.

Another option is to see if there are ways, maybe in the future, to enable it, maybe CF release a WebSocket feature you can use when deploying there and Remix can use that internally

[gavriguy]

Another option for serverless will be to add some logic to the client that will then ask to refetch data from the action. Maybe something on top of usefeatchers. It means that instead of using sockets to pass data it’ll we be used only to tell the component to refetch. This also can integrate with long polling easily