Last modified: 2011-09-27 16:40:06 UTC
Created attachment 8538 [details] proposed patch Sometimes userscripts need to know about the registrated modules, mostly about their state. A further enhancement could be something like mw.loader.getModules = function() { return Object.keys(registry); } but I don't think is really needed. My patch also resolves inconsistencies in the naming conventions of getters and setters; I think there should be a clear difference.
r88185 & r88184
Just curious, but what exactly is the usecase behind this ? Currently in trunk resourceloader is becoming more asynchronous, so states maybe changing rapidly and in unexpected orders. I couldnt' think of any obvious usecase where a module would want or need to know the load status of another one. Please enlighten me so we can write tests for this to make sure whatever you do with this will keep working in ResourceLoader 2.0. -- Krinkle
It's not so much about getting the loading state, it's about knowing whether a module is loaded/does load or not. For example there might be user scripts that enhance modules. They can't use loader.using, because that would load the module even when it's not needed. Of course there may be other methods to determine whether a module is loaded on the current page (like simple [list, of, page, names].indexOf(wgPageName)>-1), but it would be better if the resource loader had an api for that.
Do you want to determine whether a module is registered or loaded ?
No, it's not interesting whether a module is available or not (that doesn't change for each page), I want to know whether it is (or will be) used. Maybe it would be a better idea to make the load-event public than to allow checking the load state.
