Websocket: Undefined error on sending a string

[Sal]

I have an elm code defined here that simply sends a string over websocket: http://share-elm.com/sprout/53e1703ee4b07afa6f983cd8

Compiling and running it generates undefined error. This works fine if I write similar code in JS (just to confirm that the websocket is being opened, and command being sent). Are there any subtleties of websocket I am missing here? I could go back to using ports with JS but I want to avoid this, and keep the solution as simple as possible. 

I saw this discussion which seems to match my problem description: https://groups.google.com/forum/m/#!topic/elm-discuss/3xDhWg_CJYo/discussion

Can I do just selective patch of WebSocket library by downloading github patch? If not, is there another simple workaround short of rebuilding the entire compiler?

[Ray Racine]

My initial attempts to use a the runtime websocket hit the initialization bug as well.  However, it appears a response filter deals with the problem.  Here are two POC  (non-standalone) examples from some Elm playing around that work for me.

https://gist.github.com/anonymous/ce38c7328cee7f303dfb

--
You received this message because you are subscribed to the Google Groups "Elm Discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to elm-discuss...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[Ray Racine]

Before I forget there is a second issue with the current native runtime WS support as well.  If you use Chrome as a client, you can watch the WS frames that go back and forth.   If you let it the browser sit idle, you can see the time out keepalive ping/pongs going back and forth.  However, if the connection is closed on the server side (Ctrl-C the server and restart it) your page is "dead".  You have to refresh the page.   i.e. The current client side WS support will not automatically reestablish the connection if there is an outbound message and the connection is in a closed state.

[Sal]

Ray, thanks for posting this. I saw that before but didn't understand what a "response filter workaround" is. If this can be applied to my simple example (I can test and validate myself), that would help understand it better. 

[Sal]

Hmm, figured it out. Swapping "plainText" with "asText" function (which takes generic type signature instead of string) solved the string bug.

Fixed code here: http://share-elm.com/sprout/53e232eae4b07afa6f983d30