A few people have commented that since we use jQuery just for event handling, then it's possible to extract that out so jQuery is no longer a hard dependency. This is a great idea!

In the discussions within our team, we talked a bit about the preferred approach to doing so. #17 was proposed, but the general feeling was that we don't want to bake jQuery detection into the core of T3. So, we'd like to consider another option where we created something like this:

Box.Events = {
    on: function(element, type, listener) {},
    off: function(element, type, listenter) {}
};

Then, we can have both a jQuery version and a native version, while the core of T3 relies on Box.Events.on/off instead of either native or jQuery.

The remaining question is how best to work that into the bundled version in /dist.

Recently we discovered a ~6mo old bug in our system that was able to persist because T3 silently allowed a features flip service that didn't exist to be retrieved and used as a falsey value in subsequent logic. This could have been identified if T3 had thrown upon attempting to fetch the service, or at least dumped to conosle.warn when in debug mode to at least let a developer know they're attempting to access a service that does not exist.

For code cleanliness console statements can then later be stripped out during our build process with the drop_console flag when the code is minified for production use.

Hi there,

Do you think that T3 needs a Yeoman generator to generate some modules, services and behaviors?

Looking for some interesting ideas,

Thanks,

Barış Güler

I love ReactJS but it basically only renders View and I still need the other things like event handling, etc. It seems T3 has very simple and elegant idea. I tried a bit tonight with T3 + ReactJS. One thing I did notice is that when I run Box.Application.init, it expects that all the elements with data-module attributes are already added to Box.Application.

It seems I've found that componentWillMount is a good place to write Box.Application.addModule and in componentDidMount, you can run Box.Application.init.

I attached my code below. Do you think this is the proper way to use T3 and ReactJS? Thank you!

           var CommentBox = React.createClass({
                getInitialState: function() {
                    return {
                        showSubmit: true
                    };
                },

                componentWillMount: function() {
                    var r = this;
                    Box.Application.addModule('comment-box', function(context) {

                        // private methods here
                        return {

                            init: function() {
                                // capture the reference when the module is started
                                moduleEl = context.getElement();
                                console.log(moduleEl);
                            },

                            onclick: function(event, element, elementType) {
                                if (elementType == 'submit-btn') {
                                    r.setState({showSubmit: false});
                                    context.broadcast('submit', 'Submitted!');
                                } else if (elementType == 'close-btn') {
                                    r.setState({showSubmit: true});
                                    context.broadcast('close', 'Closed!');
                                }
                            }

                        };
                    });
                },

                render: function() {
                    return (
                        <div className="commentBox" data-module="comment-box">
                            <input type="text" />
                            {this.state.showSubmit ? <button data-type="submit-btn">Submit</button> : <button type="button" data-type="close-btn">Close</button>}
                        </div>
                    );
                }
            });

            var Article = React.createClass({
                getInitialState: function() {
                    return {text: ''};
                },

                componentWillMount: function() {
                    var r = this;
                    Box.Application.addModule('article', function(context) {
                        return {
                            messages: ['submit', 'close'],

                            onmessage: function(name, data) {
                                if (name == 'submit') {
                                    r.setState({text: 'submit: ' + data});
                                } else if (name == 'close') {
                                    r.setState({text: 'close: ' + data});
                                }
                            }
                        };
                    });
                },

                render: function() {
                    return (
                        <div data-module="article">
                            <p>{this.state.text}</p>
                        </div>
                    );
                }
            });

            var UI = React.createClass({
                componentDidMount: function() {
                    Box.Application.init({debug: true});
                },

                render: function() {
                    return (
                        <div>
                            <CommentBox />
                            <Article />
                        </div>
                    );
                }
            });

            React.render(
                <UI />,
                document.getElementById('content')
            );

Address issues raised in #12, especially strong jQuery dependency.

Box team might have bigger fish to fry, so open a pull request here to signal someone is working on it.

Now it works, I end up doing following changes:

1. Abstract event system into addListener and removeListener, still prefer jQuery over native add/removeEventListener, but allow seamless fallback.
2. Update karma config and use mocha reporter instead of progress, this is good because progress does not show which test fails when you do sandbox.verifyAndRestore in afterEach; though generally one should avoid assert (sandbox.verify is implied assert) in afterEach because it cause mocha to abort all subsequent tests.
3. Update test cases so that it no longer depends on jQuery in global space, by jQuery.noConflict at the start. Note that we still test for jQuery global, see tests for on[event]()
4. Update travis to include node v0.12 and latest iojs

Hi guys! I miss working with you, but I'm still using T3 on a daily basis with my clients!! :)

I'm wondering if there is a way you can share some of your JSDoc configurations for Modules, Services, and Behaviors. I'm having a really hard time trying to setup the proper tags so that all of my modules, services, and behaviors get grouped together in the documentation.

Can you offer any guidance for tools, configs, and jsdoc tags that would allow me to have namespaces for "Modules", "Services", and "Behaviors", and then have those contain all of the classes of those types?

Thanks! Adam

• adding proxyquire for testing browserified source files
• modified tests to use CommonJS
• modified build process to account for browserification
• downgraded karma-coverage to 0.2.6 to support browserify-istanbul
• updated ESLint rules to account for CommonJS changes

fixes #24

I think that may be more effective to check on circular dependencies only during instantiation of service. When an instance of service already exists we should immediately return it.

P.S. Changes only in lib/application.js file

I understand Box.com might be using jQuery features extensively, but if T3's idea is to stay modular, then why not decouple jQuery as well.

Looking at the documents (apologize if I missed something), it seems jQuery would be used for data-binding, but there can be lots of approach to data-binding, not to mention virtual-dom approach (where binding is handled differently)

Seems like T3 can be done without jQuery, or at least with alternatives like DOMtastic.

Either way, I am just very excited to see a framework that takes progressive enhancement into account and I am very interested in using it for my current project.

Currently when a module is missing in debug mode an exception is thrown. That's all well and good, but it prevents T3 from continuing its initialization. We have a situation where multiple engineers will be working on one environment and sometimes they use a proxy to make a local version of their script to the page which may not have a module that the dom for that environment has listed. This is fine in non-debug mode, but when debug is enabled it completely borks the process.

Granted I realize our development process at the moment may be more at fault then how T3 functions, but it would be nice to be able to see the error but not have T3 stop the initialization process when that error occurs.

Currently when one wants to handle messages or events they add something like the following

return {
  onmessage: function(name, data) {
     switch(name) {
        case 'test-message': test(data);
        break;
        // ...
     }
  }
}

Something like that, right? Well, maybe instead of a switch an if else statements is used. Regardless, that breakdown is up to the individual who implements the module/behavior/service in question.

I pulled this straight from the docs:

Don't include application logic in the event handler. Everything the module is capable of doing should be represented as a method on the object and the event handler should call out to those methods.

This interface doesn't naturally support that. On the contrary, I feel like it encourages the bad practice of handling all cases directly inside that method.

I'm proposing an improvement to message/event handling where an object can be passed to on* as an alternative to passing a function.

Example

return {
  onmessage: {
    'test-message': function(name, data) {
     }
  }
}

This interface ensures that there's a function that handles every message instead of a single function that handles all messages. There's no noisy if or switch statements to deal with. The other thing this setup makes me think is, now that it's known what messages are being handled by the T3 construct, it's not necessary to specify messages at all because that'd just be redundant. T3 can just scrape the messages off the onmessage object.

My current proposal isn't to get rid of messages or the fact that onmessage or onclick can be a function. It's really just the addition for something like onmessage to be an object. Though, I will say that given the next "major" release, which might be a while from now, it would be good to consider the former points.

Thoughts?