I am using requirejs so that I don't have every single script in the head tag for every page. The main motive behind switching to use requirejs is that we have plugins such as CodeMirror, with like 15 plugins to extend that too.
What I want to avoid is having for example:
require(["cm", "cmxml", "cmcss", "cmcodefold", "cmfoldgutter", "cmbracefold", "cmcommentfold" ....], fn);
I'd like to have this as just require(["cm"], fn); and automatically include all of the plugins with this. I'd also like to keep the plugins separate, so combining all the files into CodeMirror.js is not an option.
What I am wondering, before I go creating my own functions or modifying 3rd party code for this, is whether requirejs allows this kind of loading in any case? I have looked at the docs a lot and can't find anything, but that doesn't mean I haven't missed it or that it isn't documented. Thanks in advance.
Well I've managed to get this working using a shim for a script called cminit.js - the deps array simply lists all of the plugins for CodeMirror, which in turn have a dependency on CodeMirror which in turn has a dependency on jQuery. So one call to require for cminit.js automagically means that jQuery exists.
It works, but I'm not sure how much of this is best practice. Feel free to comment if you have a better way to do this.
Related
I'm building a project in javascript, using paper.js in some features.
Most of my project is built in vanilla Javascript, just some minimum but important features are built with paper.js
The problem is that the library (.min library) is 200kb.
The normal library is 300kb, I was wondering if there is an automatic way to see which functions are being used in the main paper.js library, in order to delete the useless functions.
If there is no program or automatic way to do this, maybe some advice of how to do it manually, or which tools you recommend for me and my team in order to delete useless functions, then minify the file and run it smaller.
Thank you all guys, I did not added any specific code because I want this anwser to be global.
Greetings
You have to do it manually but it's not an easy (and certainly not quick) process. You'll have to find which functions you're using and then find whatever classes or functions those functions reference. You would probably have an easier time creating a new script then copy/pasting what you're using (and any referenced content) then running it with your script, log errors, and repeat.
When you're done there's many minify libraries and services online you can use to minify the new script.
I used the paper-core version and then minified.
I saved 140kb by doing this.
There's still no way to see useless functions in this library
I have new challange to solve. We would like to create many application with same JS code and base on parameter load different theme and maybe do some extra things for specified value. This I guess is not a problem by adding a parameter at build process and just check it while render.
Question is how to deal with this on native code. I was thinking about copy&paste ios/andoroid code and change all required parameters, name etc, but it sounds like not best approach. Do anyone have idea how to deal with this problem ?
Thanks in advance for help.
I’d suggest you to create a component library that exports shared components for reusability.
For theming you could use the theming library that distributes a theme object in the context including subscriptions to changes. https://www.npmjs.com/package/theming
Libraries like styled-components and glamorous-native already have this built into them.
One thing to note is that you shouldn’t forget to use peerDependencies while pulling all reused dependencies into devDependencies so that you won’t end up with duplicated packages in any case.
I publish a library called DataTables and I'm looking to improve how it works with package managers for the next set of releases. RequireJS is the one i'm specifically looking at just now. Building the Javascript AMD support for RequireJS in DataTables is relatively simple, however, DataTables doesn't really make a lot of sense without some styling.
I publish a number of styling integrations (Bootstrap, Foundation, jQuery UI and DataTables own default with others planned) so I'd like to have something like require(['jquery', 'datatables.net-bs'], ... ); which will include DataTables and the Bootstrap styling for DataTables.
I could simply list a bunch of <link> tags for folks to include, but if I do that, I might as well just publish the <script> tags and forego RequireJS altogether.
I know that CSS is not supported by the RequireJS core, but I was hoping to use the require-css plug-in. That works well, but I can't find a way to have a module name include both the JS and CSS.
I found that the config.paths option for a module could specify multiple files in an array, so I tried:
'datatables.net-bs': [
'require-css!//nightly.datatables.net/css/dataTables.bootstrap.min',
'//nightly.datatables.net/js/dataTables.bootstrap.min',
]
But the plug-ins operate on the module name, not the path. I had a look at the plug-ins API but can't see an option to add a plug-in at that point (unless anyone knows better)?
If that isn't the best approach, can anyone suggest what is a better one?
This is what I have tried: http://jsfiddle.net/coaqsjkv/ - note that the CSS "plug-in" is not resolved at the path level giving a 404.
I could have the require list all the JS files and CSS files needed - but that seems very verbose (three files for DataTables with Bootstrap styling for example).
Any insights very welcome.
i can't find any definitive answer on the boilerplate docs, but can someone clarify the difference between plugins.js, and script.js? i'm a javascript newbie, and am tempted to just put all my scripts in one file... is there a good reason not to do this?
From the FAQ:
Script.js should hold your primary application script. It might make sense to store it in an object literal and execute it based on body classes.
Plugins I use for jQuery plugins and other 3rd party scripts myself. I put the jQuery plugins inside of the (function($){ ... })(jQuery); closure to make sure they're in the jQuery namespace safety blanket, especially if they were written by more amateur developers. See also jQuery Plugin Authoring.
in plugins.js file you get few helpers bundled, it's probably meant to include stuff you won't modify at all (or at least not so often), while script.js is a file ready for your... yes, scripts. ;)
what you said is true - in production, it's usually better to serve the browser one file instead of many. however in development it's easier to keep things separated.
that's the reason why boilerplate comes with a build script, which combines all your scripts into one so you don't have to worry about this.
in scripts -> your custom scripts
in plugings -> don't touch it!
In build process both files unite into one unique and compressed file...
When building a jQuery plugin, do you think it's bad practice to embed the source of another plugin or library that it depends on?
It seems to me that it's a better way to go than requiring users to do multiple <script src="..."> calls or compressing the multiple source files themselves.
I would stay away from embedded in most cases, especially if you're depending on another jQuery plugin. Some cases to consider:
What if I'm already using that plugin, a newer version, an older one?
At best you're adding the download weight twice, possibly a different version
At worst you're breaking my code :)
What if I'm trying to debug, is a bug in your plugin?, the other?, still yours because you included it?
Which author do I contact?
There are few upsides to this besides saving a few <script> tags, which should be cached on the client anyway...and in my case as well as many others (like SO) the scripts get compressed into one or a few requests.
Most jQuery plugins require dependencies to be added with their own <script> tags, in this case by not going with what most do serves more to confuse or complicate rather than save time. Personally, I'd stay away from the embedding, but to each their own.
Personally, as a potential plugin user, I'd prefer the multiple <script src='...'> way. First, it gives me more flexibility and control and second, if I already have some of the plugins in my own code, having them in your plugin as well means they'll be included twice.
Imagine what would happen if every plugin author included all dependencies in the source. What you think is convenient now will turn out to be a maintenance nightmare later.