Meteor.js serve javascript files without (function() { ... }).call(this) - javascript

The title should be self explanatory, but is there a way to get Meteor to serve up a javascript file without stuffing it into (function() { <<code>> }).call(this)?
I wrote an app that relies on javascript objects each stored in their own file and then instantiated when they are ready to be used. However, because of the aforementioned problem, they are isolated and unable to be viewed from outside files.
The only option I have come up with is to store them as plaintext and then load them using an HTTP request and then store them into the main file. Hopefully I am missing a much easier way.
If you need any code, let me know, but I think this is general enough to not warrant any.
--EDIT--
I originally wrote this to be a standalone html page, but then decided to go all out and use meteor to make it a full-blown web app.

Its probably not a good idea to try and get the javascript file this way because when you deploy the app or set production mode on, all the javascript files and html files will be minified into a single js file & they wouldn't exist the normal locations during development anymore:
If you want the javascript file to be untouched by meteor you would need to put it in a folder called /public in your projects root directory.
If you are more interested in whats inside the javascript files as opposed to getting them by filename you might want to switch to the devel branch of meteor, or wait for the never version after 0.6.2.1 and put your javascript files in /client/compatibility/ as these files are not variable scoped & will still be automatically referenced unlike the /public dir.

Related

Is it possible to access angular app data from an external Javascript Code in the same project

So, this is a theoretical question because I don't have to encounter this problem. But I'm just wondering.
Let say I have an Angular Project Compilated in My PROJECT FOLDER.
<br/> In this PROJECT FOLDER, I have the other JAVASCRIPT FILE, EXTERNAL to my Angular Project.
<br/>
In this EXTERNAL Javascript Files, I Would like to access a data or a variable from a file in my Angular Project.
Could it be Possible?
Like an import/export from a file in my Angular Project to a Javascript file Outside of my Compilated Angular.
The part where I'm concerned about is the fact that Angular is compiled in production.
In development, I could easily write a path to an angular file. But Once it's compilated, what would happen?
So is it possible? If yes, how? When using tools like Webpack?
It's totally possible, given certain conditions.
In case you haven't played with it yet, know that you have a ng global variable in your Angular projects, that is bound to your window.
You can use it with something like this
ng.probe(document.querySelector('app-root')).componentInstance
And that should return your app component instance (assuming you use the correct selector).
But this can be done only if the code isn't minified, and maybe even when you serve your application (not checked this one).
Other than that, I am not aware of any other technique to access angular features through another script.

How to have web page include all js files in a directory tree?

I'm trying to figure out how to set up a JavaScript development project that will allow me to factor my code into several files. I plan to run this eventually on a client web browser, but first I need to set up an efficient development environment.
I've used other programming languages before that let you keep a large number of files in a subdirectory and then let you compile everything into your final deployable (or have an interpreter do something similar). Javascript doesn't seem to allow this - I have to manually add a <script> tag for each js file to the head of my web page to get the browser to load it. This can get very hard to manage once you have more than about 10 files that you need to keep track of. It would be nice if I could write <script src="myscripts/**/*.js"> to suck in everything, at least during development time.
I've found Grunt 'uglify' which looks like it would be a handy tool for creating a final file for deployment, but during development I need to keep everything separate so I can debug properly. Is there any way to have my web page load every js file in my development directory?
As others have mentioned in comments, Webpack (or similar) is the way to go. It bundles up all of your relevant code, and can also process it for minification.
I want to address this comment though:
but during development I need to keep everything separate so I can debug properly
You don't need, or want, that. While developing, you want to be testing against the same sort of build process you'll use in a deployment later. So, how can you easily debug your compiled scripts? There's a .map file that gets built, which tells the browser what your original code looked like.
Chrome and other browsers will automatically load and parse this file when you open your developer tools. Then, you'll be able to see the original source code (and in the original language, for anything transpiled) and debug it as if it were not bundled in the first place.
Don't deploy this map file, unless you want external users to be able to see all your original source code.

Why not to include a .js file containing Express.js code into an HTML file?

Not an unsolved problem, but rather a technical question, which I hope is valuable enough to ask.
As a beginner web developer, I attempted to give a variable from a .js file to an .html file, to display a variable from the former on-screen - I desired to do so by the <script src=... parameter. The .js file I wanted to include in the .html is the one that contains the code, which creates the HTTP server (as of yet a simple one) and loads the .html file.
I was told that it is a bad idea, and I should use JSON objects instead. THe problem is therefore solved, but I'm interested: why was it a bad idea to include the script of Express.js within the HTML file?
Express.js is Node.js web application framework. Lets simply call it backend javascript, which means it's designed to be run not in browser, but as part of Node.js application.
Just FYI:
There is a way to 'run' some Node modules in browser. There is tool called browserify .
Here what they are saying on their web site:
Use many of the tens of thousands of modules on NPM in the browser
I'm afraid that Express.js is not one of those 'many' modules.

Does creating javascript dll have any advantages over adding it directly using script tag?

I am working on project with larger javascript files.I can add these javascripts in one of the two ways.
1) create a separate class library project and have the javascript files there as embedded resource.Include a reference of the dll into the web project and then include those using scriptmanager as webresource.
2)Have these files in a separate folder and then simply add these files using the script tag and there path.
I am not going to paste the javascripts in my page within the script tag cause they would mess my pages mark up.
So I would like to know which one is better of the above 2 ways.In either of the 2 ways everytime i load the web page i see GET request for the js files.If i create a javascript dll will the browser cache it?
You can't create "javaScript dll". JavaScript is a client-side stuff, dll is server-side. No matter in which project your javaScripts are, it will still be sent to the client and executed there. So it makes no sense to put JS files to another project (especially as resources)
We usually want to minify and bundle the JS files, so the client will do less requests to the server and also to reduce the amount of data to transfer.
For minifying the JS files I would recommend to use Web Essentials extension to VS. It is very handy and can make web programming easier.
Minification will remove all unnecessary characters from the JS file and it will also reduce the length of the identifiers (like method names and variable names).
You can learn about bundling here. It is useful when there are more JS files to load to load all of them at once.

Best way to keep files that are used in multiple projects in sync?

I have a few files called "helpers.scss", "helpers.js" and "consolerules.js" that I use in every one of my projects. When I'm working on a project I'm modifying one of the files, for example I will add a function for replacing all strings within a strings into "helpers.js" but then when I open my other project I don't have that function.
Or I will add a helper css class in helpers.scss in the other project and I don't have it in the other projects.
What is the best way so I can always keep them in sync when I edit them in one of the projects? I was thinking of bower, gists, git, dropbox, google drive or something like that ...
I used two ways to handle these:
Get a CDN like server
Have a single version of those files and place them on a server. For example you could have URLs such as:
https://cdn.example.com/css/helpers.css
https://cdn.example.com/js/helpers.js
If you want to support versions (maybe you should?), you can add that to the filename:
https://cdn.example.com/css/helpers-1.3.css
https://cdn.example.com/js/helpers-1.2.js
Or to the path if you view all your files as having one common version:
https://cdn.example.com/1.2/css/helpers.css
https://cdn.example.com/1.2/js/helpers.js
Versioning is useful if you want to test a website with the newest version before using that version on your live site.
This is most certainly the easiest way if you can implement it that way. Now all your other websites will use those URLs instead of local versions of the files:
<link type="text/stylesheet" href="https://cdn.example.com/1.2/css/helpers.css"/>
Pull those files at build time
Depending on how you organize your websites (it is really not clear from your questions) and assuming you have folders on your machine with the original source, you can bring in those files as required with a script that you run before you upload your sites.
In my case, I like to do that in three steps:
I write the files
I copy the files to a .../build/... folder
I send the .../build/... folder to my test or production server
One reason for this is to generate a build folder that includes exactly what you want, verify it, then send it to your server. That verification happens only when you write your script. Once done, it should not require any additional work.
So... one reason to get such a script is that I can compile my files. For example, if you write PHP code, the servers only need the most compressed version of your code (unless you are debugging and need to find line numbers...) The script that generate the build folder could do:
for p in php/*.php
do
php -w $p build/$p
done
Now your PHP code on your server may be something like 20% smaller.
Similarly, you could copy your helper.css file as in:
cp ../helper-project/css/helper.css build/public_html/css/.
This copies the helpers.css file to your build folder. Since it grabs that file from your unique ../helper-project folder, you will always end up with the latest.
And instead of a simple cp command, you could also minimize that file at the same time:
cleancss --remove-empty ../helper-project/css/helper.css > build/public_html/css/.
The only problem here is that if you make changes to the helper-project, it won't automatically update all the projects. You still have to do in each project and run the script(s) that generate the build folder and copy that to your servers. Yet, I find that to be a practical way of doing things because that way I know when I do the update and I can test the resulting website(s) before going to production and once I update a production site, I can verify that it's still all working just fine.
You can do this with git (or any modern VCS); I assume you are using some sort of VCS for your code.
If you have a project being managed in git, you can even add multiple remotes, such that you can pull in code from multiple sources.
If you are using a VCS like git, then it is just a matter of doing a git pull <remote ref> <branch ref> whenever you want to sync up.
Otherwise, the comments to your question offer some alternatives.

Categories