Maintain JS debug code & reloading browser - javascript

I use Google Chrome Dev Tools to troubleshoot or debug JavaScript. I add break points and use watches, but a lot of the times it's convenient to just insert console.log(value) here and there in the script.
The problem is that when the page has to be refreshed in order to see the JS changes (and the console.log() calls), then the console.log() calls have been removed when the page reloads. Obviously this is because I didn't edit the actual source file itself.
Is it possible to maintain edits to JS files and still reload the page?
There are a lot of cases where I'm looking at other people's JS, learning and understanding it, so editing the source code is not even a possibility. Other times, when working on my own code, I might be debugging JS code on a live server, to editing my source to put in random console.log()'s is not desirable.
I know that Dev Tools has an auto save feature where the changes you make can save the actual source files (as long as the files are on a filesystem that is available to your computer). But that doesn't help in my case.

There is 'workspace' feature in DevTools.
It allows you to map the source files on your disk to the scripts of your page.
So when you apply your changes to the page's javascript they also will be saved to the disk.
If your web server serves these files from this folder then you will get the changed files after reload.

Related

Accessing local files for a client-side only website, to be distributed as a HTML-download the user opens with a browser

Due to the safety rules of the same-origin policy (SOP), i am unable to load certain local files when opening an index HTML-file directly with a browser. Using a "live-server"-plugin works fine, as all the files in that case are "on the same server". I need to distribute the website as a client-side only app - A folder and html file to be opened with your browser. Solutions to the problem always seem to require setting up a server. Is there any way to avoid that, and keep everything on the client?
I am making a mathematics e-book, that i want to distribute as a website people can download. I want it to be client-only and a download, since if it were to become popular, then i wouldn't be able to afford running the server (as i would be studying at that time). I have chosen html and javascript over EPUB, as they are much more powerful, and allow for tons of interactivity (and much more efficient development).
So far i have a browser.html file, that loads individual pages with JQuery .load(). This browser.html file has both html, and javascript. The CSS is in an external file. The individual pages have many pictures, that are also stored locally on the server. As the pages are contained in subfolders, the picture URL's go out into their parent folder, and into the assets folder, like: ../../../Assets/Chapter1/Talopgaver og intuition/Misc\F\solsystem.png. I use custom-elements (shadow-DOM) to handle various complex aspects such as questions, answers, along with certain other things too. Other than JQuery, i also make use of Math-Jax, and a "polymer" library that helps with cross-browser support of custom-elements. All the pages in a certain chapter are loaded in the start, and then put into a array (this makes it fast to scroll through pages as you often do in books). They (as strings) are each modified slightly to automate certain tedious parts of development.
I have tried to open the browser.html file on chrome, firefox, internet-explorer, and edge. They all load the html that browser.html inherently contains (properly styled even), but none of them load any external pages. Interestingly, one of the images used in the browser.html file still works (i would think that would be a local file too, not?). If have tried turning off calls to ajax or external CSS, but nothing changed. I have searched for other people with similair problems, but all the answers just reccomended setting up a server.
When loading the page with a live-server plugin, the result looks something like this:
browser.html page opened with "live-server" visual studio code plugin by Dey, Ritwick
When opening the browser.html page directly using chrome, it looks like this:
browser.html page opened directly with chrome
The error i get (after having removed an ajax .get() call) isn't particularily descriptive: simply "Failed to load resource: net::ERR_FILE_NOT_FOUND" from "platform.js:1". Even if turn off the call to start loading pages, it gives me excaclty the same error messages.
Looking at the network reports, with live server it looks very ordinary. without it's pretty weird. It says it takes hours to load browser.html, even though that clearly isn't the case. It fails loading platform.js, after using 22 seconds trying. The networks report looks a bit more healthy when turning off the call to load pages. It gives up loading platform.js faster (8 seconds), yet still supposedly takes hours to load browser.html.
Though it shouldn't ultimately be neccesary, i have linked the entire browser.html document below, along with an example of a page it might load (the example in the first picture above).
browser.html. Too big for a stackexchange code-block embed
Page in previous picture (page 37)
Any help is appreciated!
EDIT: Main problem seems to be the loading of pages using JQuery.load(). Even on a simple testing website that operation is just not possible without running on a server.

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.

Is it possible to reload a single Javascript file using Chrome Developer tools?

In many cases, I make some small changes to a JavaScript file, to see the result I have to reload the whole page.
Changes made in chrome's developer tool in "Source" tab do not save in file system.
So, is it possible to reload single JavaScript file alone?
I can't think of much efficient way to do this but one way you can do this is by adding a breakpoint at the start of the JavaScript file or at the block you want to add or delete changes to.
Then when you reload, the debugger will pause on that breakpoint, and you can make any changes you want to the source, save the file and then run the debugger through the modified code.
But here's a thing that you should know: next reload the changes will vanish but at least it let's you run some slightly modified JavaScript client side codes.

How can I specify a file source map after the page loads up?

I'm a big fan of source maps for javascript and SASS; however, I don't want to load source maps into production for a couple of reasons: the original source code is available and it's not a good use of bandwidth.
But, sometimes, the need for debugging in production arises (we've all seen production-only bugs on the front-end).
Is there a way for me to specify a source map after the fact? For example, I could have a source map available locally or behind a VPN-locked server, or even in a folder that's not visible to the user. I'm fine with doing it at run time or specifying a setting and having to reload the page. (actually if I could persist that setting that'd be even better).
You can right-click on a minified source file and select "Add Source Map". Then paste in the URL of the map file.
If your mappings file doesn't include the original file contents alongside the mappings make sure the original file paths are accessible to Chrome.

What's a good way to organize external JavaScript file(s)?

In an ASP.NET web application with a lot of HTML pages, a lot of inline JavaScript functions are accumulating. What is a good plan for organizing them into external files? Most of the functions are particular to the page for which they are written, but a few are relevant to the entire application.
A single file could get quite large. With C#, etc., I usually divide the files at least into one containing the general functions and classes, so that I can use the same file for other applications, and one for functions and classes particular to this application. I don't think that a large file would be good for performance in a web application, however.
What is the thinking in this regard?
You probably want each page to have its page-specific JavaScript in one place, and then all the shared JavaScript in a large file. If you SRC the large file, then your users' browsers will cache the JavaScript code on the first load, and the file size won't be an issue. If you're particularly worried about it, you can pack/minify your JavaScript source into a "distributable" form and save a few kilobytes.
Single file is large but is cached. Too many small files mean more requests to the server. It's a balancing act. Use tools like Firebug and YSlow to measure your performance and figure out what is best for your application.
There is some per-request overhead, so in total you will improve performance by combining it all into a single file. It may, however, slow down load times on the first page a user visits, and it may result in useless traffic if some user never require certain parts of your js.
The first of these problems isn't quite as problematic, though. If you have something like a signup page that everyone visits first and spends some time on (filling out a form, etc.), the page will be displayed once the html has been loaded and the js can load in the background while the user is busy with the form anyway.
I would organize the js into different files during development, i. e. one for general stuff and one per model, then combine them into a single file in the build process. You should also do compression at this point.
UPDATE: I explain this a bit more in depth in a blog post.
Assuming you mean .aspx pages when you indicate "HTML pages," here is what I do:
Let's say I have a page named foo.aspx and I have JavaScript specific to it. I name the .js file foo.aspx.js. Then I use something like this in a base page class (i.e. all of my pages inherit from this class):
protected override void OnLoad(EventArgs e)
{
base.OnLoad(e);
string possiblePageSpecificJavaScriptFile = string.Format("{0}.js", this.TemplateControl.AppRelativeVirtualPath);
if (File.Exists(Server.MapPath(possiblePageSpecificJavaScriptFile)) == true)
{
string absolutePath = possiblePageSpecificJavaScriptFile.Replace("~", Request.ApplicationPath);
absolutePath = string.Format("/{0}", absolutePath.TrimStart('/'));
Page.ClientScript.RegisterClientScriptInclude(absolutePath, absolutePath);
}
}
So, for each page in my application, this will look for a *.aspx.js file that matches the name of the page (in our example, foo.aspx.js) and place, within the rendered page, a script tag referencing it. (The code after the base.OnLoad(e); would best be extracted, I am simply trying to keep this as short as possible!)
To complete this, I have a registry hack that will cause any *.aspx.js files to collapse underneath the *.aspx page in the solution explorer of Visual Studio (i.e. it will hide underneath the page, just like the *.aspx.cs file does). Depending on the version of Visual Studio you are using, the registry hack is different. Here are a couple that I use with Windows XP (I don't know if they differ for Vista because I don't use Vista) - copy each one into a text file and rename it with a .reg extension, then execute the file:
Visual Studio 2005
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Projects\{E24C65DC-7377-472b-9ABA-BC803B73C61A}\RelatedFiles\.aspx\.js]
#=""
Visual Studio 2008
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\9.0\Projects\{E24C65DC-7377-472b-9ABA-BC803B73C61A}\RelatedFiles\.aspx\.js]
#=""
You will probably need to reboot your machine before these take effect. Also, the nesting will only take place for newly-added .js files, any that you have which are already named *.aspx.js can be nested by either re-adding them to the project or manually modifying the .csproj file's XML.
Anyway, that is how I do things and it really helps to keep things organized. For JavaScript files containing commonly-used JavaScript, I keep those in a root-level folder called JavaScript and also have some code in my base page class that adds those references. That should be simple enough to figure out. Hope this helps someone.
It also depends on the life of a user session. If a user is likely to go to multiple pages and spend a long time on the site a single large file can be worth the initial load seeing as it's cached. If it's more likely the user will come from google and just hit a single page then it would be better to just have individual files per page.
Use "namespacing" together with a folder-structure:
alt text http://www.roosteronacid.com/js.jpg
All you have to do is include Base.js, since that file sets up all the namespaces. And the .js file(s) (the classes) you want to use on a given page.
As far as page-specific scripts goes, I normally name the script according to the ASPX/HTML pages:
Default.aspx
Default.aspx.js
I would recommend that if you split your JS into seperate files, that you do not use lots of tags to include them , that will kill page-load performance. Instead, use server-side includes to inline them before they leave the server.

Categories