Professional JavaScript: AntiPatterns

Professional
JavaScript

AntiPatterns
By

Mike Wilcox

February 2014

This code sucks!
if (target) {
if (target.targetParent.targetParent) {
target.targetParent.targetParent.targetParent = new Event(this);
} else {
target.targetParent.targetParent = new Event(this);
}
return target;
}

WTF??
this.graphs = utilities.settingArrayPropertyProxy(
settings.graphs,
function (index, newGraph) {
var currentLimits = chartEngine.getActualLimits(), newLimits;
chartEngine.addGraph(newGraph, index);
chartEngine.render();
},
function (newGraph, oldGraph) {
result = chartEngine.updateGraph(newGraph, oldGraph);
chartEngine.setLimits(self.xAxis().limits());
},
function (index, removed) {
chartEngine.setLimits(self.xAxis().limits());
},function (setting) {
return new Graph(self, chartEngine, setting);
},
false);

ilcox
ike W
M
Co m mitter!

HTML5
Graphic Design

JavaScript ES5

UI/UX architecture

CSS3
Works there.

Natch!

But more importantly...
Brend

an Eic
h

me

Knighted me
the
Noble Architect*

*not strictly true

What do I know??
Seriously…
Being a committer to the Dojo Toolkit JavaScript
library means not only having your code and
style scrutinized by know-it-all prima donnas,
open source experts, but your results also get
used by thousands of hacks that
expect magic developers who
expect quality code.

AntiMatter
In particle physics, antimatter is material composed of
antiparticles, which have the same mass as particles of
ordinary matter but have the opposite charge.

Encounters between particles and
antiparticles lead to the annihilation of both

AntiPattern
A commonly used process, structure or pattern of action
that despite initially appearing to be an appropriate and
effective response to a problem, typically has more bad
consequences than beneﬁcial results.

Encounters
between patterns
and antipatterns
lead to the
annihilation of both

What to Expect
Discuss paradigms and patterns.
Good and bad.
Some patterns. Not all.

Focus on communications between
components.
Three words:
Maintainability, maintainability, maintainability

What is a Pattern?

Gang of Four

Addy Osmani

A design pattern is a general reusable solution
to a commonly occurring problem

Introduction
It is more difﬁcult to build maintainable code in
JavaScript than languages such as Java or C# due to its
dynamic nature and its original intent to be a simple
language with little more to do than validate forms.
There is nothing built in to the language to assist in the
construction of large apps: no classes, no modules, no
packages.
There is little to no formal developer training in
JavaScript
The result of this is programmers attempt to solve
coding problems and end up with AntiPatterns

Hypothetical App
Let’s architect a chart application. The structure
and functionality should look like:
The Chart class is the API and main controller.
The Graph class controls the Axes and Series (which
draws the lines)
There can be multiple Graphs in a Chart.
There can be multiple Series in a Graph.

Chart App
Here are the main components of our hypothetical chart
app below. How do you think they should be wired up?

chart

engine

renderer

graph

x axis

y axis

series

layer

painter(s)

Chart App Structure
graph-proxy

series-proxy

e
re to hi d
Proxies ass below
the me

layer-proxy

chart

engine

renderer

graph

x axis

y axis

series

layer

painter(s)

An example of how circuitous the code path can get if the structure is not
carefully considered before hand.

Chart App Structure
When carefully considered, the code ﬂow might look more like below.
It may take a little extra code to get to this, but it would be worth it
for a result that is easier to follow.

chart

engine

renderer

graph

x axis

y axis

series

layer

painter(s)

Code Flow
Meets acceptance criteria
Done!

Clean
Readable
Maintainable
Extensible
Testable

The quick way is often not the correct way

Management AntiPatterns
Slave Driving Management
Sales Driven Development
Waterfall Development
Hiring Practices

Developer AntiPatterns
Not enough experience
The lack of working with others
Too much solo programming
Not enough collaboration
Just damn lazy
When you ﬁnd a problem ﬁx it, don't just drop a TODO

Super Star Programmers
Smart kids with no life that work 70 hours and generate layers
upon layers of code that works... but lacks best practices, code
reviews, comments, tests, and sometimes even reason

Procedural
Using nothing but functions is the very deﬁnition of
spaghetti code
jQuery encourages procedural… and $paghetti !
Good for a web "page", not good for a web "app"
If you’re not doing some sort of OOP, you will have
a massive climb toward a maintainable large
application
Easier for the developer to comprehend small
objects, rather than large routines

Spaghetti Object Oriented Programming
… or what I have dubbed: SOOP
Too much inheritance
Inheritance breaks encapsulation because the internals
of parent classes are visible to subclasses
Tends to counterintuitively create tight coupling
Makes for a very difﬁcult-to-follow API when most of
the code is not in the current ﬁle
Making classes work together without stepping on
methods, etc gets complex

Even MOAH SOOP
FilteringSelect
MappedTextBox
ValidationTextBox
TextBox
_FormValueWidget
_FormWidget
_Widget
_TemplatedMixin
_CssStateMixin
_FormWidgetMixin
_FormValueMixin
_FormWidgetMixin
_TextBoxMixin
ComboBoxMixin
_HasDropDown
_FocusMixin
_WidgetBase
Stateful
Destroyable
_AutoCompleterMixin
SearchMixin

Over-inheritance is one
of the current problems
with Dojo

I needed to inspect this code for
what the server query should look
like. What ﬁle do you think that
was in?

MOAR SOOP
Inconsistent object methods
Violation of the Composition pattern
chart.setRect({}); graph.rect({});
settings.rect = {}; series.dimensions({});

Too much functionality
9000-line class ﬁles defeat the whole purpose of OOP

Lack of encapsulation
foo.bar.bop.hop.doThing();
Even worse for setting properties

Abstractions / Proxies
Don't do it. This ain't Java.
More overhead than direct coding, wasting precious
bytes
Because it is not native to the language, there is a
danger of creating an unmaintainable abstraction
Alternative:
Comment your damn code.
Smaller classes

Callbacks
Yes, callbacks can be an anti-pattern
Even simple callbacks as an argument is weak:
foo(x, onDone);

Passing a callback more than once quickly gets
messy
You may have heard of… callback hell.

Puts ownership of the callback in the wrong object,
which needs to check for existence
We have more modern techniques like Promises*

*Although most implementations suck

Getters and Setters
Not just an anti-pattern, getters and setters are EVIL!
Class = {
get x(){
this.node.style.left = x + ‘px’;
this.name = null;
delete this.age;
document.title = ‘My Crazy Page’;
}
};

Potential for crazy side effects
The DOM has it wrong

Private Properties

EVIL!

Can’t use the debugger to inspect objects
Can cause major problems in inheritance
Uses extra memory (in object instances)
Especially true in library code
Business code is less critical, but then… what are you
hiding, and from whom?
Suggest the underscore convention or an interface to
emphasize public API
http:/
/clubajax.org/javascript-private-variables-are-evil/

Properties

EVIL!

Now you may think I’ve gone off the rails. But...
In ref to setting from an external source

The state of a class should be handled by the class
If multiple objects are setting a property and
something goes wrong, you don’t know who dunnit
Settings objects and arrays may lose ﬁelds
Accessing a property may not be in sync with the
DOM, or necessitate overhead to keep them in sync
Okay, properties aren’t evil. But you should consider
MSDN Properties vs. Methods
when and how you use them.

Why Refactor
Doing things quick and dirty sets us up with a
technical debt, which is similar to a ﬁnancial debt,
which incurs interest payments: the extra effort
to do in future development
All projects at some point need to pay down
technical debt
Eventually more time will be spent servicing the
debt than on increasing value
Accumulated technical debt becomes a major
disincentive to work on a project
Concepts courtesy of Jeff Atwood, Coding Horror

When to Refactor
Reasons we refactor:
It's been six months and you feel you are smarter now
You read about a cool pattern on Hacker News
You found a cool jQuery plugin that has some sweet
chaining
You want to completely rewrite the project because the
last dev used spaces instead of tabs

When your boss lets you refactor:
Never.

How to Refactor
Always Be Refactoring

ABR

As a project grows (and all projects grow) there will
be a continual need to refactor
For small refactors, do them as you go
For medium refactors, hide them in tasks
For large refactors, use git, work in a branch
Major rewrites should be done in chunks
Don’t panic, do a little at a time, even if meaningless
Reorganize
Run tests often

require.js
You are using it, aren’t you?
Global namespaces are SO 2011
Globals can clash with other code, they are slow to
access, and they do not garbage collect
require.js provides a mini-framework, enforcing
packages, namespaces, and modules
Also consider:
Browserify - CommonJS
uRequire - UMD

Frameworks
Good for teams with less experience

Dojo
Ember
Angular
ExtJS
YUI
Marionette

But don’t get too excited.
Even with the

magical MVC pattern
frameworks will only get you
part way there.

Coupling
Tight
Content coupling
When one module modiﬁes or relies
on the internal workings of another
module
Common coupling
When two modules share the same
global data
External coupling
When two modules share an
externally imposed data format,
communication protocol, or device
interface.
Control coupling
One module controlling the ﬂow of
another, by passing it information

Loose
Data-structured coupling
When modules share a composite
data structure
Data coupling
When modules share data through,
for example, parameters. Each
datum is an elementary piece, and
these are the only data shared
Message coupling
Component communication is done
via parameters or message passing
No coupling
Modules do not communicate at all
with one another.

Encapsulation my boy...
Encapsulation is a form of data hiding; data, methods,
and properties. Only the interface or API is exposed.
The primary goal:
Easier for the developer to comprehend small
objects vs. large routines
But also:
Ownership of its own concepts, data, and
functionality
Breaks up functionality into smaller objects
It reduces the mystery of which module owns what

Proper Object Oriented Programming*
Object Composition: no internal details of composed
objects need be visible in the code using them
Two or three inheritance levels, or, very small
changes
Subclass Coupling
The child is connected to its parent, but the parent is
not connected to the child
For a child to talk to its parent violates a basic
programming principle of high and low level
functionality

*I have not consider any acronyms for this

TDD
Proper Test Driven Development means writing the tests
ﬁrst - forcing you to consider the consequences before
you commit to them. You’ll ﬁnd ways to:
Reduce dependencies
Encapsulate functionality
Create an intuitive interface
Keep the logic simple
Though multiple simple functions may be complex

The Failures of "Intro to TDD"

Naming and Arranging
Don't expect to cram it all into preconceived modelview-controller folders, it's too limiting, and the app
will grow out of it
Remember, the code path ﬂows
down, not up, so the deeper modules
should not have access to root or
higher level modules

Business Logic
As much as possible, business logic should be as separate
from application logic, and especially the UI
Even if this means extra code is
needed to maintain the
separation

business
application
UI

low level functionality

pubsub
Pros:
Library code is very simple
Can access distant areas of app
Cons:
Not guaranteed - pub can ﬁre before sub is ready
Can be hard to follow code paths between unrelated modules
Over-use can lead to bad habits and sloppy code
Should only be used with very loosely coupled objects
! pubsub.publish('/module/loaded', {success:true});
! pubsub.subscribe('/module/loaded', function(object){
! ! console.log('load success:', object.success);
! });

Observables
Like events that you can set
Similar to event streams in that they ﬁre on change,
and you can also read the current property
myName = obeservable('Mike');
console.log(myName); // Mike
obeservable('Bob');
console.log(myName); // Bob
myName.subscribe(function(value){
! if(value !== 'Mike'){
! ! console.log('Hey! My name is not ', value);
!}
});

Template Behaviors
<div id='menu' data-bind='ko.menu'></div>
ko.bind(‘#menu’, widgetWithMenu);

Attach DOM behavior to the template
Separates behavior from widget
Further decouples code
A good way to keep business logic separate from
DOM logic
Helps for unit testing
MVVM is a good TDD solution

Plugins
Use the concept for separating code
Various patterns for making a module pluggable
depends on code
Plugin may need intimate knowledge of host object
Importance is separation of concepts for
maintainability
Plugins aren't usually portable to other host objects
anyway

Event Emitters
The new hotness
Multiple connections can be made
Intent is clear - obvious they are events and what they do
Much better pattern than pubsub for objects that relate

dataLoader = {
! ! onDataLoaded: function(data){
! ! ! this.emit('dataloaded', data);
!! }
}
function onDataLoaded(data){
! ! console.log(data);
}
dataLoader.on('dataloaded', onDataLoaded);

Event Versatility
graph = {
! removeSeries: function(serieId){
! ! var serieData = this.serieMap[serieId].data.clone();
! ! this.serieMap[serieId].destroy();
! ! return serieData;
!}
}
chart = {
! removeSeries: function(seriesId){
! ! var graph = this.findSerieOwner();
! ! var seriesData = graph.removeSeries(seriesId);
! ! engine.removeSeriesData(seriesData);
! ! renderer.render();
Although this code is not bad, it is
!}
rigid. To operate on the series object,
};
access always needs to be through
chart.removeSeries(seriesId);
the top of the hierarchy: the chart.

Without the use of events, this logic
is necessary for methods to ﬁre in
the correct order.

Event Versatility
series = {
! remove: function(){
! ! this.emit('remove-series', this);
this.destroy();
!}
};
graph = {
! on('remove-series', function(series){
! ! delete this.seriesMap[series.id];
! }, this);
};
chart = {
! on('remove-series', function(series){
! ! engine.removeSeriesData(series.data);
! ! renderer.render();
! }, this);
};
series = chart.getSeriesById(serieId);
series.remove();
series.isSelected(true);
series.addData([4,5,6]);

Here, remove() can be called directly
on the series, from anywhere inside
or outside of the chart, and events
will bubble up in the correct order.
This also makes sense semantically,
as series methods are called on the
series, and not the chart.

Refactor!
Always Be Refactoring

ABR

Little projects always become BIG projects
You will never have all the information up front
Sales can turn your app into Frankenstein
Practice defensive coding - build it knowing it will
change
Use best practices and your code will be maintainable and more enjoyable to work with
In spite of what you might think, you don’t have the
time to NOT do it right the ﬁrst time

http:/
/www.slideshare.net/anm8tr
http:/
/www.meetup.com/Club-AJAX/
https:/
/twitter.com/clubajax

http:/
/clubajax.org/

Professional JavaScript: AntiPatterns

Professional JavaScript: AntiPatterns

More Related Content

What's hot

Similar to Professional JavaScript: AntiPatterns

More from Mike Wilcox

Recently uploaded

Professional JavaScript: AntiPatterns