Javascript part three: “very component oriented”

Find back articles from this serie...
1/ Javascript part one: "very object oriented"
2/ Javascript part two: "very package oriented"
2/ Javascript part three: "very component oriented"

It’s not easy to understand what we call component approach

 

Component approach

This is kind of « module pattern » but more limited.

Even by googling component pattern javascript you won’t find anything yet.

Some resources about object patterns in javascript: http://link.lightjs.org/modulepattern

It’s the approach used by the famous D3.js library by Mike Bostock.

Let’s understand how it’s working: if you are familiar with object pattern, you should know what is public / private variables and public / private methods.

Components are the best tool to respect it!

 

Axis D3 component example

You begin by creating a scope with one function, the constructor: [cc lang= »javascript »]d3.svg.axis = function() {
function axis() { console.log(‘I draw an axis!’) }
}[/cc]

Then, you inject your private variables and private methods.

[cc lang= »javascript »]
d3.svg.axis = function() {
function axis() { console.log(‘I draw an axis!’) }
var scale = d3.anothercomponent; // not callable from outside
function ping() { return ‘pong’ }; // not callable from outside
}
[/cc]

Now, come the « public methods » which can be accessor to your private variables.

And return the object.

[cc lang= »javascript »]
d3.svg.axis = function() {
// — constructor
function axis() { console.log(‘I draw an axis!’) }

// — private section
var scale = d3.anothercomponent;
function ping() { return ‘pong’ };

// — public section
axis.getscale = function() { return scale; }
axis.constant = ’42’;

// — return the entire object
return axis;
}
[/cc]

You get a component with all (private | public) && (variables | methods).

This pseudo pattern is not my favorite because it enclosed too much the code into object and complicates interactions with other components. A better pattern should support privates entities but still make it accessible from outside.

General willing is to well scope and get a clear separation between private and public but not hide or block anything. A softer approach could be an addition of « _ » before the first character of private variables like axis._scale

Just a mind, not a rule but I don’t like this pattern, it reduces javascript capabilities! Very adapted for D3.js, component approach match svg drawing loop and make structure very clear but don’t use it for bigger project!