Hi,
I have a simple notebook that was running perfectly and today no more.
It is really annoying. Demo time.
Resources (from require) seems available yet.
Sorry to hear that! Just so I understand… are you saying that the leaflet.sync require statement worked before and now it is not working? I see the same behavior atm, but wondering if it actually worked before…
It never did, you just forgot the .catch(). Take a look at https://cdn.jsdelivr.net/npm/leaflet.sync@0.2.4/L.Map.Sync.js and you’ll see that there’s no UMD support. The file is meant to be included directly in the browser and expects the global variable L to be present.
you tell d3-require to attempt to load the script, and suppress any errors. d3-require creates a script element with the script URL as src, attaches it to the document, waits for the UMD module to register itself (via window.define()), fails, and throws the error “invalid module”. .catch() suppresses the error.
This pattern is often used in combination with, e.g., .catch(() => window.Foo), where Foo is a global variable created by the loaded script. This allows other cells to 1. wait for the library to load, and 2. reference it via its loading cell, instead of via window.
No idea, tbh. For this to work in the past, cells would have to have received the global variable instead of the cell value whenever a global var of the same name was defined.
One of the problems here is that multiple versions of Leaflet are being loaded. At the top-level, you’ve requested version 1.7.1, but one of the other libraries you’re loading has a transitive dependency on leaflet, too, resulting in the latest version 1.8.0 also being loaded. I put your libraries into the package dependency visualizer here:
If you want to load a complicated network of dependencies like this, your best bet is to use require.alias to define all of the versions you want to load explicitly. As an added bonus, if you define the dependencies explicitly, require won’t have to load the package.json files to resolve the versions, so everything will load faster. And you can also load things faster by using Promise.all to load in parallel.
The leaflet module is UMD, so it works great with require. But the various plugins do not; they are simply vanilla JavaScript, pre-ES modules, and they expect the leaflet module to define the L global. This is why you must await r("leaflet") before loading the other modules, rather than being able to load them in parallel.
The leaflet plugins mutate the L global, so you don’t need the return value resulting from loading them. An empty catch is enough to ignore the error (since these modules don’t implement AMD/UMD).
Leaflet and its plugins also use global stylesheets, but do not insert them into the document automatically, so you need to do it. Also, you want to avoid inserting them multiple times, ideally, if the L cell is re-run. I used a flag L._style to check whether I’ve already inserted the stylesheets to avoid this, but it also means that you might need to reload the notebook if you change the definition of L.
When resolving the stylesheets, you want to be consistent with the version of the module you are using, so I included them in require.alias, too. I think that means that the subsequent require.resolve calls resolve synchronously, so it’s fine to await them in series; if these were really asynchronous, you’d want to include them in the Promise.all so they can be done in parallel, too.
First of all. Many thanks for having taken the time to make this really good support on this tricky problem when loading resources.
I have finally used leaflet 1.8.0 and have noticed no problem with it.
A problem still persists when I use the Export button (after having added 2 maps).
I get this message in the new thumbnail. If I reload the page, then the maps appear.
Sometimes also after a reload of the notebook, the problem is visible.
Do not know how to solve this problem again. Sorry.
Yeah, so the problem is that leaflet-timedimension implements UMD, which is good!, but means you can’t use the same catch pattern you’re using for the other Leaflet plugins that don’t implement UMD. Instead of this:
I am half thinking of streamlining this process to create a subscription monitoring service for like $10 a month and it will auto monitor all public notebooks for errors, would you be interested?
Any news on this issue.
The “export map” produces this error.
If I insist by reloading and reloading. it works.
So a problem again when loading ressources.
But I think the real answer is probably that you should transpile and bundle Leaflet and all the plugins into a modern ES module so that you can load it without all these race conditions. Given that each of these Leaflet plugins uses a different style of export (which is perfectly representative of the insanity solved by the ES modules standard), I’m not sure it’s possible to load this set of libraries reliably using require.