This blog will cover some of the best practices that can be applied to web app development and some to general application development.
While faced with a use case for GIS Web application, or any application for that matter, understand the details of use case to arrive at best possible solution. The solution might not always be development, so beware of fixating on a customisation/development solution when there might be a simpler solution. Keep in mind with higher customisation time and efforts would increasing, in turn increasing the cost. This diagram from Esri summarises levels with minimal efforts that can be considered before taking the leap of customisation.
When Customisation is the chosen path (hopefully you have chosen well), it is equally important to evaluate which version of the ArcGIS JS API that you require. The comparison of versions from the Developer’s page for Javascript is sufficiently detailed. If functionality matches and the app is required to be in a particular framework, React, Angular, Node app, 4.x API has the NPM install support, making it easy for such integrations.
Always Identify the project area, either to a country or region, and set the map extent to the project area. In ArcGIS JS API 4.x, this can be done by specifying the constraints for the map view. The extent geometry of the project area can be used to limit the map area that can be explored. Additionally, set the minimum and maximum scales that is appropriate for the data.
The same extent geometry of the project area can be applied to the Search widget, if used within the application. This makes sure the user will not get search results outside project area.
Performance of web application is often ignored over developing all functionalities of the project. Ensuring the best practices while handling layers on map will reduce load time and overall app performance. Some of the following points are to be considered while adding layers:
Handle errors in all scenarios. Oftentimes the success scenarios are handled while the errors are left hanging. In such cases, when the user faces an error, and yes, they will definitely face an error, the application will not know how to proceed. Anticipating and handling error in callbacks and using try catch segments will save the efforts in the long run for bug fixing.
On the other hand, in 4.x API, if the errors are unhandled, though benign, the console will fill up quickly with errors and warnings. The application would still work, but it is recommended to clean up the console before deploying. In such cases, make sure you catch the error after the activity and handle as required.
This goes without saying, and yes I slack off in this as well. But comment your codes. Comment Comment Comment. Make it your mantra. And pray for the next person who would be working on this project.
Senthil Kumar V is a seasoned Senior Pre-Sales Consultant with over 8 years of expertise in the geospatial field. He brings a wealth of technical proficiency, specializing in GIS, spatial analysis, and remote sensing. His dedication to innovation and effective communication ensures successful client solutions, making him an invaluable asset to our team.
Nimisha Srivastava is a Pre-Sales Consultant who is enthusiastic about the Geospatial field and has great communication skill. She has an year’s experience in the geospatial industry and is always eager to learn new things.
