DRYing Out Your Client-Side Apps

DRYing out
your client-side apps
Sunday, February 12, 12

View Slide

hello!
’ Garann (like Karen with a G) Means
’ Austin All-Girl Hack Night + Girl Develop It Austin
’ Node for Front-End Developers (O’Reilly)
’ [email protected] or @garannm

View Slide

so node is pretty great, right?

View Slide

and why?
’ fast!
’ evented!
’ super easy to set up!
’ awesome dev community!
’ reusable application code!

View Slide

maybe a little trickier
’ fast!
’ evented!
’ super easy to set up!
’ awesome dev community!
’ reusable application code!

View Slide

we never needed that before
’ client-side strictly presentational
’ DHTML
’ Ajax
’ explosion of JS libraries
’ client-side apps

View Slide

we never had anything to reuse*

View Slide

attempting reuse with a traditional
server
’ server-side interpreters
’ compiled versions of logic for client
’ limited vocabulary that can be truly shared

View Slide

things we can reuse
’ models
’ views/templates
’ route patterns
’ external or third-party utilities

View Slide

caveats
’ essentially one way to import in node
’ modules have to check their context
’ may need to be both synchronous and asynchronous
’ user interaction has to be abstracted
’ no global scope on the server

View Slide

the whats

View Slide

models
’ easy-peasy!
’ sensible and simple to structure data same way
’ validation and rendering signatures can be the same
’ (even if functionality differs)

View Slide

models
function Model( config ) {
var that = {
thing: config.thing,
stuff: config.stuff || []
};
that.validate = function() {
if ( that.stuff.length ) return true;
}
return that;
}

View Slide

server
socket.on( “modelUpdated”, function( data ) {
var m = new Model( data );
if ( !m.validate() ) {
socket.emit( “badData”, { message: “onoez” } );
}
});

View Slide

client
btn.addEventListener( “click”, function() {
var m = new Model({
thing: txtField.value,
stuff: convenientlyDefinedArray
});
if ( m.validate() ) {
socket.emit ( “modelUpdated”, m );
} else {
alert( “Oops - not enough stuff!” );
}
});

View Slide

templates
’ not all JS templates work client/server
’ all can be *made* to work client/server
’ used differently, loaded differently

View Slide

server
’ maximize size
’ minimize requests
’ child templates as dependencies
’ no need to cache
’ response has to wait for loading, compositing, rendering

View Slide

client
’ minimize size
’ minimize DOM interaction
’ swap out small bits of innerHTML
’ caching probably important
’ may be re-rendering constantly

View Slide

routes
’ generic functions or publish/subscribe
’ probably need to abstract input and output
’ RPC/RMI may substitute

View Slide

routes
namespace.save = function( input, output ) {
output.render ( “save”, input );
}

View Slide

server
app.get( “/save”, function( req, res ) {
routes.save( req.body, res );
});

View Slide

client
var formData = serializeData( “#myForm” );
routes.save( formData, myRenderer );
});
var myRenderer = function() {
this.render = function( tmplName, data ) {
document.querySelector( “#page” ).innerHTML =
tmplEngine.template( tmplName, data );
};
};

View Slide

alternatively..
namespace.save = function( input ) {
pubsub.publish( “loadSave”, input );
};

View Slide

utilities
’ client-side utils may rely on a global namespace
’ node modules probably expect exports
’ like templates, can be *made* to work bi-directionally

View Slide

the hows

View Slide

generally..
’ ﬁles live on client
’ pretend you never heard of global scope
’ everything decoupled from DOM*
’ pass reference to anything with state

View Slide

1. create server-side DOM
2. ???
3. profit

View Slide

server-side DOM
’ existing tools to create DOM in V8
’ slow
’ server-side DOM rarely needed
’ for entire apps, almost never
’ have to replace or trigger user interactions

View Slide

perfect candidates
’ testing
’ spidering
’ scraping
’ anything that requires parsing markup

View Slide

WTF candidates
’ games
’ visual editors
’ anything where markup is merely the ﬁnal representation
’ anything highly interactive

View Slide

where it gets used
’ templates
’ build up DOM with reference to elements (vs. string)
’ events “belong” to elements
’ existing client-side apps
’ quick n’ dirty

View Slide

write once, import twice

View Slide

require.js and r.js
’ node’s require is subtly different
’ formal dependency management solves namespace issue
’ kind of
’ text! preﬁx for loading unexecuted code

View Slide

server
var requirejs = require( “requirejs” );
requirejs.config( { nodeRequire: require } );
requirejs( [“thing1”, “thing2”],
function( t1, t2 ) {
// whatever..
});
requirejs( [“text!public/template.html”],
function( tmpl ) {
// whatever (rendering version)..
});

View Slide

client

 requirejs( [“thing1”, “thing2”], function( t1, t2 ) { // whatever.. }); requirejs( [“text!public/template.html”], function( tmpl ) { // whatever (rendering version).. }); 

View Slide

exports || namespace
’ everything in an IIFE
’ pass in scope
’ requires hard-coding client namespace

View Slide

exports || namespace
(function( ns ) {
ns.thing = function() {
// whatever..
};
return ns;
}( ( typeof process !== "undefined" &&
process.title === "node" )
? exports : clientNamespace ));

View Slide

Remote procedure calls

View Slide

RPC/rmi
’ write code once to run in two places
’ both, not either
’ pass control with callbacks (which node needs anyway)

View Slide

server
var dnode = require( “dnode” );
dnode( function( client, connection ) {
this.biznessLogic = function() {
// whatever..
}
}).listen( 1337 );

View Slide

client
var dnode = require( “dnode” );
dnode.connect( function( remote ) {
remote.biznessLogic();
});
});

View Slide

end-to-end frameworks

View Slide

the future
’ assembling this stuff by hand is silly
’ reuse should be the default
’ room for many frameworks, many methodologies

View Slide

how would that look?
’ build step required?
’ framework creates server
’ server generates client-side assets from server code
’ controllers wrap RPC/RMI calls

View Slide

full-stack solutions
’ batman.js
’ derby.js
’ ﬂatiron.js
’ thorax.js
’ drumkit.js
’ zomg: http://toolbox.no.de/categories/Frameworks

View Slide

changing everything
’ trying to do this since early 2000s, at least
’ and it’s sucked
’ browsers behaving more like servers
’ sockets, storage, I/O
’ and servers behaving more like browsers
’ \m/, JavaScript ,\m/

View Slide

why the proliferation?
’ everyone coming to the same conclusion at once
’ different needs, but not really
’ different preferences
’ which ﬁts your needs?

View Slide

lots of ways to share code
’ which pieces do you have?
’ which are crucial and which are “glue”?
’ e.g. templates may be unrelated to biz logic
’ are there constraints to how they’re handled?
’ e.g. maybe you can’t jump to a route/state by URL

View Slide

bottom line: Don’t repeat yourself
’ no reason to run logic on a different side than it’s used
’ no reason to duplicate code

View Slide

thanks!

View Slide

— image credits —
’ http://www.flickr.com/photos/breakfastcore/2285501111/
’ http://www.flickr.com/photos/bondidwhat/6114903414/
’ http://www.flickr.com/photos/rchappo2002/2694370462/
’ http://www.flickr.com/photos/[email protected]/4188316428/
’ http://www.flickr.com/photos/blackcountrymuseums/5218004706/
’ http://www.flickr.com/photos/catechism/3001280935/
’ http://www.flickr.com/photos/murrus/2344711309/
’ http://www.flickr.com/photos/carbonated/2105145079/

View Slide

DRYing Out Your Client-Side Apps

DRYing Out Your Client-Side Apps

Garann Means

More Decks by Garann Means

Other Decks in Technology

Featured

Transcript