Closed montogeek closed 10 years ago
I also submitted issue before, i would like to see this fixed, because i don't have internet connection always.
You could also use a cdn version and a local version as fallback, see e.g http://www.hanselman.com/blog/CDNsFailButYourScriptsDontHaveToFallbackFromCDNToLocalJQuery.aspx
Well the author of this package should do this, not me. If i do it, every time i run "php composer update" i will be asked to download the modified vendor file.
Sure, the repsone was ment for discussion and to be incorparated into whoops directly.
The current problem is the template can be outputted anywhere in the application. There is also no routing for this error handler, so it cannot just refer to other urls on the application.
It could use a horrible hack using a GET parameter or a custom HTTP header, act on that and abort the application, but that has so many issues with it: application will get false log hits, the application might be clearing get parameters, application might rewrite urls and modify headers, etc.
It could also just inline the jquery directly in the template. This is quite a good option, but given that the template is being refactored significantly (branch, also #60), it is probably not worth modifying the current template for this corner case.
I've also thought about inlining jQuery in the template. It's the best option IMO.
not sure which features of jQuery you use ATM, but maybe zepto.js would be a small replacement, in case the API covers everything you need.
maybe there is also a way to put the contents of the js lib into HTML5 LocalStorage
That's what the browser's cache basically does.
That's what the browser's cache basically does.
sure, but we cannot leaverage browser cache because there is no "good" way to generate a url to get jquery loaded as an external resource. this is what this discussion is about.
I agree about this. I typically have Whoops enabled in my local development environment, where I often enough don't have internet available. I imagine a local jQuery install rather complicated when it comes to serving these assets, e.g. in Laravel. (After all, it's an error page, it should be mostly self-contained.)
So, @filp, would you be open for a port of this jQuery code to pure JS?
@franzliedke Definitely! The PrettyPageHandler's template uses very little javascript, and when I made it I used jQuery out of pure laziness. I believe it's also safe to assume people interacting with whoops will be using modern browsers (IE9+, at least, and the latest for everything else), so compatibility shouldn't be a major issue.
A possible alternative is also bundling either Zepto, or jQLite (which angular uses as a drop-in when jQuery is not available) and serving them as part of the page payload - they're still quite large (jQLite is ~15kb before gzip), but it definitely beats jQuery size-wise.
With the refactored templating system we can now inline anything. I don't see any advantage on inlining Zepto or jQLite over jQuery. Am I missing something?
Since jquery is shipped as AMD modules we could use a custom build which contains only the things we need, while significantly reducing size.
Okay, PR #128 should take care of this. =)
I just discovered that last week that Whoops library loads jQuery from Internet, when you don't have Internet connection the 'selectable' stack on the left side doesn't work, it is possible to load a local copy of jQuery?