R.js: understand the optimizer r.js requirejs

Question

im trying to find out if he has a good idea to use r.js from require.js to create a build.js file from my javascript files to load only one file in production. But they are wondering if this is a good idea in my case, as it seems that it just loads absolutely everything in the DOM, using large memory. Perhaps I misunderstood it.

Take a look at one of my basic views implemented using require.js. As I know, r.js will take this file and optimize and put it in the final build.js file with all other views, models and collections defined in the same way.

define(function (require) { "use strict"; var $ = require('jquery'), _ = require('underscore'), Backbone = require('backbone'), tpl = require('text!tpl/start.html'), Mustache = require('mustache'), template = Mustache.compile(tpl); return Backbone.View.extend({ initialize: function () { }, render: function () { this.$el.html(template()); return this; }, events: { 'click #submit': "start" }, start: function (event) { // stuff to do ... } }); }); 

I think final build.js will just take my code above and include it in it, right? Thus, this means that when I update my index.html by loading require.js, my build.js file will simply load all the views, models and collections in the DOM. It does not take up too much memory, since I do not need everything to boot from the very beginning. Does it make sense to call require ("path / to / my / view") when it is already loaded through the build.js file?

Answer 1

It may not make sense in your application to optimize all the modules into a single file. r.js supports this scenario. What you need to do is use the modules parameter and define as many output files as you need. A general illustration of this may be:

 modules: [ { name: 'main', exclude: [ "viewA", "viewB" ], }, { name: 'viewA', exclude: ['core'] }, { name: 'viewB', exclude: ['core'] } ] 

The above setup assumes that the source to be optimized has modules named main , viewA and viewB . This would create 3 optimized packages: a core , which contains all the main modules that will be loaded anyway, viewA , which represents a group of modules to be loaded in circumstances one way or another, and viewB , which represents a group of modules, loaded in other circumstances .

How to configure your modules parameter depends on the specifics of your application.