Provide a better way with dealing with missing modules in debug mode

[zephraph]

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.

[j3tan]

The intention was to bring immediate problems like missing modules to the developers attention as soon as possible. If a module being initialized is missing, then a part of the page is essentially broken. That can sometimes be a minor inconvenience, but sometimes could be a major problem. The framework really can't differentiate the two so it errs on the side of more caution in debug mode.

[zephraph]

I understand. I also completely agree with the concept. It's just proving to be a bit painful in our current working environment. Thanks though.

[zephraph]

While I understand the position on this topic, I'd like to try to determine potential alternatives. This has become a reoccurring issue on our team and is costing us valuable dev cycles.

We have a set of environments that we develop against and we use a proxy to swap out our js files during development. When multiple components are being worked on simultaneously on an environment and a developer tries to proxy in his or her code it's usually missing a module (i.e. one that's being developed by someone else). Ultimately this leads to our developers either not developing with debug enabled or having to create temporary files that add empty modules just to get their module to load.

For our purpose, a warning would be much more beneficial. Is there a potential way that we can make the error method itself configurable?

The ideas I've come up with so far aren't necessarily the best. One would be adding an Override object onto the Box namespace that can be used to override error.

// In user code
Box.Override.error = () => ...

// In Application.js
var error = Box.Override.error || fuction() { /* Normal error code */ }

It's a bit ugly, not ideal but it is middle ground.

[j3tan]

It's an odd use case. Can you create a stub file that is checked in but .gitignored? i.e. developers have their own version of a stubs.js

// stubs.js
Box.Application.addModule('missing-module', function() {});

Alternatively, there could be something like:

Box.Application.setErrorHandler(function(exception) { ... });

The downside of this is that you'll have to call this before you call Box.Application.init()

Even less optimal would be passing in a callback as a parameter to Box.Application.init({})

[zephraph]

I think the second option is the most ideal.

Box.Application.setErrorHandler(function(exception) { ... });

That would work really well for me. If you're open to the change I'll do the work in a PR.

[j3tan]

I'm good with the second approach. Thanks!

[zephraph]

Implemented in #181.

[zephraph]

Being as #181 is well under way, I'm going to close this issue. Thanks for working with us!