When you load with Dojo's require a module with the wrong module url (mid), it creates an error (timeout) each time you use require(not loaded yet modules) again, regardless you loaded another module successfully afterwards.
Is there a way to clear that errors? Those failed modules seem to be permanent somewhere in dojo.js and they don't seem to be accessible through an API.
ps: I'd be happy even with a core hack to get rid of them.
Related
I'm trying to follow the Compose Multiplatform Web Getting Started guide. Most of it seems to work fine, but when I try to actually run the thing (gradle jsBrowserRun), it starts a browser, but it can't find the generated JavaScript file. The browser console shows a 404 for GET http://localhost:8080/kotlin-multi-web.js.
The file kotlin-multi-web.js is indeed the name of a file generated in web/build/compileSync/main/developmentExecutable/kotlin.
The page title matches the one I defined in my index.html, so that gets loaded correctly.
I have tried a pure Compose Web project (which isn't a Gradle multi module project), and there it does all load correctly. I checked, and didn't see any differences between the Gradle build files other than the extra dependency from the web project on common.
So, why doesn't it load, and how can I fix it?
My changes are not reflecting inside browser even after storage/framework/views clear and running various artisan clean-up commands.
To make clear that I am calling the right file.
Is it possible my PHP environment is somehow persistent loading this file?
I found the answer.
I am using Nwidart/LaravelModules to structure my project.
Laravel Modules has a command that publishes all modules to the views folder in resources/views. Apparently Laravel was using those 'published modules' alongside the 'official' modules, which caused the problem above.
We're migrating from Require JS to webpack. In our project, we were able to require a runtime-based url as a module (to our SignalR proxies - these are generated at runtime) and that file was downloaded completely before the module requiring that fired off. I haven't-yet determined how to achieve the same effect using webpack except for an unsavory syncrhonous xhr request to get the script, which is a deprecated approach. What am I missing?
So the desired effect is to be able to have the top-most consumer require a module which internally requires the core SignalR lib (which we get like normal) and then this runtime-based (that url) script as a module, before running the top-most consumer's code.
I use Browserify at the moment to bundle my client-side modules into bundles. Each bundle is then loaded as a script tag.
However with HTTP/2, my understanding is that bundling and minification are no longer best practices due to the amount of simultaneous connections available between the client and the server.
So how do I load npm modules in the browser without bundling?
I guess I want to be able to do
var someModule = require('some-module');
And have 'some-module' fetched from the server dynamically.
(I am aware there may be adverse affects on older HTTP/1.1 clients.)
You can't (without hacks and/or rewriting the files), because CJS require is sync. Even if you could, it would still be slow.
JS thread needs to be suspended waiting for the dependency to be loaded and executed. Without modifying source files doing this would require hacks like sync XHR or document.write, but these won't be able to load dependencies in parallel.
You could theoretically use some tool to rewrite the files to convert imperative require to callback-driven one (sort-of like conversion of CJS to AMD or ES6 yield compilers for ES5), but that would probably defeat your goal of using npm modules as-is.
And finally, even if you could load them (or used ES6 modules and travel a bit to the future), it would still be slower than bundling, because the browser doesn't know the full dependency tree, so it has to wait to discover dependencies of dependencies.
I do recommend webpack chunking (use the analyzer to find chunkable parts of the app) if you'd like to load your app in smaller pieces. It requires using an async require.ensure(cb) though.
Depending on what you're using to build your JS into a useful browser bundle, the tools will vary.
If you're using webpack, they have a built in feature for lazy loading:
https://github.com/webpack/bundle-loader
If you're using browserify, there is a module called externalize that aims to do this:
https://github.com/epeli/browserify-externalize
If you're using something else, I'd recommend searching for that builder's name and "lazy loading". I know RequireJS has supported this for a long time, too.
I'm trying to work out how to use DOH to test Dojo modules if I don't install Dojo locally to my project. I'm working in Eclipse and ideally, I'd like something that I can run as part of a Maven build eventually. The Dojo package is 5-20Mb and I don't want to have it stashed in my source control system with each project if possible.
I've tried a few options with the runner.html test runner, but DOH is going to need to find a Dojo somewhere, and then it seems that modules will be found relative to that installation.
Having Dojo installed on my system but not in the project gives me a problem in trying to find the project relative to the location of the dojo.js file. The cross-domain protection prevents me serving up any kind of absolute path as it strips : characters. It also stops me using a Dojo installation served up on a different domain over http.
Is it necessary to have Dojo installed somewhere that I can then define a relative path from dojo.js to the roots of my modules? If not, how do I configure to get around it?
I've not tried this completely cross domain, but yes, you can define paths which may be enough to get you going.
We run our tests using a somewhat complicated deployment (to ensure we don't introduce accidental dojo/doh path dependencies), and our URL looks like this:
http://server/XXX/dev/dohpath/util/doh/runner.html?boot=../../../dojo/dojo.js&dojoUrl=../../../dojo/dojo.js&paths=doh,../dohpath/util/doh;mymodule,../../mymodule&testModule=full.test.module
That is, you fire up the runner, give it both 'boot' and 'dojoUrl' to tell it where Dojo itself lives, use 'paths' to tell DOH where it lives and how to find your own modules.
blech
Whether those relative paths can be made absolute successfuly, and whether it'll work cross-domain is an entirely different matter, I'm afraid. We'll be hitting that problem ourselves in a couple of months.
I've been able to do this with the runner located at http://archive.dojotoolkit.org/nightly/checkout/util/doh/runner.html and a gist.
The trick seems to be to use a path alias in the URL, and use a network-path reference URL (i.e. omit the URL scheme, URL starts with //).
I found this out while trying to answer this question without a local copy of DOH.
Here it is:
http://archive.dojotoolkit.org/nightly/checkout/util/doh/runner.html?testModule=aa&paths=aa,//gist.github.com/gitgrimbo/5406688/raw/e6bc4469ce72dfd6d50e61e885889cb915a3f66b/gistfile1