Snippet "body" conventions about arcgis-js-vscode-snippets HOT 7 OPEN

Q6: I prefer the snippet name too we'll just need to ensure that we add info to the readme to let users know how these snippets within snippets work.
Q7: For simplicity sake I think we should leave out the placeholder that shows the options. I worry that it will be too hard to maintain and as you noted if users are working with the jsapi types they already get that info.

Q8: Interesting approach. I like it and think it would be a nice option that makes it generic.

Q9: I think it would be useful to have snippets for the enums and like the idea of adding the enum suffix.

from arcgis-js-vscode-snippets.

Let me share the notes from the meeting @kellyhutchins, @RalucaNicola and @ak-kemp just add.

From what I understood, we have agreed on the following:

Q0) Do we use \t instead of spaces?
We agreed on using \t

Q1) The snippet should contain a new class initialization, its constructor properties, or both?
We agreed on both are OK for JavaScript.
For TypeScript only the "new ... " version.
We agreed on adding the suffix "Props" to the version just with the properties (without "new").

Q2) When creating new class, do we also assign it to a variable?
We agreed on not assigning it to a variable

Q3) Should we avoid adding multiple expressions in one snippet?.
We agreed on trying to keep snippets small and try not to instantiate more than one class whenever possible.

Q4) Do we allow comments?
We agreed on not using comments. Use the description instead.

Q5) When instantiating a new class, do we add only required fields, the most common ones, all?
We think there is no unique answer for this. Try to use the most common ones but it will need to be checked case by case. We agreed on sorting properties by alphabetical order.

Please correct me if I understood something wrong.

Cheers

from arcgis-js-vscode-snippets.

I agree with Kelly on the last 4 questions, nothing to add.

from arcgis-js-vscode-snippets.

@hhkaos I think we can follow the same guidelines used here in the JSAPI resources: https://github.com/Esri/jsapi-resources/blob/main/.prettierrc.json

from arcgis-js-vscode-snippets.

Yuhu!, so we got to an agreement then. I will add the agreements to https://github.com/Esri/arcgis-js-vscode-snippets/blob/master/contributing.md :)

from arcgis-js-vscode-snippets.

@kellyhutchins I think we should also add to the guidelines that after a colon, there needs to be a single space " ".

I'm not sure about singles quotes vs double quotes vs backticks 😅, do we follow any rule/convention?.

from arcgis-js-vscode-snippets.

I think we can follow the same guidelines used here in the JSAPI resources: Esri/jsapi-resources@main/.prettierrc.json

Perfect!, we will have to include that in the contributing guidelines.

Another question related to the body conventions.

Properties for autocasting vs constructors

I have noticed most of the snippets today contain properties for autocasting:

{
	type: "polygon-3d",
	symbolLayers: [{
		type: "fill",
		pattern: {
			type: "style",
			style: "${1|solid,vertical,horizontal,forward-diagonal,diagonal-cross,cross,backward-diagonal|}"
		},
		material: { color: ${2:[255, 250, 239, 0.8]} },
		outline: { color: ${3:[70, 70, 70, 0.7]}}
	}]
}

But it could also be:

new PolygonSymbol3D({
	symbolLayers: [{
		type: "fill",
		pattern: {
			type: "style",
			style: "${1|solid,vertical,horizontal,forward-diagonal,diagonal-cross,cross,backward-diagonal|}"
		},
		material: { color: ${2:[255, 250, 239, 0.8]} },
		outline: { color: ${3:[70, 70, 70, 0.7]}}
	}]
})

Almost the same except for the type: "polygon-3d", many times needed for autocasting.

Should we remain consistent and recommend one approach versus the other? Or any rule to when to go for one vs the other? I just feel it can get messy and end-up having random patterns.

Raul

P.S. if we are OK with both, I wonder if we should apply different conventions for each (e.g. common properties vs all properties).

from arcgis-js-vscode-snippets.