Hi Tomas, big fan of your plugin. We were very sad to see that the plugin wasn’t available in Data Center and it was difficult to work it out of our workflow. Very happy to see you continuing to develop it.
Can you explain to me the rational about making something promise/callback based that is obviously known at page load and should be available synchronously?
By requiring me to dynamically load a module, it means that for instance when using React, I will have to add context resolution to my component state during the componentDidMount() call, use React Context API or an HoC instead of being able to construct the URL during rendering.
The wrm/context-path is a module that is defined in the browser runtime. The AMD module loader will not have to try to load it from the server. Once you specify all the web-resource XML dependencies for WRM module, you will get them loader in the runtime. Additional pros of using the wrm/* module is that you don’t depend on the global variables anymore and you should be able to write a unit test that can mock the wrm/* dependency.
Like I wrote in the previous paragraph. The wrm/* are not dynamically loaded modules. You could write your code using either AMD or ESM (with the help of babel and webpack):