Loading the library asynchronously
ethanresnick opened this issue · 4 comments
Hi,
Your library looks awesome!
I'd like to use it, but not have it block the initial rendering of the page, which is very important for user experience. Some other logging libraries, like loggly, handle that like this:
<script type="text/javascript" src="logglyScriptUrl.js" async></script>
<script>
var _LTracker = _LTracker || [];
_LTracker.push({ /* config settings here */ });
</script>
In other words, they load the script asynchronously (so it doesn't block rendering), but seed the _LTracker global with a blank array right away. That way, calls from user code to _LTracker.push
(their logging API) fall back to Array.prototype.push
before the library loads, without throwing an exception. Then, when the library loads, it looks if the _LTracker
global array contains any messages and logs them properly; after that _LTracker
is a genuine instance of the library. (Configuring the library is also done through an initial push()
.)
Is something like this possible with your library? Obviously, your library has a bigger API surface area than just .push()
, but maybe something like this wouldn't be too hard to support?
I can see the need to load the jsnlog.js script without this blocking page rendering.
It is not possible to call JL functions before jsnlog.js has loaded. However, I'm not sure why you would need this.
I guess you load all your other JavaScript in files, with the script tags at the bottom of the page. Maybe you even minify and combine your JavaScript files. You can do the same thing with the jsnlog.js file, treating it as any other JavaScript file. You just want to make sure it loads before the JavaScript files that call any JL functions.
Details on how to do this are in:
http://jsnlog.com/Documentation/HowTo/LoadingJsFile
You might also be interested in this:
http://jsnlog.com/Documentation/JSNLogJs/ConfigureFunction
It is not possible to call JL functions before jsnlog.js has loaded. However, I'm not sure why you would need this.
Ok, let me try to explain better. Holding aside the details of browser script loading/timing, the key point is this: sometimes there's JS that I need to run as soon as possible to get a useful render (as is often the case with single page apps that use JS to build the DOM); and, sometimes, that code that needs to run ASAP can throw errors. So, ideally, JL would be able to log those errors. However, having to load, parse, and execute the entirety of JL before my critical javascript (which might call a JL function) can run is a big performance penalty, just to cover the off-chance that my code will hit an error. So, the point of queueing strategies, like the one my initial post, is to let authors run their possibly-error-throwing code immediately, without having to wait for JL to load, but then having JL do the logging once it does load. That use case doesn't seem to be covered by any of the suggestions in your response, and I think it's an important one
Thanks for the clarification. I understand what you're after is some way of logging errors in memory using some minimal JavaScript code that has been inlined on the page (that is, not loaded from an external file). Then after the html and JavaScript files have loaded those errors can then be sent to the server.
This isn't supported out of the box by JSNLog. Will have to think about whether and how to add this, which shouldn't be all that hard.
Thanks for the suggestion though, much appreciated.
Awesome! Glad to hear you'll consider it