I like to use complex functions in DocumentDB, inside a SP.
Can I load a JS library to be called from the SP ?
A library I created called documentdb-utils has limited support for including libraries in your sprocs using require(...). Note, it doesn't load them into DocumentDB independently to be called from another sproc, it simply inlines them in each sproc that needs it. It's surprising how big a library you can fit but it is not unlimited. You'll have multiple copies of some libraries on the server, one in each sproc that needs it but that doesn't seem to be a problem and I reload the sprocs every time I startup so I don't have a version control issue. There is only one version of each npm module in my project so the same one gets loaded regardless of how many sprocs it's required from.
You can use many npm modules with this functionality but not all. For instance, I couldn't get lowdash to work, so I had to settle for underscore. I have included examples of how to load underscore and async.js in the library. Here is the test for loading and executing async.js. Here is the test for loading underscore.
Note, I'm using CoffeeScript to create the library. The tests and most of the examples are in CoffeeScript, but I have a few examples in JavaScript. Not to worry though because you can easily compile CoffeeScript to JavaScript. There is a lot of help on the web automating this.
Related
I can't seem to find a basic piece of tooling which is a static analyzer that shows me which pieces of code use methods from which other pieces. I could even do with a very primitive one that only shows me which source files contain references to names found in other files in a NodeJS project (still using CJS require here). So far all I have found is a couple of abandoned projects, but one should think there simply must be something out there.
Edit: Graphical output is not required (but certainly a plus); what I primarily need is a tabulation (text) of which functions in which module call functions from which other modules so I can order dependencies.
Sublime text has this feature where when you hover over a name you get the location where that name was defined; this even works across modules and with CoffeeScript. Does anybody know how that is implemented?
This is an actively maintained proprietary call graph generator that supports multiple languages.
Usage : callGraph <files> <options>
https://github.com/koknat/callGraph
I’ve been looking for a similar tool to help my team track the indirect usage of a deprecated function, so I ended up writing a script based on the ts-morph module: https://gist.github.com/adrienjoly/fc117b187f87cca3417abc4a8433e3a2
It’s a node.js CLI that generates the call tree (a.k.a. call hierarchy, or dependency graph) of a function. You can probably modify it to support JavaScript projects. Or create a tsconfig.Json file that includes your JavaScript files.
Hope this helps!
How to organize Vue-JS project [files and directory]: Non Javascript way?
Coming from a non-javascript background, I found Vue.js very intuitive and easy to use. My earlier experience in Javascript is with JQuery and vanilla javascript on the browser.
I created an application using Vue , Vue-components and vue router. Everything works fine.
My problem is, I have ended up writing a lot of code in a single index.html file of my project. This file contains over 10 templates that I have created and attached to different component in my app. I want to know that is there a non-javascript way to organize these templates in seperate files.
I see that there are options using webpack and browserify to modularize the project. But coming from non javascript background, I don't find them intuitive. I don't want to go node - npm way because that has its own learning curve and moreover it downloads a dozen of files and dependencies in my project which I don't understand. I am old school and more comfortable downloading the files and including them in the webpages.
So probably, you understand where I am going to. I need a solution where I could put my templates as separate files and read those files in the different components.
What I have tried :
Declaring the templates inside my components. But writing all that html inside the component is not that clean. It also, makes my JS file too huge. I am better in putting all data in the index.html instead.
Storing template as smaller chunk "homepage.html","about.html" and in my components, using $.get / $.load to read different components in ready function of the component. This works but I still have to fire an additional ajax call for each component which is not efficient.
Please refrain from suggesting the obvious node-npm [webpack and browserify] way. I know thats what is supported by Vue but this needs a learning curve and complete setup. Answer to this question would actually help other developers who hesitate going the node-npm way.
Please shout back if you need more clarifications to the question.
The options you've mentioned are your only real ones... the HTML of the template needs to be available when it's needed, so you either have to have it within your html file off the bat, or load it using AJAX or an in-browser loader like RequireJS (and this extension that allows it to load HTML https://github.com/requirejs/text).
In-file templates make sense for very small projects. As your project grows, you'll need to start using the tools that are built for this. NPM rocks and every JS package that you'll ever need can be included in your project in seconds.
I highly encourage you to try the Vue CLI
It does use node, npm, webpack and downloads dozens of files. Which you've you've explicitly asked for not to use, so let me clarify:
The Vue CLI takes care of the complexity and configures webpack for you.
You don't even have to know it's using webpack.
It's very developer friendly (it even has a built-in gui) and lowers the barrier to entry compared configuring a webpack config.
I hope you'll also find it "intuitive and easy to use".
I am writing a web server in Node.js, and I want it (among other things) to deliver a single JavaScript file to the client which contains my client SDK. The SDK is basically an object which provides lots of functionality the client can use.
I need to build the SDK from various sources:
3rd party libs, such as AngularJS
Custom code, which is stored in static .js files on the server
Custom code, which is created dynamically in-memory at runtime
For being able to test my custom code (#2) easily, and for being able to share this code with the server-side as well, it would be great if I could write it according to CommonJS.
I do not have too much experience with bundling things up for the client-side, but I know UglifyJS and Browserify.
If it was only about concatenating some files (and perhaps minifying them), I knew what to do with UglifyJS. If it was only about delivering some stuff that is compatible to CommonJS, I also knew what to do with Browserify. What I don't get is their combination, and this in addition with demand #3 - the dynamically generated code.
This essentially means that I am not able to use Grunt for this, but that everything needs to be done at runtime (please let's not discuss why I want to do it like this).
So … I'm somewhat lost. Can anybody help clarify things for me? How do I have to put all these pieces together so that I finally end up with a single deliverable that can be sent to the client, and that the client can use?
Basically, what the client should end up with is a number of global objects such as $, angular and my very own custom object, but all this by only loading one single file.
How could I do this?
PS: I do not have the need to put the result to disk on the server, if it's a pure in-memory solution that's perfectly fine for me (and is even preferred, as then I do not need write access to the file system).
Imho webpack provides all the features you need. It's a bundler like browserify but I find it more flexible and extensible. webpack is agnostic to different module styles (CommonJS, AMD, ES6 or old-school globals) and is able to apply and chain pre-processors on modules. These are called loaders (according to the CommonJS spec) and can be used to generate code dynamically. Usually they transform LESS to CSS or CSS to JavaScript, but they can be used for any dynamic task.
To provide your global $, angular and your custom object you could use the script-loader, which runs the given module classically in a global context.
What you're looking for is called "asset pipeline".
You can use mincer (I didn't try it, but it looks very promising) or asset-pipeline (certainly will do the job, but is kinda deprecated).
I'm developing a modular framework in javascript and am looking for a way to automatically optimize/combine a set of javascripts as a precompile step.
I'm already using grunt so a grunt-task would probably make sense.
The framework consists of modules in their own files (as in the rectangular 'widgets' we're all used to) that in turn may require other javascripts.
All this is wired using Require.js which works great.
However, I came across the following constraint when trying to use r.js which comes with require.js
The optimizer will only combine modules that are specified in arrays
of string literals that are passed to top-level require and define
calls, or the require('name') string literal calls in a simplified
CommonJS wrapping. So, it will not find modules that are loaded via a
variable name:
The thing is: modules may inherit from eachother, and even composition of other modules is possible through configuration (with the technical need to load the referenced modules sitting in their own js-files).
This doesn't work with the mentioned constraint above.
I'm sure I could cook up something myself with enough time, but perhaps someone has already done something like this. (r.js but more flexible).
A doable solution imho would be to:
let the precompile-task run the page for which the js needs to be optimized once (but on the server in Node instead of on the client, the framework is able to do this)
and somehow track all the libraries loaded in by require.js
read out require.js somehow and voila there's your list of js-scripts to load.
hand this to r.js through the include it provides and r.js handles it from there.
there are more pagetypes btw. But in r.js it seems possible to define common libraries, so they don't get included in the per-page-optimized file.
Does this sound plausible? Anyone ever tried something like this?
This seems overly complicated. In r.js build there is option onBuildRead, where you can modify source so that it would be acceptable to optimizer. Also you may look into Internal API: onResourceLoad. Where you can capture all loaded dependencies and then make a call to do custom build.
To load your page you would have to use PhantomJS, so that it acts as a browser and executes JS. Then signal node to produce custom build for that page. But then need to switch resources on that page to use custom build. I guess you can make it configurable and do that when in production.
It does sound that it is possible, not sure if it is feasible.
I've developing JavaScript since many years but have never really thought about the whole testing, developing and building stuff - but I realized it's pretty much necessary. We've just used a Subversion repository with simple release tagging (switching to git soon). As a new bigger pure JavaScript project (using jQuery) is arriving soon, I'd like to optimize the whole process.
I already did some research but never found a good starting tutorial.
It's definetly a good idea to split classes and separate code blocks into several js-files and not a big one (as Prototype or jQuery do it). These js-files must be "build" into a single file. How do I achieve that?
It's pretty much necessary to Unit-test the stuff me and my colleagues are coding. I found the js-test-driver which has an eclipse plugin that seems to be doing his job quite good. If my developer-folder contains all these src- and src-test-files, how do I integrate this in the building process?
For testing, take a look at this: https://stackoverflow.com/questions/32809/javascript-unit-testing
For merging all of your JavaScript into one file you can use something like YUI Compressor. You need to be looking for a minimizer first, compression second. A minimizer just takes the files and merges them together and gets rid of whitespace. A compressor will actually try to optimize the js for you by changing variable names and removing unnecessary code.
As for unit testing I am unsure of how you will want to do that. There are a few unit test libraries out there. A popular tool for testing is Selenium. I don't currently do unit testing so I am out of my element there..
For setting up your code you could always look at using a JavaScript framework like ExtJS or JavaScriptMVC. Those help you with setting up your code in the proper way and also helps focus your team on the proper standards and coding structure while also writing a lot of the code for you so you don't have to re-invent the wheel.
EDIT: Just a quick after thought. Even if you don't want to use a JavaScript framework, I would suggest checking them out, especially ExtJS, just to see how they organize their code and some of the tricks they do to keep it clean.
I'll answer part of your question:
These js-files must be "build" into a
single file.
This is possible only with server side language - in ASP.NET you have built in tools for that, otherwise build your own "merger" server side file and reference that file instead of the actual .js files.
These js-files must be "build" into a single file. How do I achieve that?
Definitely keep your files separate in version control, and only merge them during the build process.
The YUI compressor mentioned elsewhere is a java-based tool that will not only merge but -- of course! -- compress your files for faster download.
If you just want a simple merge of files, a simple Perl or bash-script (or other preferred scripting language) could concatenate multiple .js files into one for release -- just make sure that the build script also updates all HTML in the release to reference only the single page.