JavaScript (client-side) Messaging Anti-Patterns(freshbrewedcode.com)

10 pointsby ifandelsevor 14 Jahren2 comments

JavaScript (client-side) Messaging Anti-Patterns

http://freshbrewedcode.com/jimcowart/2012/03/19/client-side-messaging-in-javascript-part-3-anti-patterns/

1 comments

klsvor 14 Jahren

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.

ifandelsevor 14 Jahren

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.