CoffeeScript design patterns and file organization

Vote count:

0

Hello stackoverflow community!

A quick heads up before I ask my question. This is my first post to the site, so I hope I am staying within the question guidelines. Also, my apologies that I am somewhat new to the subject area of my question, but I have been doing quite a bit of research to grow in this area. The particular area is client-side web development.

First, let me explain a little about where I am at, and then I will ask my questions near the end. I am building a web application which is going to be primarily event-driven (heavy on the CoffeeScript). It won’t be a HUGE, but I expect it to grow fairly large over time. It will mostly be for reporting data and allowing actions to be performed on that data from the UI. That said, I want to establish the client code following clean modular design. I haven’t had the green light to pursue JS frameworks yet, but in the future I may (however I am using jQuery). I am aware that incorporating frameworks may solve some of this challenge. Also, on the server side I am using ColdFusion (so I unfortunately don’t have access to built-in assets-handling).

So far, I have incorporated these design patterns: Module, and pub/sub for inter-module communication (using this implementation http://ift.tt/1ojq9G6). I want the different logical modules of the application to be as independent and stand-alone as possible. For me, a logical module really stems from the UI (as the code below shows I have a module for search which will eventually be a used to search for results, other modules for the rest of the UI elements will follow suit). I liked the idea of modules publishing messages if they want to notify their state changed, and let the subscribing modules do what they will with it. This follows more of an observational pattern one would see in platform application development (which is how I like to think about CoffeeScript and jQuery together as opposed to static html). My thinking is that modularizing the code like this up front will pay off as we build more and more modules and need to maintain them (or swap them in/out).

Here is an example of how I am laying out the code:

coffee/common.coffee

# setup sub/pub methods

(($) ->
    o = $({})
    $.subscribe = ->
        o.on.apply o, arguments
    $.unsubscribe = ->
        o.off.apply o, arguments
    $.publish = ->
        o.trigger.apply o, arguments
)(jQuery)

# initialize objects to hold all modules and functions

modules = {}
functions = {}

# initializes a list of modules

functions.initModules = (dependencies) ->
    for name in dependencies
        if modules[name].init
            modules[name].init()

# runs once the document is ready

functions.applicationStart = ->
    # get the page and load any of its dependent modules, using the body class to determine the page
    page = $('body')[0].classList[0]
    if (page.length > 0 and modules[page])
        modules[page].init()

coffee/modules/search.coffee

# an example of a module

modules.search = do ->
    init = ->
        $('#search').click ->
            $.publish '/event/search', 'you clicked search'
    init: init

coffee/modules/list.coffee

modules.list = do ->
    init = ->
        $.subscribe '/event/search', (e, args) ->
            console.log args
    init: init

coffee/modules/examplePage.coffee

# an example of a page module (with dependencies)
# this is being done so the same js file can run different modules for different web pages

modules.examplePage  = do ->
    dependencies = ['search']
    init = ->
        functions.initModules dependencies
    init: init

**coffee/main.coffee**

$(document).ready functions.applicationStart

======

I am building and watching all these files into 1 js file using a command like this: coffee -j js/app.js -cw coffee/common.coffee coffee/modules/* coffee/main.coffee

======

Here are my questions about the way I am doing this:

1. Is the way I am handling modules communicating with modules in other files following best practice? If not, is there an alternative that may be better? I am basically struggling with how to organize. Since there seems to be so many flavors and variations out there, it’s hard to know without the experience to go behind me.


2. Each module file is making assumptions about the existence of a modules object. Maybe this is something that is OK and the right way to do it?


3. Since I heard the CoffeeScript maintainers are deprecating –j for joining files, I need to find another method. I attempted to use Grunt, but the dev environment I use is on a server and runs surprisingly too slow. Does anyone know of alternative to compile/watch coffeescript and build the files in the correct order? Is there any best practices to this?


4. Also, general spot checks from more experienced people :)

Best regards,

Josh

asked 1 min ago

Joshua Eilers

1

CoffeeScript design patterns and file organization