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; } } }

ArcGIS JavaScript programming, single responsibility, singletons and best practices?

YgorThomaz

Hello guys,

I started my programming in two days, my "main.js" file starts getting gigantic and hard to understand.

Do you know any documentation that can help me with the Javascript programming with Dojo and ArcGIS API?
I believe that to minimize the problem will need to singleton for the object map. Questions:

- How do you guys organize your files (.JS)? Separate files for subsequent "compilation"?
- Do you use MVVM?
- Do you use the single responsibility principle for the scope of require([]) (Dojo)?

Thanks, any opnion is welcome!

Finde mehr Beiträge mit dem Tag

Accepted answers

JasonScharf

I work on a moderately sized application (> 50K LOC) that makes heavy use of the JavaScript API.

We use an in-house MVVM library similar to Knockout because it allows us to cleanly separate UI and business code from markup and presentation. It also allows us to avoid writing DOM handling code, instead relying on data-binding attributes to do the work for us. This cuts down on a significant amount of code, and provides a great deal of organization.

We also rely heavily on compilation, compiling many small units of code/markup/CSS into a single JavaScript file. This allows us to keep a large number of modular components separate and organized during development. We find this approach is integral to maintaining non-trivial applications. Dojo's build system has similar functionality, if you go down that route.

I really recommend you take a look at TypeScript if you're planning on writing large applications.

We have recently ported a great deal of our code to TypeScript, as it allows us to write type-safe code and offers code completion in Visual Studio and other IDEs. TypeScript supports classes, modules, namespaces, interfaces, and the upcoming 0.9 release supports Generics. It's totally compatible with JavaScript.

Check it out!

All comments

nicogis

d.ts api js 3.9: https://github.com/Esri/jsapi-resources/tree/master/typescript

I have written a post: http://nicogis.blogspot.it/2014/05/typescript.html

samples: https://github.com/frett27/ESRI-TypeScript-Samples/tree/master/samples

@Jian: Strong Typing is a lifesaver on large projects

http://blogs.msdn.com/b/eternalcoding/archive/2014/04/28/why-we-decided-to-move-from-plain-javascript-to-typescript-for-babylon-js.aspx

MatthewWeyland

TypeScript also supports what are known as "definition files". These are a lot like C headers. They define objects and types and method signatures, often belonging to libraries outside of your control. We use them when coding against dojo, the ArcGIS JavaScript API, and jQuery. They are simply code contracts. They tell us what's available, and how to create objects and call methods upon them without making mistakes and wasting time.

Care to share your d.ts file?

Is this something that ArcGIS would contribute to the DefinitelyTyped project on GitHub

We're looking at this and want to see how this works with Knockout and how well it plays with Tyepscript.

We've been working quite extensively with the Google Maps API and currently have about a 4k LOC rich UI tool for mapping, demographic data, geographies etc. I've encapsulated my interface with the google maps API to only a few objects so I'm hoping making the swap out won't be too bad if I can make them all play together well.

Thanks.

JianHuang

Yes, dynamic typing versus static typing is an old argument starting since LISP, and it's still an argument. Here is a good discussion brought up by Douglas Crockford:
https://plus.google.com/118095276221607585885/posts/MgzNUSTwjRt
In my opinion, I think it's really a personal preference, and I want to write and maintain real javascript code directly so that I have control over everything. That doesn't mean I refuse the help of tools such as JQUERY or DOJO. Translating from another "language" is not my favorite option even though the result seems not unreadable.
Intellisense might be a big plus for many people. Again, it's a personal reference. It's a nice to have feature, especially for programmers whose primary language is not JavaScript.

JasonScharf

Dynamic typing is one of the core concepts of JavaScript, which is powerful. Which one is better is arguable. But since JavaScript has dynamic typing nature, I'm not sure if adding a typescript upon it makes a lot of sense. I haven't compared the performance of typescript. But JavaScript normally has the reputation of "SLOW", you may not want to sacrifice more just for type safe. Once you get used to dynamic typing, you will find it's a very flexible and interesting feature.

TypeScript compiles into pure JavaScript and there's no perfomance hit that I know of. If anything, it's skewed towards better performance and encapsulation. TypeScript produces JavaScript that is essentially what an excellent JavaScript developer would produce when working with namespaces, modules, and "classes".

The dynamic versus static typing argument is an old one. I can't imagine a reason not to want compile-time checking, code completion, etc.

One of the beautiful things about TypeScript is that has strong type inference. Example:

// JavaScript:
var thing = "a b c";

thing = 5; // Totally fine!

var pieces = thing.split(" "); // Run time error: thing.split is not function

// TypeScript:
var thing = "a b c";

thing = 5; // Compile time error: Type of "thing" is string, not number!

var pieces = thing.split(" ");

Strong type inference with TS makes porting existing codebases easy. You get compile-time checking, code completion, static analysis, and all the good things that come with these. The only thing that really changes in TS are namespace and class declarations, as well as method signatures. They gain type annotations.

TypeScript also supports what are known as "definition files". These are a lot like C headers. They define objects and types and method signatures, often belonging to libraries outside of your control. We use them when coding against dojo, the ArcGIS JavaScript API, and jQuery. They are simply code contracts. They tell us what's available, and how to create objects and call methods upon them without making mistakes and wasting time.

derekswingley1

The gas prices by state sample is a simple example that follows the conventions discussed in this thread. The JS API site itself is another example if you example the source.

YgorThomaz

...

To your last point, about "single responsibility principle for the scope of require([])", I think the answer is yes, if I understand correctly. Typically, in things that I build, I create classes (one per AMD module) and then wire them up with a main.js or app.js file which contains a single require(). I don't typically put anything in the global namespace except when debugging. If I find myself with a huge list of dependencies for any require() or define() call, I take that as a sign that it's probably time to refactor and that I'm trying to do too much at one time.

Derek,

Do you have any examples posted to this simple architecture that you described above?

I read all the recommended readings. I decided to start with a simple project, my first goal is to understand the process of initial load of my scripts and JS and how can I work with objects(singletons) that will be used in other classes or modules as the MAP object.

I am creating a prototype to convince the staff that work with javascript is a good idea at this time. But really I'm a little confused right now. I agree with Jian about "typescript" at this time.

Thank you for your attention!

RRubalcava

I had put this demo together a while ago, it's not exactly how I do things these days, but still gives an idea about breaking stuff up into modular pieces.
https://github.com/odoe/AGSModularDemo
For example, I don't use "views" anymore, I changed it to controllers and my widgets are actually all done in Angular.js now.

I used to use r.js to build my apps from when I was still using requirejs, but since the API moved to 3.x, I just use Grunt now.
http://gruntjs.com/

I was finally convinced to go Grunt after talking with one of the AGRC guys about how they use Dojo to do their builds. It's just a lot easier for me to automate my tests, less compiles and minification.
https://github.com/agrc/AGRCJavaScriptProjectBoilerPlate

If I find myself with a huge list of dependencies for any require() or define() call, I take that as a sign that it's probably time to refactor and that I'm trying to do too much at one time.

This is always a good sign that something could probably be broken out. I've taken to writing lots of smaller functions I can string together, which I'm fine with, but a long define/require list makes me feel bad.

JianHuang

Dynamic typing is one of the core concepts of JavaScript, which is powerful. Which one is better is arguable. But since JavaScript has dynamic typing nature, I'm not sure if adding a typescript upon it makes a lot of sense. I haven't compared the performance of typescript. But JavaScript normally has the reputation of "SLOW", you may not want to sacrifice more just for type safe. Once you get used to dynamic typing, you will find it's a very flexible and interesting feature.

JasonScharf

We use a fairly simple custom tool that glues together our code and encodes CSS and HTML into the output .js file, based on configuration files.

Also, I just now got word that TypeScript 0.9 was released today. More info here: http://blogs.msdn.com/b/typescript/archive/2013/06/18/announcing-typescript-0-9.aspx

YgorThomaz

Ty Jason,

What do you use to compiling many small units of code/markup/CSS into a single JavaScript file?

TypeScript is amazing!

JasonScharf

YgorThomaz

We recommend using Dojo's tools for creating classes and modules to manage your code when you start building large apps. Our Dojo and AMD page is the best place to start. You'll find links to writing classes and widgets from there.

Regarding MVVM, we don't typically recommend MVVM, MVC or any other flavor of MVW (model-view-whatever). You can use any MVW framework alongside our API, including Backbone, Angular, Ember...the list goes on. Here's a repo that Matt Driscoll and I put together for examples using Backbone, Angular and Knockout at the Esri Dev Summit earlier this year: https://github.com/driskull/framework-samples-js

To your last point, about "single responsibility principle for the scope of require([])", I think the answer is yes, if I understand correctly. Typically, in things that I build, I create classes (one per AMD module) and then wire them up with a main.js or app.js file which contains a single require(). I don't typically put anything in the global namespace except when debugging. If I find myself with a huge list of dependencies for any require() or define() call, I take that as a sign that it's probably time to refactor and that I'm trying to do too much at one time.

Hello Derek,

I'm reading this article: http://jpenet.blogspot.ca/2012/11/using-amd-pattern-to-create-modular.html

I will take into consideration all your advice.

Thank you!

derekswingley1

We recommend using Dojo's tools for creating classes and modules to manage your code when you start building large apps. Our Dojo and AMD page is the best place to start. You'll find links to writing classes and widgets from there.

Regarding MVVM, we don't typically recommend MVVM, MVC or any other flavor of MVW (model-view-whatever). You can use any MVW framework alongside our API, including Backbone, Angular, Ember...the list goes on. Here's a repo that Matt Driscoll and I put together for examples using Backbone, Angular and Knockout at the Esri Dev Summit earlier this year: https://github.com/driskull/framework-samples-js

To your last point, about "single responsibility principle for the scope of require([])", I think the answer is yes, if I understand correctly. Typically, in things that I build, I create classes (one per AMD module) and then wire them up with a main.js or app.js file which contains a single require(). I don't typically put anything in the global namespace except when debugging. If I find myself with a huge list of dependencies for any require() or define() call, I take that as a sign that it's probably time to refactor and that I'm trying to do too much at one time.

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.