I have a question around the dependency injection based on AngularJS and NodeJS.
There's any difference between $injector from AngularJS and the require module from NodeJS?
Would be nice use require module with a MEAN STACK architecture instead $injector for the Angular app? And for whar propose?
They're quite different.
Angular's $injector is a classic example of Inversion of contorl. Instead of each module fetching their dependencies, you have an $injector whose job it is to provide dependencies to the modules that are asking for them at run-time. This makes it really to easy switch out the dependencies in tests for example, since nothing is forcing you to pass in the expected dependency -- you could pass in a mock version.
NodeJS's require methods just allow you to require other javascript files and have access to any properties they set on module.exports.
They're not mutually exclusive. You could use browserify (nodejs like require for the front-end) to load the different Angular modules if they are in separate files. It would essentially be equivalent to concatenating them, however. If you wanted to dynamically load the angular modules as needed, you would have to use something like RequireJs.
Conversely, you can use inversion of control in node by passing stuff into a module rather than trying to fetch it from the module. It's actually good practice in many cases.
Related
I'm learning how to use Flux and I encountered the following line in the documentation: "We can use Node's EventEmitter to get started with a store."
I understand that you can use things like Browserify to do the bundling and minifying, grabbing all the dependencies that Node code has to make the bundled browser-compatible JS file. But what's bugging me right now is how you know what you can do this with. How do we know what Node code we're allowed to use in the browser?
So, first of all let's consider that when in node you have
JavaScript modules that are the 3rdParty modules written in JavaScript (ECMA5, ECMA6 and even TypeScript or CoffeScript) etc;
Node built-in module. Those are node Core modules like fs, path, util, etc.
native compiled module called Addons that are are
dynamically-linked shared objects, written in C or C++;
Then you have the packager / module bundlers
Browserify
Webpack
the transpilers i.e. source to source compilers that typicall will handle syntax tranforms like
Babel.js that shims modern JavaScript to legacy engines
and the techniques
ECMA5 Shim to support legacy JavaScript engines
HTML5 Cross-Browser Polyfills
Because you need to do polyfills if you want to transform not only syntax but even globals (like the Promise), so you combine transpiler to polyfill having like babel-polyfill
Finally we have different kind of modules design patterns (modules format) to be handled for the bundling process:
AMD modules format
CommonJS modules format
and formats that are not in those ones that must be bundled/shimmed - where possible - through custom loaders.
That said, native modules will not run in the browser: you cannot bundle a native module through Webpack. Ordinary modules will, but not all. This is due to several reasons. There are some specific methods that cannot be "browserified" or "webpacked". Let's take as example fs. Can you put this built-in module in the browser? There are some abstraction for that called brfs, that are transforms for built-in node apis fs.readFileSync() and fs.readFile(), so you will do
$ browserify -t brfs example/main.js > bundle.js
to get
var fs = require('fs');
var html = fs.readFileSync(__dirname + '/robot.html', 'utf8');
console.log(html);
This will not work for every non built-in modules, in the npm modules jungle, so WebPack has a module.noParse option to exclude Addons modules, non supported modules, etc. - see here about that.
So you have to look at the list of the transforms that means you can apply this transform to browserify to obtain like the fs transform mentioned above.
So that said, how do you know that a certain module will run in the browser? When you design your web application and Node backend you have to do opportunistic design choises to design shared modules/library that will run in both the environment, so being shimmed/packed at some point, like object models, application logic, etc., other modules that will deal with the File System I/O or will use native addons, so that will work in the server only, packing through wrappers it's possibile, but the behavior will look differently, as we have seen in the fs example above, and web specific modules, so it's a design matter.
A note can be added about networking modules i.e. node http, https that thanks to library abstractions like node request will run everywhere or using specific transforms like http-browserify.
I've got a site that doesn't use RequireJS. I load all of my code in <script> nodes index.html.
I found a module on NPM, azure-storage, that I'd like to use. However the js files in the module contain code that assumes that I'm using RequireJS; The documentation says to use it via a require(), and the javascript files itself is littered with more require() calls.
I do not mind taking a dependency on RequireJS to consume this package. However all of the tutorials that I found gave me the impression that I need to restructure my entire application in a RequireJS style before I could require() the dependency that I found on npm.
Please tell me that I'm wrong. Is there a simple way for a non-RequireJS site to consume a RequireJS module?
In case it matters, my web app is built on AngularJS.
The problem here is browsers don't support require or any notion of modularity, really.
Assuming you just want to assign whatever azure-storage exports to a name in the global namespace (which assumes azure-storage and its dependencies will only consume APIs available on the browser), there are tutorials for using browserify or webpack to that end.
Either of those will build the azure-storage package and its dependencies into a solid .js file you can use in a <script> node that will assign whatever the module exports to a global name of your choosing.
I setup a website with regular client side RequireJS today. Than I did some research on node, got that installed and setup my first module in node. When I setup the first require, I loaded the Require.JS file and I get all that. The thing that is confusing me is, I created a file called test.js and within that I am including:
var require = require("requirejs");
which is actually including the node require, not the original require library I was using right?
So like are they completely different? Can they used together?
Doesn't Node already have a module loader?
Yes Node does.
That loader uses the CommonJS module format. The
CommonJS module format is non-optimal for the browser, and I do not
agree with some of the trade-offs made in the CommonJS module format.
By using RequireJS on the server, you can use one format for all your
modules, whether they are running server side or in the browser. That
way you can preserve the speed benefits and easy debugging you get
with RequireJS in the browser, and not have to worry about extra
translation costs for moving between two formats. If you want to use
define() for your modules but still run them in Node without needing
to run RequireJS on the server, see the section below about using
amdefine.
Source: http://requirejs.org/docs/node.html#1
As the title suggests, i use browserify for my internal requires and on my node server that interferes with the require of global modules.
My solution now is to build the server script with browserify on the side, and then append a file that holds all my requires of global variables that are later gonna be used by the script. This renders browserify unable to try to put my global npm modules into my server script.
Is there a prettier solution to this? Because this way feels like a heap of dung.
-- EDIT --
The code runs only on backend, however - the problem is partially due to how i compile the code that is to be run on that backend. Initially the require keyword is used to get global node modules, e.g express or http. In my case, i need both that functionality as well as reference my own modules compiled with browserify.
My solution right now is to overwrite the global 'define' parameter with amdefine after i've saved references to the the global node modules that i will later use.
Code to bundle node modules into global parameters, require looks for global node modules
My Main, everything from this point forward, require looks for modules inside my own code
I guess I could make a duplicate of nodes require and make a new global reference to it, i.e, require becomes requireNodeModule, i feel as if that's an even worse solution to the one i have at present though...
It sounds like you have some code that runs both on the front-end and back-end, but at present this question is too broad for me to give you useful advice.
Can you narrow it down to a single, specific module that you want to run both in the browser and on your server, where the require clash is evident?
Standard NodeJS app utilising module.exports to make the code modular. We'd like to combine all of those files together into a single file a la RequireJS on the client side (which is what we use there). Does anyone know an easy way to do this server-side without wrapping everything in more module wrappers (e.g. RequireJS) e.g. command-line tool ?
Ta
N
If you want to use node.js modules on the client side without additional wrappers (like RequireJS), you'll want to look into using browserify:
https://github.com/substack/node-browserify
It's a very useful build tool that allows you to use node-style require() statements and native node.js modules on the client side. Or, to quote from the github page itself:
Make node-style require() work in the browser with a server-side build step, as if by magic!