I'm about to be working on a very large site, and it's going to have quite a
bit of Javascript. My goals for this project are the following:
1. Loose coupling of page components
2. Dom Ready Execution for components
3. Clean file organization (but let's keep all these recommendations on
Garren's Javascript File Organisation thread)
Here's some resources I've found that have been helpful so far, that have given
me some ideas.
Functionality Focused Code Organization - Rebecca Murphey
Terrific overview of the problem I'm facing. This is a great deck that
explains exactly the sort of thing I'm trying to prevent and how i might like
to do things.
Dom Ready Execution for components
For current projects I have a single jQuery dom ready execution $(function() {
APP.onLoad(); }); The onLoad also accepts functions as params, which queues up
those function in an array. When you call onLoad without any arguments, it runs
through the queue and executes all those queued up functions. This allows us to
have a single dom ready execution handler.
One issues I have with this is that there is no way to prioritize functions
passed in to queue up. So order of execution is dependent on what order your JS
files are loaded on the page, and then what order your components are defined
in those files. Paul's idea has a way to handle running less important tasks at
a later time which I may incorporate into the onLoad function.
Markup-based unobtrusive comprehensive DOM-ready execution - Paul Irish
I really like this as it completely removes having to have any
javascript login on the page that knows which components need to be run.I'm
still trying to figure out how this would work with page components though. For
example, say you have a feedback tab (think getsatisfaction) attached to the
right side of the page. Every page will need to initialize the Feedback
component's javascript. Would you add feedback as a class to the body class
attribute? Basically all components go into the body class?
Loose Coupling of Page Components
For current projects, I have it so that all page components are in their own
namespace and are either an object literal or an IIFE to keep all logic in one
place. I then handle component to component communication using jQuery custom
events which works will on keeping them decoupled but having to use the dom is
silly. Using pubsub will be much better. To initialize each component i call
APP.onLoad(APP.Component.init), which queues up that components initialization
function to run once the dom has been completed.
Scalable JavaScript Application Architecture - Nicholas Zakas
Some really great concepts in this deck, by our very own Nicholas
Zakas. He confirms my thought that everything on the page should be divided
into modules or components. Each component only has knowledge of the component
sandbox, they don't know about any other components. Components communicate
using the component sandbox. I'm thinking the sandbox works as a pubsub
manager, where components can subscribe to events via the sandbox. Different
components fire different events... One thing I wasn't completely sold on was
one part of the slide that said the components are completely decoupled from
the base library (jQuery, Dojo, YUI). I like being able to use $('selector') to
mess with the dom, and I think you should be able to do this within your
components.
Any one have any experience with using either of these two methodologies
mentioned in the provided links? What have you all found works will for
structuring your large javascript applications and keeping the code organized.?
Finally, how do you kick off your javascript execution?
-Brian Wigginton
--
To view archived discussions from the original JSMentors Mailman list:
http://www.mail-archive.com/[email protected]/
To search via a non-Google archive, visit here:
http://www.mail-archive.com/[email protected]/
To unsubscribe from this group, send email to
[email protected]
