Template for a new custom web app

1245
12
Jump to solution
02-28-2023 06:51 AM
MichailMarinakis1
Occasional Contributor II

Hi all, 

4 years ago, we created a production application based on arcgis js cli. During these years, we have created a lot of custom widgets for this app, following esri documentation, and we have migrated from:

  • JS version 4.13 to 4.26,
  • AMD to ESM,
  • webpack 4 to 5,
  • typescript 3.1.1 to 4.7.4,
  • calcite maps 0.0.9 to calcite design 1.0.7 (partially, still on going),
  • ... 

Everything is working like charm and all the necessary tools to deploy to a production environment were included with the cli e.g. service workers, minification, PWA, etc. It saved us a loot of time! We considered that the cli was the tool to build production custom web applications.

We want to start developing a new custom web app. We found out that the arcgis-js-cli is going to be deprecated (with a recommendation to use vite).

We have been looking at the repo https://github.com/Esri/jsapi-resources:

  • The custom widget sample has a deprecation flag (with a comment to use the UI component library of our choice (like react? so it is recommended not to use the UI framework of custom widgets? ))
  • We noticed also a strong promotion of vite at most of the samples, instead of webpack.
  • There are not so many typescript samples, even though it is promoted from the documentation here.

What we are looking for is, a stable, "building for production", template to give us a boost start. So the question is, if we want to start creating a new custom web app, is there any official best practices/documentation/resources/recommended tools from esri? 

I know there is no single answer, there are a lot of parameters to make a decision like that, just wondering if there is a consensus in the forum here or something that is already discussed between esri developers 😀

Thank you!

@DasaPaddock 

@AndyGup 

@ReneRubalcava 

@BenElan 

 

1 Solution

Accepted Solutions
AndyGup
Esri Regular Contributor

For fully custom widgets, use the UI library of your choice. We want to re-evaluate how custom widgets work. Additionally, the JS Maps SDK uses legacy TypeScript decorators, and we have documented that for custom widgets you need to set useDefineForClassFields to false. This could potentially limit the TypeScript target that you want to use, in the future. And there are also new decorator changes coming in TypeScript 5.0 that we need to investigate.

View solution in original post

12 Replies
AndyGup
Esri Regular Contributor

Hi @MichailMarinakis1 thanks for the questions, and we are glad everything worked like a charm.

Correct, as you are discovering there isn't a one-size-fits-all solution to implementing custom applications built with modern JavaScript build tools, templates and frameworks. There are many excellent third-party choices, they all have their area of expertise and they iterate, constantly. Our recommendation is to prototype a variety of approaches and see what works best for you and your organization's unique requirements. Our goal for the JavaScript Maps SDK is to work with the widest number of these.

That's what happened with arcgis-js-cli, over time the variety and advancements of modern choices for ESM developers made its' interpretation of project scaffolding obsolete.

MichailMarinakis1
Occasional Contributor II

Hi @AndyGup , 

thanks for the reply! Just to clarify, if we start to develop a new custom web app, is it OK to use esri custom widgets UI framework ? We got a bit worried with this deprecation flag at the github project 😅

0 Kudos
AndyGup
Esri Regular Contributor

For fully custom widgets, use the UI library of your choice. We want to re-evaluate how custom widgets work. Additionally, the JS Maps SDK uses legacy TypeScript decorators, and we have documented that for custom widgets you need to set useDefineForClassFields to false. This could potentially limit the TypeScript target that you want to use, in the future. And there are also new decorator changes coming in TypeScript 5.0 that we need to investigate.

MichailMarinakis1
Occasional Contributor II

Great, it's more clear for us now! Thank you for the response

0 Kudos
GIS_Weasel
New Contributor III

Andy,

we're in the same position as @MichailMarinakis1 here, but I personally don't think this response adds anything -- simply repeating "For fully custom widgets, use the UI library of your choice" isn't helpful; I saw that in the repo and was concerned enough to search here for a response.

We're migrating some legacy content from 3.x to 4.x, and don't have a large development team. If Vite is a dead end, I'd appreciate a handle on what is going to be supported long term, and what the best-practice development toolchain for this looks like.

Kind regards.

0 Kudos
AndyGup
Esri Regular Contributor

Hi @GIS_Weasel  we are going to clarify the deprecation wording and sync that up with any SDK documentation pages. The good news is only the custom widget sample, itself, is being deprecated. You can continue to use Vite, you can extend the capabilities of the 4.x esri/widgets/Widget class, and you can continue to use the SDK's viewModels. Note that the React and Vue samples are using Vite, and so are the downloadable ESM-based SDK samples. Our goal is for the SDK to be compatible with all the major frameworks and module bundlers.

With regards to migrating custom 3.x content to 4.x, building custom UI within frameworks such as React, Angular or Vue is best done using their respective UI patterns and practices. Of course, you can also continue to use 4.x OOB SDK widgets within the MapView/SceneView. And, you can also incorporate the Calcite Design System: https://developers.arcgis.com/calcite-design-system/.

 

GIS_Weasel
New Contributor III

Thanks Andy, much clearer.

0 Kudos
MichailMarinakis1
Occasional Contributor II

I have a following up question 😃

Normally, using custom widgets, we were able to extend existing esri widgets to custom ones. A sample of the code is below:

import { subclass } from "@arcgis/core/core/accessorSupport/decorators";
import Editor from "@arcgis/core/widgets/Editor";
import { CalciteFlowItem } from "@esri/calcite-components/dist/components";

@subclass("app.widgets.ErrorReporterEditor")
export default class ErrorReporterEditor extends Editor {
    constructor(properties: __esri.EditorProperties) {
        super(properties);
    }
    render() { }
}

 

We could do the same for the "View" of the widget i.e. the tsx and/or the "ViewModel" of the widget e.g. 

import { subclass } from "@arcgis/core/core/accessorSupport/decorators";
import { fetchMessageBundle } from "@arcgis/core/intl";
import SearchViewModel from "@arcgis/core/widgets/Search/SearchViewModel";

@subclass("app.widgets.GlobalSearch.GlobalSearchViewModel")
export default class GlobalSearchViewModel extends SearchViewModel {
    private refineYourSearchMessage: string = "";

    constructor(params?: any) {
        super(params);
        this.init();
    }
}

 

If we use a UI library of our choice, then are we able to do something similar? 

For example, if we could not extend esri widgets in react, then do we need to recreate e.g. the Search Widget with web/react components from scratch, instead of just extending it? 

0 Kudos
AndyGup
Esri Regular Contributor

@MichailMarinakis1  correct, you can extend the ViewModel. And, creating fully custom widgets means building your own functionality either by extending the Widget base class, or building from scratch using a UI library.

And, correct, we no longer provide the out-of-the-box widgets View files. There was little-to-no abstraction with the core internals, and that made for a very brittle approach, lots of breaking changes and limited our ability to upgrade capabilities.

Here's a ViewModel example: https://developers.arcgis.com/javascript/latest/sample-code/sketch-viewmodel-styler/.