4.X Migration Issue

SteveCole

I had hoped that I could just fade into the sunset with my 3.x JS API application and not have to migrate it to 4.x but the slow & delayed pace of Experience Builder functional parity makes me feel like I'll have to migrate it. The app I have is what I would call "plain" vanilla and just uses the JS API and Dojo components available when using the API. In other words, I'm not doing any React, Typescript etc. When I developed it, I used the example in the 3.x API documentation where I created custom modules to group together my app's functionality and then load/reference them as it is outlined here under Step 4 (Load a custom module) in the Documentation.

Is this method/practice still valid with the 4.x API or should I be doing this some other way? My app breaks when it hits the Require statement in my main JS file and attempts to reference the custom module. The error thrown provides zero detail as to the issue so I'm mystified as to why it's failing at that point.

Steve

JoelBennett

Yes, it's still valid, but getting everything set up is slightly more complicated than previously. Migrating from 3.x would've been a bit easier prior to 4.20, because dojo was still packaged with the API in those days. When I migrated our platform in the days of 4.16 - 4.18, I was able to eliminate about 94% of the references to dojo, but some of those remaining references still exist to this day (although with charting components hopefully coming out of beta in the near future, we might be ready for the final push to remove dojo entirely). When the dojo-less 4.20 came along, I thought "oh, I'll just load dojo from the 3.x install instead", but it didn't work out that way, because the 3.x loader and the 4.x loader didn't play nice together. To make this work, I ended up copying the dojo, dijit, and dojox folders from the 3.x install into the 4.x install like so:

The screenshot below shows the code for loading dojo separately from the Maps SDK for Javascript&colon;

For good measure, the screenshot below shows the value of the "baseURL" setting in the dojo.js file which matches the environment displayed above:

Hope that helps...

SteveCole

Thanks for chiming in. Yikes. I don't like this version of Chose Your Own adventure. My original post might have led to some confusion so let me clarify- my "modules" aren't Dojo/Digit dependent per se- I'm just using the technique to break up all my code into smaller blocks based on functionality. For example, one module might have all the pop up content generating functions, another module generates a custom report. I may use an odd dojo item (dojo.number.format) but mostly they reference to JS API items like queryTask or Geometry.

It just seems like no matter what is actually inside the module, it will choke. I've tried pared down versions and the end result is the same. Here's an ESRI JS API only version with a blank function:

String.prototype.toProperCase = function () {
    return this.replace(/\w\S*/g, function(txt){return txt.charAt(0).toUpperCase() + txt.substr(1).toLowerCase();});
};
define ([
	"esri/geometry/Extent",	
	"esri/layers/FeatureLayer",
    "esri/SpatialReference",
	"esri/tasks/BufferParameters",
    "esri/tasks/FeatureSet",    
	"esri/tasks/GeometryService",
	"esri/tasks/query",
    "esri/tasks/QueryTask"
], function (
	Extent, FeatureLayer, SpatialReference, BufferParameters, FeatureSet, GeometryService, Query, QueryTask
	) {
		return declare(null,{
			create: function () {
			
			}
		});
});

Here's a simple module from Dojo's website:

define([
    "dojo/_base/declare",
    "dojo/dom",
    "app/dateFormatter"
], function(declare, dom, dateFormatter){
    return declare(null, {
        showDate: function(id, date){
            dom.byId(id).innerHTML = dateFormatter.format(date);
        }
    });
});

Both will error out with the same message. For the heck of it, here are the consoles from my 4.x attempt on the left and the existing 3.x app which works fine. The only difference in dojoConfig I see is that the 4.x dojoConfig specifies baseUrl whereas the 3.x dojoConfig does not.

Again, I'm only using this approach because that's how I did it with 3.x If there's a different (and suggested) way of dividing up / compartmentalizing your code with 4.x, I'm all ears.

JoelBennett

I see...one of the main problems here is you won't be able to use "declare" anymore. After migration, my modules use one of two interchangeable approaches: a vanilla implementation, or extending Accessor:

Vanilla:

define(["esri/Color", "esri/rest/geoprocessor/execute"], function(Color, Geoprocessor) {
	var a = function() {
		function b(options) {
			//this is the constructor
		}

		b.prototype.isAvailable = function(installation) {
			//this is an example member function
		};

		b.prototype.activate = function(toolParams) {
			//this is another example member function
		};

		return b;
	}();

	a.prototype.declaredClass = "myPackage.myFolder.myModule"; //optional

	return a;
});

Extending Accessor (note, uses undocumented "Evented" class to add support for emitting and handling events with "emit" and "on" like in 3.x):

define(["esri/Color", "esri/core/Accessor", "esri/core/Evented", "esri/rest/geoprocessor/execute"], function (Color, Accessor, Evented, Geoprocessor) {
	return Evented.EventedMixin(Accessor).createSubclass({
		declaredClass: "myPackage.myFolder.myModule", //optional

		constructor: function(options) {
			//this is the constructor
		},

		isAvailable: function(installation) {
			//this is an example member function
		},

		activate: function(toolParams) {
			//this is another example member function
		}
	});
});

The error message in your console also indicates it's looking for dojo modules in the ESRI JSAPI, but that was removed in 4.20 (which was what my first post was about). It also shows you're using the API from ESRI's server, but my discussion from the previous post assumes an environment where the API has been downloaded and installed on the local server.

SteveCole

Thanks, Joel. While I have read the announcements about each new 4.x version, these migration issue aspects have definitely not been on my horizon. And yes, as you commented, I am using the ESRI CDN rather than self hosting the API.

In my dojoConfig, I have tried providing a full URL path for my custom modules but it keeps appending that to the end of the core ESRI baseURL. This shouldn't be so difficult but, if I have to append them all into an 8,000 line JS file, I'll do it. 😩

[By the way, I don't actually use Declare in my code base. I didn't know about that getting dropped and it was pure bad luck that I randomly copy/pasted that from the Dojo help pages. Doh!]

JoelBennett

Do you have a constraint preventing you from hosting the API locally? I would definitely recommend hosting it to anybody that can, since it gives more control and less dependencies on third parties.

SteveCole

No, I don't believe I would have any issues doing so. I kinda considered downloading the API as an option to keep my 3.x app running (I know ESRI isn't pulling the CDN plug for awhile but still).

The biggest challenge seems to be finding the actual 3.x download. I keep getting in a circular loop while looking for it. Ugh. I'm too old and too close to retirement to learn NPM. 😆

JoelBennett

It looks like they've taken down the 3.x links. The direct URLs still work though...for now. Go here, copy the URL from the JSON text it outputs, and paste back into your browser.

SteveCole

THANK YOU! Your approach might be the least painful option for me so I'll see if I'm able to incorporate it.