nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Legacy code vs AMD code

GaneshSolai_Sambandam

Hi GIS folks,
I am really confused with the legacy code vs AMD code. Although, I switched to AMD style of coding in my application and some of the sample/example codes in the ARCGIS javascript api are still in legacy code, because of which I am struggling to run my application as most of the time i end up getting errors. can anyone recommend which style of coding should we follow with v3.6 api.

Regards
Ganesh

Finde mehr Beiträge mit dem Tag

Accepted answers

All comments

JohnGravois

we published a blog post the other day comparing an identical sample written in AMD and legacy patterns. hope its helpful!

abc's of AMD
http://blogs.esri.com/esri/arcgis/2013/10/14/the-abcs-of-amd/

adrian.marsden_DevonCC

I gave it a good try, but for now defeated. I worked out my wkid issue was something to do with my local 3.5 - running it with esr 3.6 moved on to the next errors - a shed load of parser issues.

So, I will put this aside for now, and concentrate on stuff my users are asking for - like a constrained Floatingpane 🙂

Thanks for the help so far - at least I have a better understanding.

ACM

adrian.marsden_DevonCC

Yep - Hjelmeland has been PMing me with lots of suggestions - on the last go we took working code of his and dropped my map service in. It worked on his code. The only difference I can see is if I examine the map object, on the working code we have

spatialReference: Object
latestWkid: 27700
wkid: 27700
__proto__: Object
updating: false
width: 1680
wrapAround180: fal

On mine

spatialReference: Objectwkid: 27700
__proto__: Object
updating: false
width: 1435
wrapAround180: false

for the SpatialReference object - you'll notice the additional "latestWkid" attribute.

Cheers

ACM

Edit nearly there - my code was a horrid mix of legacy and AMD, and I had a new AMD style chunk basically doing the same stuff I'd inserted ages back. Removing this gives me an overview map (breaks loads of other stuff until I reinsert it al in the right place)

Edit #2 No idea - a brief glimpse was lost again 😞 will still work on it.

JeffPace1

have you added layers to your map before creating the overview?

adrian.marsden_DevonCC

OK - slowly making progress, but I am hitting (what I think) are scope issues.

I am creating an overview map. I have the require and attribute all done -

require(["esri/map", "esri/layers/ArcGISTiledMapServiceLayer",
 "esri/layers/ArcGISDynamicMapServiceLayer",
"esri/geometry/Extent",
"esri/layers/FeatureLayer",
"agsjs/dijit/TOC",
"esri/symbols/SimpleFillSymbol",
"esri/symbols/SimpleLineSymbol",
 "dojo/_base/Color",
 "esri/dijit/OverviewMap",
 "dojo/parser",
"dojo/domReady!"
], function (
          Map,
          ArcGISTiledMapServiceLayer,
          ArcGISDynamicMapServiceLayer,
          Extent,
          FeatureLayer,
          TOC,
          SimpleFillSymbol,
          SimpleLineSymbol,
          Color,
          OverviewMap,
          parser
          ) {

then I create the ovmap

 var overviewMapDijit = new OverviewMap({        map: map,
        expandFactor: 2,
        visible: true,
        height: 230,
        width: 230
    });

but get

Uncaught TypeError: Cannot read property 'wkid' of undefined

As if the map doesn't exist - I have a "var map;" earlier of course - what I have, is, more or less the same as https://developers.arcgis.com/en/javascript/jssamples/widget_overviewmap.html

cheers

ACM

CharlesGeiger

I, too, am struggling to convert older code to AMD, and echo many of the earlier posts in this thread, especially requesting that Esri show examples in both legacy and AMD format to help us with the transition. My particular question is why all of the examples involving dynamic map service layers are still in legacy code. Is there some move to separate dynamic map services from tiled and feature services?

adrian.marsden_DevonCC

<lightbulb> (well, low energy, dimmer light bulb, that has occasional brown-outs) I'm sort of seeing it now. Gives me an excuse to totally re-structure my code as I move each bit over from my main init function

RRubalcava

Not to pimp, but I'll pimp a little, you can view a presentation I did at the last dev summit on AMD.
http://video.esri.com/watch/2318/embrace-your-modules-on-amd-and-javascript

There was another good talk about building modular dijits, but doesn't look like it's available.

The transition to AMD from the (ArcGIS JS) pre-3.0 days can be a little bumpy, and it may not be perfect, but it works pretty well.

I am however of the opinion that when you have a dependency array like

function(dom, domAttr, array,Color, parser, esriConfig,Map,Graphic,GeometryService,BufferParameters,Draw,SimpleMarkerSymbol,SimpleLineSymbol,SimpleFillSymbol)

It's a good sign you could use a refactor of some sort.

adrian.marsden_DevonCC

😉 Er, sorry for sounding silly, but aren't those two code blocks identical? I think I know what you mean. Ah I see it now, the Upper case M in the first one and no 'esri'. Doh!

Anyway, it's Friday afternoon where I am, it is sunny and will remain so for the weekend, so I'm off home!

ZachLiu1

If you don't provide args for second function, you are still using dojo modules loaded in traditional way, which exist in the global scope.

The require function creates a local scope, so you can not get access to the modules outside of the require function. The major benefit is your global object is clean.

e.g.

you can write

require(["esri.map"], function(Map) { 
    var map = new Map();
});

or
you can still write

require(["esri.map"], function(Map) { 
    var map = new esri.map();
});

But they work in different ways.

Actually, if you don't load ArcGIS API which automatically load many modules in the old way I guess, the second one won't work.

adrian.marsden_DevonCC

Thanks - that helps a bit- amazingly just having just the modules required and a minimal second arg it still allworks - I guess the rest still being old style just picks up.

Any idea where the link should go to to show "preferred argument aliases for Esri modules" which I guess is the list I add to the second arg for all the modules I am referencing?

ACM

ZachLiu1

first of all, require is just a function.:)

It takes two args.

The first one is an array of all modules you needed for your project. For a Ags API app, it usually includes Dojo modules and ESRI modules.

The second argument is a function whose arguments pair with the modules you required. All arguments in this function (may be a long list) are just references to your loaded modules and you can give whatever names you want, but usually it's a good idea to follow conventions.

It will be better to read this first.

http://dojotoolkit.org/documentation/tutorials/1.9/modern_dojo/

adrian.marsden_DevonCC

Ok - with my major JSAPI project about to be fully live I thought I'd try to get my head around AMD, but failed, almost at the start.

For example the link https://developers.arcgis.com/en/javascript/jsapi/argument_aliases-amd.html on this page https://developers.arcgis.com/en/javascript/jstutorials/ 404s , so I am strugling to work out what exactly the function inside the require is for

<script>
  require(["esri/map"], function(Map) { ... });
</script>

For a simple map it seems only to define the map, but WTF is this all about?

function(dom, domAttr, array, Color, parser, esriConfig, Map, Graphic, GeometryService, BufferParameters, Draw, SimpleMarkerSymbol, SimpleLineSymbol, SimpleFillSymbol)

So, I'm giving up for now, and my code will be a horrid mix for a while.

I may return later when there are better guides

ACM

JasonZou

I like to echo Ken. It's not only the samples need to have both versions, but to provide a way to access all released API as well. Lots of projects were developed under old versions, and when something goes wrong, there is no way to look at the API under which the project was developed. Many organizations aren't willing to take the effort to upgrade to the most recent version as long as the project still works.

kenbuja

I agree this is going to be a bumpy transition. I have several projects written a couple years ago, it's not like I have the time to go back and rewrite everything I've done in the past. I think there should be samples in both styles, so we can see the before and after and get the hang of the differences . That API reference is good about showing both, but the samples are a mixed bag. I'd hate to see every sample move to AMD because I need to see both to know where and how to change my older code.

This is one reason why I wish the Esri would keep the older versions of the samples and documentation on their website, similar to what Dojo does. With Dojo's documentation, you can select which version to see. However, when Esri redesigned their website, there doesn't seem to be a way of seeing the older versions (3.6 vs. 3.5 vs 3.4) of the help pages. It's kind of a pain to download the older SDKs and pick through the html files

TracySchloss

I agree this is going to be a bumpy transition. I have several projects written a couple years ago, it's not like I have the time to go back and rewrite everything I've done in the past. I think there should be samples in both styles, so we can see the before and after and get the hang of the differences . That API reference is good about showing both, but the samples are a mixed bag. I'd hate to see every sample move to AMD because I need to see both to know where and how to change my older code.

ZachLiu1

Once you know what AMD is and how it works, you'll fall in love with it.:)

Here are a few tutorials that can help you grasp it in a short time:

http://dojotoolkit.org/documentation/tutorials/1.9/modern_dojo/

http://dojotoolkit.org/documentation/tutorials/1.9/declare/

http://dojotoolkit.org/documentation/tutorials/1.9/modules/

http://dojotoolkit.org/documentation/tutorials/1.9/modules_advanced/

JasonZou

I started one of my major projects using AMD, and I would highly recommend to use AMD if using v3.6 api with the following reasons.

With AMD style which will load the modules asynchronously, the initial loading performance will be greatly increased.
All JSAPI events are following dojo/on event mechanism now.
AMD will be enforced since dojo 2.0. Dojo is reaching v1.9 now, one more release away from 2.0!
The issue that your module may not work since one of the dependecies is not loaded won't exist if using AMD.
Minimize global variable usage.
and much more...

I can tell ESRI JSAPI team is working hard to make the conversion including the samples. There are some work for the improvement though for the JSAPI team especially on the documentation. I found out that when clicking any event handler (onLayerAddResult) link on AMD style, it won't work. I will have to switch to legacy event style to access the description.

Here are some references:
https://developers.arcgis.com/en/javascript/jshelp/inside_dojo_amd.html
http://dojotoolkit.org/documentation/tutorials/1.9/modules/
http://addyosmani.com/writing-modular-js/

JeffPace1

Hi GIS folks,
I am really confused with the legacy code vs AMD code. Although, I switched to AMD style of coding in my application and some of the sample/example codes in the ARCGIS javascript api are still in legacy code, because of which I am struggling to run my application as most of the time i end up getting errors. can anyone recommend which style of coding should we follow with v3.6 api.

Regards
Ganesh

AMD. legacy is deprecated at dojo 2. we are rapidly approaching that.

Nimm an der Unterhaltung teil

Angemeldete Mitglieder können Beiträge verfassen, Updates folgen und mehr. Neu hier? Registriere ein kostenloses Konto.

Schnellzugriffe

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.