Open thadk opened 10 years ago
I created an example gist of my module and I reworked it from the Readme.md, perhaps slightly more readable:
+1 to this!
+1
+1
+1
+1
:pineapple:
+1
I've built a fairly big project with this generator, and one of the major pain points is the proliferation of files into a handful of folders. I was scrolling endlessly to find what I needed.
I'm currently building parts of an app using requirejs and backbone.marionette and the methodology that I've currently landed at is as follows:
In each modular app I reference modules in the other modular apps via alias paths (in require.paths config); e.g.:
// From within some other app other than above apps
require.config({
paths: {
// ...
ma1: '../modular-app-1/src',
ma1_tmpl: '../modular-app-1/templates',
ma2: '../modular-app-2/src',
ma2_tmpl: '../modular-app-2/templates'
// ...
}
Now included module calls look like ma1/modules/HelloWorldModule
.
Here's an example of running all three apps from another app:
// If you've added initializers to your modules they will automatically initialize when
you call their app starts. There by allowing you to compose the apps as you
please and still have them exist separately from each other (I can vouch for this,
builds nicely, and allows you to really modularize your apps even have separate
builds/distros of each (if necessary)!)
define([
'ma1/application',
'ma2/application',
'ma3/application',
'this-apps-path/application',
'ma1/modules/SomeModule',
'ma2/modules/AnotherModule',
'ma3/modules/AnotherModule',
'this-apps-path/modules/TestingModule'
],
function (ma1_app, ma2_app, ma3_app, app) {
$(function () {
ma1_app.start();
ma2_app.start();
ma3_app.start();
app.start();
});
});
The only thing to remember with this paradigm is that each modular app will have to use a path alias for itself (makes app's paths unique within modular-app-sphere): modular-app-1
is using ma1/...
, modular-app-2
is using ma2/...
, and the includer app is using it's own path (this-apps-path
). Then all app'ed up composition apps have to do to use other apps is define their path aliases in their require paths config; e.g., (example above)
So I agree with @thadk having a feature like this in generator-marionette (or any framework generator-...) would greatly help development flow and also help dev's in wrangling their application architectures more easily. :+1:
I'll will put this feature into the roadmap for my branch of generator-marionette.
+1
+1
I have been lurking in Marionette 2.0's gitter chat room (https://gitter.im/marionettejs/backbone.marionette) and I noticed this new starter kit: https://github.com/thejameskyle/marionette-starter-kit
It isn't as automatable as this example and doesn't use real App modules, but in lieu of a full upgrade for generator-marionette, it could be a good starting point for new projects. The author is responsive.
One bonus is that it uses Browserify instead of requirejs, though it hasn't gone the whole way of using Gulp rather than Grunt.
For app modules I would also include templates, unit tests and css in there.
On my last project I used this generator as a basis to parse out and follow Brian Mann's proposed Marionette app structure from his elegant-but-huge Rdio app (vid) (slides) that is now featured on Marionette's homepage. _Be prepared for the thought bomb._ Much is only covered in the audio.
The main difference from what we have here and over on this generator fork that adds modules is that his Marionette components are laid out and scoped by AppModules. As Brian Mann says, individual AppModules and isolated (Bower or otherwise) Components are the gateways to essentially all internal app interaction.
Here was my fairly successful folder structure:
_Any comments? Is this a decent way to implement scoped AppModules productively that we could consider implementing in the mainline generator?_
I feel like Brian Mann's pattern reflects the best thinking from Ember.js and other parts of the javascript/rails ecosystem and it is nice to work with that within Marionette.
(We used this structure with a standard backbone backend PaaS API implemented with Kinvey rather than Rails as BM advocates.)
Brian Mann's outer structure:![The big structure](https://speakerd.s3.amazonaws.com/presentations/bc2d3b60dcf501301ff46e142f2c2d05/slide_79.jpg?1375377243)
Brian Mann's inner structure:![The detail structure](https://speakerd.s3.amazonaws.com/presentations/bc2d3b60dcf501301ff46e142f2c2d05/slide_94.jpg?1375377243)