If reactivePrint or reactiveText return non-ASCII characters on
Windows, it causes invalid UTF-8 strings to be received by the
browser which closes the websocket connection.
I'm not sure this is the right place to do encoding, but it seems
to me like this approach is likely to work best for the most
users (especially those who just aren't thinking about encoding).
If you want to handle encoding in the reactives themselves (for
example), use `options(shiny.transcode.json=F)`.
If the server sends a message with a "custom" field, that field's value will
be passed to a custom window.Shiny.oncustommessage function, if it is defined.
Also add support for messages like so:
{
console: [
'line one',
'line two'
]
}
This will cause "line one" and "line two" to be printed at the browser console.
InputBinding.subscribe used to have to call callbacks with at least two arguments,
now there is only one optional argument (allowDeferred). The binding argument in
particular was problematic because it required "var self=this;".
(function() { }).call(Foo.prototype) for extending prototypes manually, and
$.extend for extending objects manually or prototypes inheriting from each
other.
This feature is currently pretty rough. It only works in the most modern
browsers (depends on HTML5 File API, including Blob.slice) and doesn't
show upload progress.
- JS can now do remote procedure calls (with return value or exception), not just message passing
- RPC calls can include non-JSON-compatible binary data (not compatible with IE)