javascript - Name html blob urls for easy reference - Stack Overflow

Within our web application we load a lot of content from package files (zipped packages containing html, js, css, images and so on.) The module loader (client side JS) processes the packages and makes the content available to the DOM using blob urls.

While this works very nice, it's sometimes tedious to find the right piece of JavaScript file for debugging.

IE: in chrome in the development console->sources all blob urls are listed under (no domain) and have random names such as:

blob:

In a normal production environment there are roughly 100 lines like this, so finding the right one might take some time.

I'd pretty much like to name the blob urls, or do something to make them easier to find for debugging purposes. This seems possible since WebPack is doing something like this, however i can't seem to find how. Is there anybody that can hint me in the right direction.

Within our web application we load a lot of content from package files (zipped packages containing html, js, css, images and so on.) The module loader (client side JS) processes the packages and makes the content available to the DOM using blob urls.

While this works very nice, it's sometimes tedious to find the right piece of JavaScript file for debugging.

IE: in chrome in the development console->sources all blob urls are listed under (no domain) and have random names such as:

blob:https://example./0613efd7-6977-4872-981f-519eea0bc911

In a normal production environment there are roughly 100 lines like this, so finding the right one might take some time.

I'd pretty much like to name the blob urls, or do something to make them easier to find for debugging purposes. This seems possible since WebPack is doing something like this, however i can't seem to find how. Is there anybody that can hint me in the right direction.

• javascript
• html
• blob

Share Follow asked Jan 30, 2018 at 10:39 Bas GoossenBas Goossen 59911 gold badge77 silver badges2020 bronze badges 3

• 2 At the point your extracting and make into a blob, why not just create a reference here.. var blobs = {"blob:https://example./0613efd7-6977-4872-981f-519eea0bc911": "This is the blob"} etc. – Keith Commented Jan 30, 2018 at 10:48
• 1 Hi Keith, thank you for the out of the box answer, i was thinking about something like that as wel, it whould definitively save time searching the right file. However then i saw the implementation of WebPack and liked to really implement the file names and structure. However if i cannot find out how to do that i'll go for your option. – Bas Goossen Commented Jan 30, 2018 at 10:59
• @Keith that's probably the best solution, you should write it as an answer. I'll mention it in my own answer which is just a hack, but it would make more sense if you care to post it. – Kaiido Commented Jan 30, 2018 at 13:33

Add a ment  | 

3 Answers 3

Sorted by: Reset to default 3

Ok, the way I would do it is have some global that keeps a track of the URL's, using a simple reverse map.

One problem of course with this is that references to a blob that no longer exists will be kept in memory, but if say you was only enabling this for debugging purposes this might not be a problem.

var namedblobs = {};

function addNamedBlob(name, uri) {
  namedblobs[uri] = name;
}

function getNamedBlob(uri) {
  return namedblobs[uri];
}

function createSomeBlob() {
  //for testing just a random number would do
  return Math.random().toString();
}

var blob = createSomeBlob();

addNamedBlob("test1", blob);
addNamedBlob("test2", createSomeBlob());

console.log(getNamedBlob(blob)); //should be test1

Finally i have found a solution that works to my liking. For our application we already used a serviceworker which has caching active. So i ended up writing the module files into the serviceworker cache whenever somebody has debug mode turned on.

Since the url portion of the resource files is static this way, all the nice browser features such as breakpoints are now useable again.

Below i've posted the relevant code of the serviceworker. The rest of the code is just plain serviceworker caching.

api.serveScript = function(module, script, content){
try{
    content = atob(content);
} catch(err){}

return new Promise(function(resolve, reject){
    var init = {
        status: 200,
        statusText: "OK",
        headers: {'Content-Type': 'text/javascript'}
    };
    caches.open("modulecache-1").then(function(cache) {
      console.log('[ServiceWorker] Caching ' + module + "/" + script);
      cache.put("/R/" + module + "/script/" + script, new Response(content, init));
      resolve("/R/" + module + "/script/" + script);
    });
});

}

Thanks for your answers and help. I hope this solution is going to help some others too.

@Keith's option is probably the best one. (create a Map of your blobURIs and easy to read file names).

You could also do a dynamic router that will point some nice url to the blobURIs, but if you are open to do this, then just don't use blobURIs.

---

An other hackish workaround, really less cleaner than the Map, would be to append a fragment identifier to your blobURI blob:https://example./0613efd7-6977-4872-981f-519eea0bc911#script_name.js.

Beware, This should work for application/javascript Blobs or some other resource types, but not for documents (html/svg/...) where this fragment identifier has a special meaning.

var hello = new Blob(["alert('hello')"], {type:'application/javascript'});
var script = document.createElement('script');
script.src = URL.createObjectURL(hello) + '#hello.js';
document.head.appendChild(script);
console.log(script.src);

var css = new Blob(["body{background:red}"], {type:'text/css'});
var style = document.createElement('link');
style.href = URL.createObjectURL(css) + '#style.css';
style.rel = 'stylesheet';
document.head.appendChild(style);
console.log(style.href);

And as a fiddle for browsers which doesn't like null origined StackSnippet's iframes.