Today the extension contain just a few snippets

But this is just a small subset of all the Symbols.

It would be nice to have snippets for the following classes: (just the ones with the checkboxes; 21 in total)

• CIMSymbol
• WebStyleSymbol. I think adding the enums for WebStyleSymbol2D and the WebStyleSymbol3D is too much
• For 2D Symbols
  • MarkerSymbol (Points)
    • PictureMarkerSymbol
    • SimpleMarkerSymbol
  • LineSymbol (Polylines)
    • SimpleLineSymbol
  • FillSymbol (Polygons)
    • PictureFillSymbol
    • SimpleFillSymbol
  • Text Symbol (Labels)
• For 3D symbols:
  • PointSymbol3D
    • IconSymbol3DLayer
    • ObjectSymbol3DLayer
    • TextSymbol3DLayer
  • LineSymbol3D
    • LineSymbol3DLayer
    • PathSymbol3DLayer
  • PolygonSymbol3D
    • ExtrudeSymbol3DLayer
    • FillSymbol3DLayer
    • IconSymbol3DLayer
    • LineSymbol3DLayer
    • ObjectSymbol3DLayer
    • TextSymbol3DLayer
    • WaterSymbol3DLayer
  • MeshSymbol3D
    • FillSymbol3DLayer

Instead of just the properties:

{
  type: "simple-marker",
  color: [255, 255, 255, 0.25],
  size: 12,
  style: "circle",
  outline: {
    width: 1,
    color: [255, 255, 255, 1]
  }
}

/* Snippet
 "SimpleMarkerSymbol": {
    "body": [
      "{",
      "\ttype: \"simple-marker\",",
      "\tcolor: [255, 255, 255, 0.25],",
      "\tsize: 12,",
      "\tstyle: \"${1|circle,square,cross,x,diamond,triangle,path|}\",",
      "\toutline: {",
      "\t\twidth: 1,",
      "\t\tcolor: [255, 255, 255, 1]",
      "\t}",
      "}"
    ],
    "description": "Create a SimpleMarkerSymbol",
    "prefix": "simpleMarkerSymbol"
  }
*/

I would suggest something like:

new SimpleMarkerSymbol({
  type: "simple-marker", // required only when autocasting
  color: [255, 255, 255, 0.25],
  size: 12,
  style: "circle",
  outline: {
    width: 1,
    color: [255, 255, 255, 1]
  }
})

/* Snippet
"": {
"prefix": "",
"body": [
	"new SimpleMarkerSymbol({",
	"\ttype: \"simple-marker\", // required only when autocasting",
	"\tcolor: [255, 255, 255, 0.25],",
	"\tsize: 12,",
	"\tstyle: \"${1|circle,square,cross,x,diamond,triangle,path|}\",",
	"\toutline: {",
	"\t\twidth: 1,",
	"\t\tcolor: [255, 255, 255, 1]",
	"\t}",
	"})",
],
"description": ""
}
*/

Note: I think these are all symbols. Checking the symbol builder gallery I think I haven't left anything out... 😅

Does it make sense @kellyhutchins ? // cc: @RalucaNicola

I'm not even sure if this is feasible, but I think it would be really nice if we could add a custom icon for the snippets coming from this extension instead of the squared box:

I have been looking at CompletionItemKind and CompletionItemProvider, but I'm unsure how it can be done.

What do you think? Do you know if this is possible?

Looking at #36 I have noticed we have missed better guidelines on how to properly format a commit message and a pull request.

I'm going to work on adding them following ideas from https://github.com/Esri/calcite-design-system/blob/main/CONTRIBUTING.md

I think we can improve the snippet builder by:

• Increase height of body and description fields (calcite)
• Adding checkboxes to be able to select the language snippet scope. It should include the following language identifiers: javascript (JavaScript), json (JSON), css (CSS), html (HTML), scss (SCSS), typescript (TypeScript), typescriptreact (TypeScrip JSX).
• Been able to copy generated snippet to clipboard using a copy-to-clipboard button
• Add button to import snippet (form VS Code)

After yesterday livestream, I think there is room to improve "Getting a development environment set up" (Courtney struggle with our instructions)

So I'm going to send a proposal, CONTRIBUTING.md and including a development environment setup.

Existing JS snippets needs some review and make sure that they follow the conventions we recently added.

Currently we use a default esri icon. This issue is to identify and replace it with a more meaningful icon. Once a new icon has been identified it can be updated using the icon option in package. json

First of all, congrats for this awesome repository :), I would love to contribute but I have no previous experience developing VSCode extensions.

I'm using a Mac, so I have modified the file at ' ~/.vscode/extensions/esri.arcgis-jsapi-snippets-1.1.2/snippets/javascript.json' but I don't know how I can test if it's properly working. How do I do it? Do I need to refresh/reload the extension?

Thanks!!

Note: I would be nice to include the readme / contributing.md simple instructions on how to do it.

If I go to "Help > Toggle Developer Tools" and then open up a VS code project and then open package.json, I see this error:

[Esri.arcgis-jsapi-snippets]: Unknown language in `contributes.arcgis-jsapi-snippets.language`. Provided value: typesccript

Which should be the conventions about the snippet description?

Ideas/questions about how description should be defined:

• Q1: It should be a proper description of what the snippet does, right?
  A: I would say yes, and reuse text from the API reference whenever possible.

• Q2: If it is a snippet related to a class/module, do we recommend including the path to it?
  A: I would say yes (for now, the AMD Module path), but at the end probably, something like: Convert a geometry from Web Mercator units (wkid: 3857) to geographic units (wkid: 4326). Uses: esri/geometry/support/webMercatorUtils.

Hello again!,

Sorry I know this issue is long, but I wanted to share with you some doubts that have arisen while I was creating new snippets and my opinion about them.

As mentioned in the previous issue, I think it would be good if we could try to reach an agreement to define minimum conventions to facilitate the contributions and make them as heterogeneous as possible.

• Q0) Do we use \t instead of spaces?
• Q1) Then snippet should containt a new class init, it constructor properties, or both?
• Q2) When creating new class, do we also assign it to a variable?
• Q3) Should we avoid adding multiple expressions in one snippet?.
• Q4) Do we allow comments?
• Q5) When instantiating a new class, do we add only required fields, the most common ones, all?
• Q6) When the property expects another class but supporting autocasting, what do we do. Add a sample or place the snippet name?
• Q7) When a property is overloaded, should we show all possible inputs?
• Q8) How do we create snippets for inherited methods
• Q9) Do we allow snippets for enums?

Q0) Do we use \t instead of spaces?

{
  "tsconfig-basic": {
    "prefix": "tsConfigBasic",
    "body": [
      "{",
      "\t\"compilerOptions\": {",
      "\t\t\"module\": \"amd\",",
      "\t\t\"sourceMap\": true,",
      "\t\t\"target\": \"es2019\",",
      "\t\t\"esModuleInterop\": true",
      "\t}",
      "}"
    ],
    "description": "Simple TS Config"
}

or

{
  "tsconfig-basic": {
    "prefix": "tsConfigBasic",
    "body": [
      "{",
      "  \"compilerOptions\": {",
      "    \"lib\": [\"dom\", \"es2015.promise\", \"es5\"],",
      "    \"module\": \"amd\", // output files as AMD modules",
      "    \"sourceMap\": true,",
      "    \"target\": \"es5\",",
      "    \"esModuleInterop\": true",
      "  }",
      "}",
   ],
  "description": "Simple TS Config"
}

A: Yes, I think we should if we want to be more friendly to different tab configurations 😄

Q1) Then snippet should contain a new class initialization, its constructor properties, or both?

Ex: simpleMarkerSymbol snippet:

new SimpleMarkerSymbol({
    color: [255, 255, 255, 0.25],
    size: 12,
    style: "circle",
    outline: {
        width: 1,
        color: [255, 255, 255, 1]
    }
})

or

{
    type: "simple-marker",
    color: [255, 255, 255, 0.25],
    size: 12,
    style: "circle",
    outline: {
        width: 1,
        color: [255, 255, 255, 1]
    }
}

A: In my opinion we could add both (and call them something like simpleMarkerSymbol, simpleMarkerSymbolProps) or simply leave the second one. But in that case, I would add the Class name and the module path in the description.

Q2) When creating a new class, do we also assign it to a variable?

Ex: featureLayer snippet:

new FeatureLayer({
    url: "service-url"
    blendMode "service-url":
    effect: FeatureEffect
});

or

const fl = new FeatureLayer({
    url: "service-url"
    blendMode "service-url":
    effect: FeatureEffect
});

A: I think I would remove the variable. But I think it is a minor thing.

Q3) Should we avoid adding multiple expressions in one snippet?.

Ex: webmap snippet:

const webmap = new WebMap({
    portalItem: {
        id: "webmap_id"
    }
});

// Is this necessary?
const view = new MapView({
    container: "viewDiv",
    map: webmap
});

or featureLayer snippet:

const fl = new FeatureLayer({
    url: "service-url"
    blendMode "service-url":
    effect: FeatureEffect
});

// Is this necessary?
map.add(fl);

or disableNavigation snippet:

view.when(view => {
    const stopEvtPropagation = event => {
        event.stopPropagation();
    }

    // Are all these necessary?
    view.on(["mouse-wheel", "double-click", "drag"], stopEvtPropagation);
    view.on("double-click", ["Control"], stopEvtPropagation);
    view.on("drag", ["Shift"], stopEvtPropagation);
    view.on("drag", ["Shift", "Control"], stopEvtPropagation);
    
    view.on("key-down", function (event) {
        const prohibitedKeys = ["+", "-", "Shift", "_", "=", "ArrowUp", "ArrowDown", "ArrowRight", "ArrowLeft"];
        const keyPressed = event.key;
        if (prohibitedKeys.indexOf(keyPressed) !== -1) {
            event.stopPropagation();
        }
    });
    
    return view;
});

A: I think snippets should be as short as possible. If it is to help init a layer we should only do the init and nothing else. In some cases snippets like disable mapview navigation will be larger.

Q4) Do we allow comments?

Ex: queryLayer snippet:

myLayer  // queries all features in the layer
    .queryFeatures().then(results => {
        // queries features and returns a FeatureSet
    })
    .queryExtent().then(results => {
        // queries features returns extent of features that satisfy query
    })
    .queryFeatureCount().then(results => {
        // queries features and returns count of features
    })
    .queryObjectIds().then(results => {
        // queries features and returns objectIds array of features
    })

A: I think it is OK to add comments

Q5) When instantiating a new class, do we add only required fields, the most common ones, all?

E.x: popupTemplate snippet:

Note: do we use comments to indicate which are required? What do we do when none is required?

{
    outFields: ["*"],
    title: "Value: {attribute}",
    id: "myId",
    className: "esri-icon-zoom-out-magnifying-glass",
    content: [popupContent],
    fieldInfos: [fieldInfo],
    expressionInfos: [expressionInfo],
    actions: [ActionButton],
    returnGeometry: true
}

A: I don't have a clear answer to this. I would probably add the most used ones with a // recommended comment or similar.

Q6) When the property expects another class but supporting autocasting, what do we do?. Add a sample or place the snippet name?

E.x: heatmapRenderer snippet:

new HeatmapRenderer({
    field: "crime_count",
    colorStops: [
        { ratio: 0, color: "rgba(255, 255, 255, 0)" },
        { ratio: 0.2, color: "rgba(255, 255, 255, 1)" },
        { ratio: 0.5, color: "rgba(255, 140, 0, 1)" },
        { ratio: 0.8, color: "rgba(255, 140, 0, 1)" },
        { ratio: 1, color: "rgba(255, 0, 0, 1)" }
    ],
    minPixelIntensity: 0,
    maxPixelIntensity: 5000
})

or

new HeatmapRenderer({
    field: "crime_count",
    colorStops: HeatmapColorStop[],
    minPixelIntensity: 0,
    maxPixelIntensity: 5000
})

A: I prefer the snippet name

Q7) When a property can hold different value types, should we add a placeholder to show all possible inputs?

E.x. PopupTemplate properties:

Do we do something like this?

{
    "prefix": "popupTemplate",
    "body": [
      "{",
      "\toutFields: [\"*\"],",
      "\ttitle: ${1|\"Value: {attribute}\",function(){}|},",
      "\tid: ${2:\"myId\"},",
      "\tclassName: \"${3:esri-icon-zoom-out-magnifying-glass}\",",
      "\tcontent: ${4|[popupContent],\"<p>Content</p>\",function(){}|},",
      "\tfieldInfos: [fieldInfo],",
      "\texpressionInfos: [expressionInfo],",
      "\tactions: [ActionButton],",
      "\treturnGeometry: ${5|true,false|}",
      "}"
    ],
    "description": "Create an instance of esri/PopupTemplate. Describe popup content"
}

A: I think it is nice to provide all possible input types, knowing that it might not always be up-to-date. Knowing that in case of been using @types/arcgis-js-api it might be kind of duplcated (but it still can add some value like specify the value that needs to be returned by the function, or the sintax to use in the string can referer to geometry fields:

Q8) How do we create snippets for inherited methods

Ex: method fromJSON() inherited in the SimpleRenderer, UniqueValueRenderer, HeatmapRenderer, etc.

Do we do something like this?:

${1|Simple,UniqueValue,ClassBreaks,Dictionary,DotDensity,Heatmap|}Renderer.fromJSON(json)

A: to make them generic I would try to do so.

Q9) Do we allow snippets for enums?

Ex:

• rendererTypes: "class-breaks"|"dictionary"|"dot-density"|"heatmap"|"simple"|"unique-value"
• basemapStyle: arcgis-imagery,arcgis-imagery-standard,arcgis-imagery-labels,arcgis-light-gray,arcgis-dark-gray,arcgis-navigation,arcgis-navigation-night,arcgis-streets,arcgis-streets-night,arcgis-streets-relief,arcgis-topographic,arcgis-oceans,osm-standard,osm-standard-relief,osm-streets,osm-streets-relief,osm-light-gray,osm-dark-gray,arcgis-terrain,arcgis-community,arcgis-charted-territory,arcgis-colored-pencil,arcgis-nova,arcgis-modern-antique,arcgis-midcentury,arcgis-newspaper,arcgis-hillshade-light,arcgis-hillshade-dark
• symbolTypes: "simple-marker"|"picture-marker"|"simple-line"|"simple-fill"|"picture-fill"|"text"|"shield-label-symbol"|"point-3d"|"line-3d"|"polygon-3d"|"web-style"|"mesh-3d"|"label-3d"|"cim"
• ...

A: I think I would allow them with the suffix "enum". Something like rendererTypesEnum, basemapsEnum, symbolTypesEnum, ...

Check existing issues

• I have checked for existing issues to avoid duplicates

Snippet prefix

"require" and "map"

Proposal

1) map enhance proposal

The map prefix adds:

const map = new Map({
        basemap: "arcgis-imagery"
      });
      const view = new MapView({
        container:"viewDiv",
        map:map,
        zoom:  4,
        center: [15,65]
      });

Following our conventions and having to remove variable declaration, I would replace it using autocasting and changing the prefix to MapView to have something like this (I have replace the basemap selector with to prefixes of the two snippets to the the different basemap enums):

My proposed snippets:

"Create MapView using a Map": {
  "prefix": "MapView",
  "body": [
    "new MapView({",
    "\tcenter: ${1:[15, 65]},",
    "\tcontainer: \"${2:viewDiv}\",",
    "\tmap: {",
    "\t\tbasemap: ${3:basemapsWithAPIKeys|basemapsWithoutAPIKeys}",
    "\t},",
    "\tzoom: ${4:4}"
    "});",
  ],
  "description": "Create MapView using a Map"
},
"Basemaps with API keys": {
  "prefix": "basemapsWithAPIKeys",
  "body": [
    "\"${1|arcgis-imagery,arcgis-imagery-standard,arcgis-imagery-labels,arcgis-light-gray,arcgis-dark-gray,arcgis-navigation,arcgis-navigation-night,arcgis-streets,arcgis-streets-night,arcgis-streets-relief,arcgis-topographic,arcgis-oceans,osm-standard,osm-standard-relief,osm-streets,osm-streets-relief,osm-light-gray,osm-dark-gray,arcgis-terrain,arcgis-community,arcgis-charted-territory,arcgis-colored-pencil,arcgis-nova,arcgis-modern-antique,arcgis-midcentury,arcgis-newspaper,arcgis-hillshade-light,arcgis-hillshade-dark|}\"",
  ],
  "description": "Basemaps enums to be used with API keys"
},
"Basemaps without API keys": {
  "prefix": "basemapsWithoutAPIKeys",
  "body": [
    "${1|satellite,hybrid,oceans,osm,terrain,dark-gray-vector,gray-vector,streets-vector,streets-night-vector,streets-navigation-vector,topo-vector,streets-relief-vector|}",
  ],
  "description": "Basemaps enums to be used without API keys"
}

The same thing would apply to scene

UPDATE: dismiss this one

2) require enhance proposal

require snippets adds:

require(["esri/Map", "esri/views/MapView","dojo/domReady!"],function(Map, MapView){
      
  });

dojo/domReady! which if I'm not wrong is for the JS SDK 3.x, right? In 4.x it returns a:

Failed to load resource: the server responded with a status of 404 ()
4.27:31 Error: scriptError: https://js.arcgis.com/4.27/dojo/domReady.js
    at n (4.27:6:46)
    at HTMLScriptElement.<anonymous> (4.27:30:44)

So, considering 3.x will be retired in July 2024, we should remove the dojo/domReady.

I would also include to add a require and a requireApiKeys

require([
	"esri/config",
	"esri/Map", 
	"esri/views/MapView"
], function(
	esriConfig,
	Map, 
	MapView
){
      esriConfig = "${1:YOUR_API_KEY}";
});

What do you think @kellyhutchins ?

I took the idea from this script that Maarten from Esri Netherlands published on its CoolScripts repo.

Prefix: findLayer
Description:
Snippet:

const fl = view.map.layers.find( l => l.title === "${1:LayerTitle}");

Code:

"Find a layer by it's name": {
    "prefix": "findLayer",
    "body": [
	"const fl = view.map.layers.find( l => l.title === \"${1:LayerTitle}\");",
    ],
    "description": ""
}

Greetings and happy Hacktoberfest 2023!

We're thrilled that you've chosen to participate in Hacktoberfest with us! Please bear in mind that during the month of October 🎃, the volume of pull requests (PRs), comments, and other interactions may be higher than usual. Therefore, we kindly ask for your patience while awaiting responses. To increase the likelihood of a successful PR, please adhere to the following guidelines:

• Familiarize yourself with the repository by reading the README.md.
• Review and follow all the guidelines outlined in CONTRIBUTING.md.
• When you receive feedback on your PR, incorporate the changes into the same PR rather than creating a new one.
• Ensure your PR has a descriptive title, as this will facilitate a smoother review process.

If you haven't already, please check out our blog article 📃, which contains valuable information, including a list of participating Hacktoberfest repositories and details about our contest 🏆 and rules. Additionally, consider joining our Slack channel to join in the fun, receive announcements, interact with maintainers, Esri employees, and fellow participants, and have a place to ask any questions you may have.

Mappy Hacking! 🗺 👩‍💻

Today the extension contain just a one snippets

But there are a lot of (Layer) types.

It would be nice to have snippets for the following classes: (38 in total)

• Vector layers
  • CSVLayer
  • GeoJSONLayer
  • GeoRSSLayer (OGC)
  • GraphicsLayer
  • FeatureLayer
  • FeatureLayer (client-side)
  • MapNotesLayer
  • OGCFeatureLayer OGC API - Features
  • RouteLayer
  • StreamLayer
  • VectorTileLayer
  • WFSLayer OGC Web Feature Service (WFS)
• Raster Layers
  • ImageryTileLayer
  • ImageryLayer
  • ImageryTileLayer /w COG
  • ImageryTileLayer (Multidimensional)
  • WebTileLayer - (XYZ layer / Slippy maps)
  • WMSLayer OGC Web Map Service (WMS)
  • WMTSLayer OGC Web Map Tile Service (WMTS)
  • WCSLayer OGC Web Coverage Service (WCS)
  • MapImageLayer (Time-based) Traffic layer
  • BingMapsLayer
  • OpenStreetMapLayer
• 3D layers
  • SceneLayer
  • Elevation
  • PointCloud
  • BuildingSceneLayer
  • LineOfSightLayer
  • DimensionLayer
  • IntegratedMeshLayer
  • VoxelLayer
• Others
  • MediaLayers (Overlayed images with control points)
  • MediaLayers (/w video)
  • KML Layer (OGC)
  • GroupLayer
  • SubtypeGroupLayer
  • TileLayer
  • KnowledgeGraphLayer

Most of these layers have the possibility to be initialized in different ways (e.g. using source or a similar property), with a url, and/or using a portalItem. Like FeatureLayer (using: source, url, portalItem), RouteLayer (using: stops, url and portalItem, StreamLayer (webSocketUrl or url), etc.

I think the portalItem is the easiest to remember, and having addLayerFromPortalItem I don't see that very relevant. I also think using the URL is probably one of the most commons ways, but also the easiest to remember. I would say having the custom-source/client-side (for been the most complex to remember) or both (including url) if you think that should be default, would be my preference for these snippets.

Does it make sense @kellyhutchins ? // cc: @RalucaNicola

What do you feel about making a printable version like this:

Right now, the table in the readme doesn't look very friendly to me. I would probably organize by categories like: basics, core, geometry, layers, renderers, popup, smartmapping, ... maybe even grouping using some color to differentiate those snippets only for 2D or 3D elements from the common ones.

If you think it might be worthy I don't mind making the first sketch in a collaborative tool like Google Drawing on which we can iterate.

Which should be the conventions about the snippet name?

Just to keep in mind, when you are typing a lot of built-in snippets shows up:

Important note: names have to be unique.

Ideas/questions about how names should be defined:

• Q1) Does it make sense to add something like Esri JS API? to differentiate (from others?).
  A: I don't think so, it would make it very long.

• Q2) Do we allow spaces or use camelcase? (E.g. List map styles vs ListMapStyles).
  A: I think we should allow spaces.

• Q3) Do we recommend not to use more than... 5? words. (to describe what it does)
  A: I would say yes.

• Q4) We just split words? (E.g. createMap to Create Map).
  A: I would split and start with capitals.

• Q5) Do we use the same name but with 2D & 3D suffixes when there are equivalent snippets for 2D and 3D?.
  A: I think we should.

In addition to the existing snippets, which I would recommend revisiting to make them clearer (like with map)

It would be nice adding some additional ones:

• require
• Map:
  • create2DMap (a.k.a map)
  • create3DScene (a.k.a. scene)
  • load2DWebmap (a.k.a webmap)
  • load3DScene (a.k.a. webscene)
• View:
  • hitTest
  • mapViewConstraints: scale, zoom, rotation, extent
  • sceneViewConstraints: for camera tilt and altitude
• Markers:
  • addDefaultMarkerToView
  • addCustomMarkerToView
  • addMarkerWithPopup
• Navigation:
  • enableSmoothScrollNavigation snapToZoom
  • disableViewNavigation
  • disableViewRotation
  • disableViewMouseWheelNavigation
  • disableViewSingleTouchNavigation
• Others
  • watchPropertyChanges (reactiveUtils)
  • watchPropertyChanges (Accessor.watch())

The JS Search Widget has many optional properties and different source options.

Create a snippet for each scenario below:

• Search widget
• Search widget with multiple sources
• Search widget with custom source

Hello again!,

I wanted to share a simple interface I have built for myself to help me create new snippets. While I was doing it, I decided to make it public just in case it could help other developers too (for personal use or to contribute to this repo).

So I just wanted to share it with you:

If you think it can make sense to host the app on this repo, I can finish/clean it a little, remove my repo and do a pull request to this one.

Cheers!

I would add a snippet to help instantiate a MapView Class in *.js files (this issue was opened with the help of the snippet building)

Prefix: MapView
Description: Create an instance of esri/views/MapView
Snippet:

const view = new MapView({
	container: "${1:viewDiv}",
	map: ${2:map},
	zoom: ${3:4},
	center: [${4:15,65}]
});

Code:

"Load a MapView (2D)": {
    "prefix": "MapView",
    "body": [
	"const view = new MapView({",
	"\tcontainer: \"${1:viewDiv}\",",
	"\tmap: ${2:map},",
	"\tzoom: ${3:4},",
	"\tcenter: [${4:15,65}]",
	"});",
    ],
    "description": "Create an instance of esri/views/MapView"
}

Problem

As I mentioned in the Snippet cheatsheet issue. Maintain the table of snippets available manually is:

• It is more time-consuming:
  • Require an additional check on every PR to ensure the entry has been added in the table
  • Require contributors to modify the readme
• Prone to error/inconsistencies:
  • Mismatch between: prefixes and descriptions (table and snippets file)
• Not very usable:
  • The table is not intuitive to explore, even in alphabetical order (other programming cheat sheets group snippets, and use multiple columns). This affect users, but also for maintainers/contributors trying to understand if a code snippet already exists.

This also apply to the one I made with cheatography.com. But I think is worth to have a mechanism that can ensure it is always updated.

Proposal

I think making a web interface should be pretty simple. I have been testing, and I think we can add "custom properties" to the custom snippets:

That, way we could create properties like:

• category: To be able to group snippets (we could consider subcategories if needed; e.g. using a delimitation character)
• url: if we want to add additional hyperlinks on each snippets. For example, we could add to help build an interface which in addition to showing the snippets, also add a link to a reference page:
  • colorVar snippet could point to ColorVariable class - API reference
  • Or a dojoConfig snippet to Configure AMD to load custom modules
  • Or a basemapStyle to Map class - API Reference > Basemap
  • etc.

What do you think? I envision something a simple serverless SPA, like this:

I see there are many acronyms sms, sls, sfs, ... I think it would be also nice to add the extended version for developers not so familiar with our acronyms, something like SimpleMarkerSymbol (sms):

{
"SimpleMarkerSymbol": {
    "body": [
      "{",
      "\ttype: \"simple-marker\",",
      "\tcolor: [255, 255, 255, 0.25],",
      "\tsize: 12,",
      "\tstyle: \"${1|circle,square,cross,x,diamond,triangle,path|}\",",
      "\toutline: {",
      "\t\twidth: 1,",
      "\t\tcolor: [255, 255, 255, 1]",
      "\t}",
      "}"
    ],
    "description": "Create a SimpleMarkerSymbol",
    "prefix": "SimpleMarkerSymbol (sms)"
  },

This way it still matches with sms, but also with sym, marke, ...:

Update: This has been added to the description
I would also add in the name, the path to classes. Instead of just SimpleMarkerSymbol use symbols/SimpleMarkerSymbol:
...

Does any of these ideas make sense to you? 😄