

JavaScript (client-side) Messaging Anti-Patterns - ifandelse
http://freshbrewedcode.com/jimcowart/2012/03/19/client-side-messaging-in-javascript-part-3-anti-patterns/

======
kls
I tend to treat message passing data as immutable, I think in my time
developing applications (almost 20 years now) I have hit a pattern maybe twice
where I have needed something to modify the message before other listeners in
the sequence receive it, but when they arise they can be a nasty pattern to
deal with. It brings order of events to a pattern which for the most part is
designed to be unordered. I have developed two patterns to deal with modifying
messages when the need arises and I am still not sure which I like better.

The first is I clone the message and pass a mutable and immutable copy of the
data, this seems to work ok but you still have to ensure order of events, so
if the message passing pattern guarantees first in first out, I just make sure
the registration sequence of modifying listeners are registered first. It is
not bullet proof but it has worked for my needs.

The second pattern I have used is a concept of a preprocessor routine, kind of
a method that does all the modification before the message event is fired, so
I wire the data to the preprocessor and then the preprocessor fires off the
message event after it has made it's modification.

~~~
ifandelse
Well said. I've used the second pattern you described as well. If I find
myself in a situation where I'm tempted to treat the message as mutable, it
usually indicates I've hit the point where I need to (potentially) use some
sort of transformation pipeline, and the steps in that transformation should
ideally be encapsulated inside a component and not publicly exposed on the bus
itself.

