<\/P>
De temps en temps, quelqu'un me demande comment structurer son application ArcGIS JS API. Dans mon livre<\/A>, je recommande la structure d'application suivante :<\/P><\/P>app\/<\/STRONG><\/SPAN><\/P> |-- css\/<\/STRONG><\/SPAN><\/P> |-- js\/<\/STRONG><\/SPAN><\/P> |-- controllers\/<\/STRONG><\/SPAN><\/P> |-- services\/<\/STRONG><\/SPAN><\/P> |-- utils\/<\/STRONG><\/SPAN><\/P> |-- widgets\/<\/STRONG><\/SPAN><\/P> |-- main.js<\/STRONG><\/SPAN><\/P> |-- run.js<\/STRONG><\/SPAN><\/P> |-- index.html<\/STRONG><\/SPAN><\/P><\/P>J'ai utilisé cette structure d'application pour beaucoup de projets et cela a bien fonctionné. Typiquement, mon run.js<\/STRONG> ressemblait à ceci :<\/P>(function() { 'use strict'; var pathRX = new RegExp(\/2F[^\/2F]+$\/2F) , locationPath = location.pathname.replace(pathRX, ''); require({ packages: [{ name: 'controllers', location: locationPath + 'js/controllers' }, { name: 'widgets', location: locationPath + 'js/widgets' }, { name: 'utils', location: locationPath + 'js/utils' }, { name: 'services', location: locationPath + 'js/services' }, { name: 'app', location: locationPath + 'js', main: 'main' }] }, ['app']);})();<\/PRE><\/P>Cela fonctionne assez bien. Mais une chose qu'il ne prend pas en compte est de traiter l'app et tous les sous-modules comme un package app<\/STRONG>. Cela concerne davantage le traitement de mes modules comme des packages lors de l'utilisation du CDN. Quelle est la différence ?<\/EM> Heureux que vous demandiez !<\/P><\/P>Disons que vous voulez construire votre application. Peut-être allez-vous utiliser le ArcGIS optimizer<\/A> ou esri-slurp<\/A>, qui a un excellent exemple ici<\/A> d'ailleurs. Vous voudrez traiter votre application comme son propre package. Que veux-je dire par là ? Eh bien, regardons comment vous utilisez l'ArcGIS JS API.<\/P><\/P>require(['esri/map', 'dojo/declare'], function(Map, declare) {\/*cool stuff*\});<\/PRE><\/P>Dans ce cas, esri<\/STRONG> est un package et dojo<\/STRONG> est un package. Il y a d'autres packages inclus dans l'API, tels que dgrid<\/STRONG>, dstore<\/STRONG>, et diijt<\/STRONG>. Cela parce que lorsque vous utilisez le système de build Dojo<\/A>, il sait comment référencer les fichiers. Donc vous pouvez naturellement empaqueter votre application comme son propre package, appelé app<\/STRONG>. Vous pouvez l'appeler Sally si vous voulez, mais supposons que app fonctionne très bien.<\/P><\/P>Ainsi ces jours-ci, la façon dont j'aime structurer mon app est similaire à ceci.<\/P>index.html<\/STRONG><\/SPAN><\/P>dojoConfig.js<\/STRONG><\/SPAN>
app\/<\/STRONG><\/SPAN><\/P> |-- css\/<\/STRONG><\/SPAN><\/P> |-- js\/<\/STRONG><\/SPAN><\/P> |-- controllers\/<\/STRONG><\/SPAN><\/P> |-- services\/<\/STRONG><\/SPAN><\/P> |-- utils\/<\/STRONG><\/SPAN><\/P> |-- widgets\/<\/STRONG><\/SPAN><\/P> |-- main.js<\/STRONG><\/SPAN><\/P> |-- run.js<\/STRONG><\/SPAN><\/P> |-- index.html<\/STRONG><\/SPAN><\/P><\/P>J'ai utilisé cette structure d'application pour beaucoup de projets et cela a bien fonctionné. Typiquement, mon run.js<\/STRONG> ressemblait à ceci :<\/P>(function() { 'use strict'; var pathRX = new RegExp(\/2F[^\/2F]+$\/2F) , locationPath = location.pathname.replace(pathRX, ''); require({ packages: [{ name: 'controllers', location: locationPath + 'js/controllers' }, { name: 'widgets', location: locationPath + 'js/widgets' }, { name: 'utils', location: locationPath + 'js/utils' }, { name: 'services', location: locationPath + 'js/services' }, { name: 'app', location: locationPath + 'js', main: 'main' }] }, ['app']);})();<\/PRE><\/P>Cela fonctionne assez bien. Mais une chose qu'il ne prend pas en compte est de traiter l'app et tous les sous-modules comme un package app<\/STRONG>. Cela concerne davantage le traitement de mes modules comme des packages lors de l'utilisation du CDN. Quelle est la différence ?<\/EM> Heureux que vous demandiez !<\/P><\/P>Disons que vous voulez construire votre application. Peut-être allez-vous utiliser le
require(['esri/map', 'dojo/declare'], function(Map, declare) {\/*cool stuff*\});<\/PRE><\/P>Dans ce cas, esri<\/STRONG> est un package et dojo<\/STRONG> est un package. Il y a d'autres packages inclus dans l'API, tels que dgrid<\/STRONG>, dstore<\/STRONG>, et diijt<\/STRONG>. Cela parce que lorsque vous utilisez le
var dojoConfig = {
Le cmv-app a une structure d'application intéressante utilisant une base de configuration similaire à ce starterkit sur lequel je travaillais.<\/P>
La clé ici, que vous aimiez mes conseils ou non, est de choisir une structure qui fonctionne pour vous. Vous pourriez faire en sorte que votre main.js fonctionne comme le contrôleur de l'application et simplement avoir un dossier widget avec tout votre contenu UI. Encore une fois, tant que cela fonctionne pour vous, tout est prêt.<\/P>
Je vais écrire un article de blog de suivi qui parle de l'étape suivante ici, qui est la création d'une build personnalisée de votre application. Ça devrait être amusant !<\/P>
Pour plus d'astuces et conseils geodev, consultez mon blog.<\/P><\/BODY><\/HTML>
Great article, We have been doing a lot of Flux and React lately and are using tons of open source build tools and the last thing for us to integrate is downloading the API from either the Optimizer or esri-slurp and plugging it into our build system. I think the examples here may be a good step in the right direction for us.
Cant wait to see the follow up on creating a custom build with Dojos build system, I am very curious to see how that all works since thats something I have never dug deep into. We are currently using RequireJS optimizer for our builds just because of the simplicity of it.
r.js will get you about 75%+ of the way there depending on what you are using in your app. Main issue with r.js is that it attempts to execute loader plugins during compilation and will fail on most instances that try to access the DOM, since it's run in Node. Dojo gets around this by using plugin helpers during the build process that r.js does not have. So you can get close to a single-file build, but there are still some modules that will need to be lazy-loaded.
Then there is i18n, which will always be lazy-loaded unless you include all the locales you would need into your build.
The requirejs loader is also missing some methods that Dojo has, mostly for cross-domain loading.
Yea the executing of the plugins was a gotcha at first for me. It use to throw module not found errors because it could not resolve the dojo plugins. I had some success if the loader plugin was a local module but not if I used the dojo loader plugins.
However I don't use plugins in our apps anymore or any of the other extras. I use react to render my views have been playing with different methods for css. Right now I am injecting critical css into the head and then loading our single javascript bundle, then once that is loaded I lazy load the remaining css. This worked and was able to boost my page speed insights score a bit but did require a slightly different setup.
We originally chose r.js at first because it was simple and we did not need any extras, but I would love to see a writeup on dojos to see what else it can offer and if there is anything that can simplify our current process.
Les membres connectés peuvent publier, suivre les mises à jour, et plus encore. Nouveau ici ? Inscrivez-vous gratuitement.
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.