Closed csnover closed 9 years ago
I believe the "dynamic" property should be removed from the API. I have not found a way to reliably support it, and I do not see it working in ES6 either. Maybe an alternate solution for a per-module differing value would be to use map config to map to different loader plugin IDs that have different resource ID segments.
It was added originally I think based on Rawld's motivations to try to support it. However, the requirejs set of loaders do not support it, and based on the listserv discussion about it, it seemed difficult for others to support too:
https://groups.google.com/forum/#!topic/amd-implement/ASREn674nSk
All that said, if you want to prep a pull request for that dynamic property text update, feel free to do so and I can merge it, but it would be good to get more feedback from loaders that do support it.
OK. I am OK with removing it as well. If features can’t be migrated to ES6 modules then they should not exist.
+1. AMD should be evolving in the direction of ES6 modules. @jrburke do you have a list of reference for which loaders support dynamic plugins? (Inject does not)
I do not. As far as I know, only @rcgill in dojo's loader, and @unscriptable in cujojs expressed interested in the dynamic option, so would be good to hear from them.
Only curl.js's deprecated js! plugin uses the dynamic option. -- J
On Fri, Dec 12, 2014 at 2:17 PM, James Burke notifications@github.com wrote:
I do not. As far as I know, only @rcgill https://github.com/rcgill in dojo's loader, and @unscriptable https://github.com/unscriptable in cujojs expressed interested in the dynamic option, so would be good to hear from them.
— Reply to this email directly or view it on GitHub https://github.com/amdjs/amdjs-api/issues/24#issuecomment-66820626.
┏( ^◡^)┛ ┗(^◡^ )┓ I rock RaveJS! ┏( ^◡^)┛ ┗(^◡^ )┓
@rcgill isn’t currently an active contributor, I am currently the primary person managing the Dojo loader. It seems like there is a consensus among loader authors to remove the dynamic option. Is this something where I should create a pull request with the change?
First, a little history. When we (mostly James, John, and myself) negotiated the plugin spec, I argued that the loader should not provide any caching of plugin results--which is basically the dynamic option. My arguments against any plugin result caching in the loader were as follows:
At the time, these arguments were convincing enough to include the dynamic option. In hindsight, nobody is happy. I am unhappy about the extra logic caused by caching and the normalize functionality, which inclusion defeats optimizations possible with non-caching designs. In my own work done for private clients, when and where it’s important/required, I provide optimized AMD-based systems where the loader all but disappears. I suspect others do the same. For the wider community, it seems these kinds of systems are not valuable. If this is the case, then it seems reasonable to dispose of them.
@csnover: there were some historical reasons that the dojo/text plugin needed to be dynamic…primarily that some very large clients had code and builds that used other techniques for loading text. I you decide to go forward and remove this from the dojo loader, you might want to query those clients first. Feel free to email me with questions and I’ll try to help where I can.
Given the lack of use, I am fine if @csnover does a pull request to remove the sections, I can merge. It will also be more in line with what I believe will be in ES6, where the loader will track module export objects, and provide hooks for a loader plugin type of system to participate in different parts of the loader pipeline.
How does this work in the case where you are using CJS wrapper syntax?:
With the spec as written, this would be valid:
require('dynamic-plugin!foo')
fails because the result was not cachedI would suggest an update to the spec stating that the value of the dependency should be cached until after the factory function holding the dependency has executed.