This approach tries to allow the minimum set of changes to allow more real world experimentation with a working and deployed require() approach. I am just giving an option particularly since there are many choices with how a require function could be designed. I completely understand if you feel this does not fit in with jQuery's goals for script loading.
Make sure jQuery ready callbacks are not fired until any scripts require is tracking finish loading.
RUNJS ACTIVATION KEY PATCH
The monkey patch would also be very ugly. It is not very robust to try to monkey patch jQuery after it loads. Ideally these sorts of changes would not be needed in the jQuery source, but I do not see another way to do them, particularly since jQuery could be inlined with some other scripts that may register ready callbacks. Only jQuery users who care about modular script loading have to take the require() cost.The f in RequireJS allows multiple versions of jQuery to exist on the page in a more flexible way than jQuery.noConflict().Allows jQuery to be required, meaning a page can have a small bootstrap via RequireJS and load jQuery after page load.The require function is provided by RequireJS. This is a possible way to tie in a require function for jQuery without having to build it in directly to jQuery. I submitted a pull request that demonstrates how a simple integration might work without having to build require() functionality into jQuery itself: These numbers were generated by typing in "make" and looking in the dist directory. With the baseline build of RunJS integrated with today's jQuery master, the file sizes break out like so: However, with this ticket, jQuery would be the first one to integrate RunJS, if jQuery chooses to do so.
RUNJS ACTIVATION KEY CODE
I also plan on approaching other toolkits to try to get it as the baseline code loader that works well in the browser. RunJS is capable enough to handle larger Dojo projects with many nested dependencies. I can already convert the Dojo 1.4.0 code to use it, but the i18n bundles for layers is are not fully optimized yet. I am working with Dojo to get RunJS integrated in any future efforts for that toolkit. I am happy to make changes to RunJS if there is something that would help make it easier to integrate jQuery. The build tools with RunJS could allow each piece of jQuery to be used on its own - each component JS file can specify its dependencies and the RunJS build will make it easy to create custom versions of jQuery. This makes it nice if multiple versions of jQuery needed to be loaded in the page with their own dependencies. Given the "no global modules" approach that is supported by RunJS, it would be possible to construct jQuery so that it would not need to create a global jQuery object.
I believe starting jQuery off using a stand-alone loader instead of something that is only accessible inside of jQuery (like via a $.require) will make it harder in the long term to have jquery code interoperate with other modules in the future. Here is a patch to jQuery that integrates RunJS, in a similar fashion as Sizzle: Here are specific instructions that detail how it can be used with jQuery now (links to a downloadable sample at the end): Here are the requirements RunJS is trying to meet: It is a standalone project and recently relicensed to be a tri-license like Sizzle: I propose RunJS as the code loader for jQuery. This is an alternative proposal to a $.require() function.Ĭode loading in the browser is a cross-library concern, and I believe it is best served by something that can be a stand-alone script, something that can be used to load even jQuery itself.
0 kommentar(er)
