-
Notifications
You must be signed in to change notification settings - Fork 15
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Snippet "prefix" convetions #10
Comments
I understand the bit about changing the prefix to be the full name - that makes sense. But I don't understand the part about adding the path (symbols/SimpleMarkerSymbol)? |
Update: This has been added to the description
require(["esri/views/MapView", function(MapView) {
// Instantiate MapView
const view = new MapView({
container: "viewDiv",
map: {
basemap: "topo"
}
});
});
require(["esri/views/MapView", "esri/WebMap"], function(MapView, WebMap) {
// Instantiate WebMap
var webmap = new WebMap({
portalItem: {
id: "webmap_id"
}
});
// Instantiate MapView
const view = new MapView({
container: "viewDiv",
map: webmap
});
});
|
@hhkaos ok now I see what you mean. Yes I think it might be good to include the path. I'll look into adding it for the existing snippets and play around with it for a day and see how it feels to use the snippets. |
I looked at adding the path but I'm not sure yet where the best spot to add it would be. I did some testing but want to do some more research to see if I can find some best practices info. I did update the prefix to use the longer names. |
Hi Kelly, thanks for the update!. I have been thinking about this, and maybe it is enough just to add the path to the module in the description. What do you think about that? While doing the cheatsheet & snippets builder I realized that having a "Checklist" with all the conventions would be awesome. I have seen quite a bit of heterogeneity in the way snippets are written/named/described, so I think it would be very helpful in order to make this repo grow properly. Does it make sense? If you think it does, I would open an issue for each field (body conventions, name conventions ...) to brainstorm and discuss the best way to define each one, and have a place refer in the contributing white but also to revisit for enhancements if needed in the future.
|
So I guess with the convention that in JavaScript we use autocasting as much as possible, then the problem of importing is not so dramatic. And in TypeScript you can easily use autoimports... But I see what you mean, I always have to go to the doc to figure out where that LabelClass is placed :D And I think you said you'd like to add class imports for JavaScript as well, so then people will really have to make a lot of imports. |
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 likeSimpleMarkerSymbol (sms)
:This way it still matches with
sms
, but also withsym
,marke
, ...:Update: This has been added to the description
I would also add in the name, the path to classes. Instead of justSimpleMarkerSymbol
usesymbols/SimpleMarkerSymbol
:...
Does any of these ideas make sense to you? 😄
The text was updated successfully, but these errors were encountered: