passing in event handlers is obviously going to be the most common
usage (all apps won't necessarily need to change the default options,
though many will want to). so it seems silly to hide the event handlers
as an option... i feel like it's better as it's own separate
argument.
i personally think this was an important change as the default encoding
of maps to be sent as json is somewhat lossy (keywords converted to
strings, would never be able to get this 100% perfect using json alone
without a more complex encoding solution). encoding to edn is the
perfect solution to this.
since browserchannel pretty much requires the final sent data to be
json encoded, we just serialize the clojure data being sent to an
edn string within a root json object.
this does ultimately mean we have to do a little bit of pre-parsing
of sent and received maps to encode/decode properly and make it
completely transparent to application code, but i think it's an
acceptable tradeoff.
up until now, a single event handler "on-session" could be provided to
wrap-browserchannel which would be invoked each time a new client
session was created. it was then the application's responsibility to
register listeners for close/receive events inside this on-session event
handler.
this was kind of clunky honestly. basically every application would want
to use all of these events, so why not reduce the boilerplate needed?
this change makes it so a map of event handlers (:on-open, :on-close and
:on-receive) can be passed under wrap-browserchannel's options map (in
the key :events). this makes it simpler for an application to set up
browserchannel event handlers, and it works in basically the exact same
way as the clientside event handler registration works right now
Gered
