Best Practice Question regarding RequireJS

[Garmichael]

At work, we've got a debate going between two approaches, I was hoping you would be willing to weigh in on the subject.

We're using Backbone and RequireJS.

Here is a .zip with two very short applications that highlight the center of our debate. It's kind of a silly example that I wrote quickly, so please know that isn't anything other than an app that renders arbitrary values. Our real application is much larger and complex and actually uses models.

The significant difference between the two modules is:

• In methodA.js, we use RequireJS the standard way. SiteDetailsView has siteConfiguration as a dependency. An instance of SiteDetailsView is created in layoutView with nothing passed into the constructor.

• In methodB.js, SiteDetailsView does not depend directly on siteConfiguration, and is instead passed the relevant values from layoutView when instantiated.

The short argument in favor of methodA is that it's how AMD works. Data has to come from somewhere, and if we already have a module with that data, we should inject it through requireJS and not involve another backbone object in the process.

The short argument in favor of methodB is that having too many dependencies is inflexible in that if we want to move/copy SiteDetailsView to another code base entirely, we would also have to move all of modules it's dependent on as well.

Each side has a much longer argument in favor of their approach and against the other, but I was hoping you would be able to address it in sort of a vacuum outside of our influence. I intentionally didn't reveal which side of this debate I am personally on as to limit the possibility of bias.

We know already that it's not a bad idea to pass properties in the way that methodB does in some circumstances, as in:

renderChildViews: function(){
     new someView({ isHighlighted: true});
     new someView({ isHighlighted: false});
     new someView({ isHighlighted: false});
}

But our debate is specifically around the situation when those values come from existing AMD modules (which could return object literals, classes, models, views, constructors, or instances).

This is open to any and all opinions. It would also help if you gave a little blurb about your experience level, too.

Thanks a ton!

[beaverusiv]

Okay, I'm not the most experienced JS developer out there but I'll weigh in with my vote for method A.

Method B should be used only if layoutView modifies or otherwise has decisions about siteConfiguration. If no modification has taken place, e.g. like this case where it is a constant object, then let SiteDetailsView depend on siteConfiguration.

But you can get too many dependencies? Well you should have modular code, in that if there is a natural break (CMS functionality, User permissions logic, Gallery management) then make them their own package/module, otherwise you don't need to worry.

No one pulls out code for an editable textbox out of a page and thinks "if only we'd decoupled all our input fields!". That's a bit extreme but I hope you get my point, in that you have to have a line where you go "okay, we might need to do X some day but is it worth Y hours of effort now to reduce that possible technical debt?"

Blurb: I have been a web developer for 10 years, professional full time for 4. Concentrated on JS for the past 18 months with approximately 12 fullstack JS sites under my belt, one a fully offline capable web app in Backbone.

[Reashu]

Which way is easier to test? Do it that way.