Astuce rapide : AMD Packages

ReneRubalcava

<\/HEAD>

<\/P>

<\/P>

Peut-être que vous êtes nouveau dans l'ArcGIS API for JavaScript ou peut-être êtes-vous un utilisateur expérimenté, mais à un moment donné, je suis sûr que vous avez exploré en profondeur AMD<\/A> et le JavaScript modulaire.<\/P>

<\/P>

J'ai écrit quelques articles à ce sujet auparavant, dont un intitulé

Embrace your AMD modules<\/A>, ainsi qu'un article sur les builds personnalisés<\/A>. J'ai même enregistré une vidéo sur l'utilisation de la version Bower de l'ArcGIS JS API<\/A>.<\/P>

<\/P>

Une question revient assez souvent, c'est celle des packages.<\/P>

<\/P>

Qu'est-ce que c'est et pourquoi est-ce important ?<\/H2><\/P>Ne vous inquiétez pas, les packages sont un concept qui m'a aussi dérouté à un moment donné. On peut considérer les packages comme des espaces de noms, similaires à ce que vous pourriez voir en Java<\/A> ou dans un autre langage.<\/P>

<\/P>

Détaillons quelques déclarations, en utilisant la syntaxe ES5 par défaut.<\/P>

<\/P>

define(["esri\/map"], function(map) {});<\/PRE><\/P>Ce que nous faisons ici, c'est demander le module map<\/EM> du package esri<\/EM>. L'ensemble de l'ArcGIS API for JavaScript se trouve dans le package esri<\/EM>. Il y a d'autres dépendances provenant d'autres packages comme dojo<\/EM> ou dojox<\/EM>.<\/P><\/P>En général, vous n'avez pas besoin de trop vous soucier des packages si vous construisez une application simple. Si vous utilisez le CDN de l'API, vous connaissez probablement cette 

petite astuce<\/A> pour utiliser votre code local.<\/P>

<\/P>

Utilisation des packages<\/H2><\/P>C'est très bien, mais si vous utilisez la version Bower de l'API<\/A> et que vous souhaitez faire des builds locaux personnalisés, c'est là que les packages comptent. Parce que vous devez informer le système de build Dojo des packages dont il doit être conscient. La façon la plus simple de faire cela est d'ajouter le package esri<\/EM> et ses dépendances sous un dossier source. Le code de votre application doit aller dans un dossier app<\/EM>.<\/P><\/P>Cela signifie que vous aurez une structure d'application similaire à ceci.<\/P><\/P>src
  app
  dgrid
  dijit
  dojo
  dojox
  dstore
  xstyle
  put-selector
  esri<\/PRE><\/P>Vous pouvez lire ce guide<\/A> pour savoir comment faire installer Bower dans votre répertoire source. Maintenant, vous pouvez indiquer au système de build Dojo quels packages il doit connaître dans votre profil de build.

  packages: [
    \/\/'app' est un chemin exemple pour votre application
    \/\/'à définir en conséquence
    'app',
    'dijit',
    'dojo',
    'dojox',
    'dstore',
    'dgrid',
    'xstyle',
    'put-selector',
    'esri'
  ],

Vous pouvez voir un

exemple de profil de build ici<\/A>. Si vous ajoutez plus de bibliothèques, comme Bootstrap<\/EM> et jQuery<\/EM>, vous pouvez simplement les ajouter à la liste des packages.
Cependant, au final, les packages ne sont rien d'autre qu'un moyen de garder votre code organisé.
Cependant, ce n'est pas la fin de l'histoire pour les packages<\.EM>. Il y a plus de détails à apprendre pour informer le système de build Dojo qu'un dossier est un package et qu'il s'agit d'un package AMD. Il y a même des choses que vous pouvez faire pour ignorer les répertoires tests qui pourraient se trouver dans votre dossier package.
Je couvrirais ces détails la prochaine fois !<\.STRONG>

Pour plus d'astuces geodev, consultez mon blog.