Our documentation on feature.id in setFeatureState and getFeatureState states that feature.id can be a string or a number. However, if you try a string that cannot be cast as an integer (i.e. "d-32-a"), you'll run into this error (The feature id parameter must be provided and non-negative).
A blog post on the Mapbox blog by @lobenichou and @asheemmamoowala confirms that The ids also have to be integers or strings cast as integers (e.g. “03989” or 3989).
I think it might be helpful to update the documentation to state that if you use a string, it must be valid when cast as an integer. If folks agree/I'm not missing anything, I'm happy to open up a PR that states this.
https://www.mapbox.com/mapbox-gl-js/api/#map#setfeaturestate
https://github.com/mapbox/mapbox-gl-js/blob/aab7551fd9a87fc5c0cb0e6ac6a66ecf475121da/src/ui/map.js#L1393
https://www.mapbox.com/mapbox-gl-js/api/#map#getfeaturestate
https://github.com/mapbox/mapbox-gl-js/blob/aab7551fd9a87fc5c0cb0e6ac6a66ecf475121da/src/ui/map.js#L1414
This seems like an odd limitation of this feature. Would be good to see what is involved in getting any string value to work with this. In many data driven applications where features might be coming from an external GeoJSON feed, the developer won't have control over the ids on the features. The really odd thing is that setFeatureState works fine with any string.
Pretty sure I found a bug: Looking at removeFeatureState function in the SourceFeatureState class, it does use the number feature id, but the if statements would fail if the id is 0. Lines 65, 70. Will need to test this to verify.
I'm not sure of the reason why this is currently designed to use an int, perhaps someone who is more familiar on this code could investigate.
@rbrundritt There is a lengthy discussion at https://github.com/mapbox/mapbox-gl-js/issues/2716
was closed by #8550
Most helpful comment
This seems like an odd limitation of this feature. Would be good to see what is involved in getting any string value to work with this. In many data driven applications where features might be coming from an external GeoJSON feed, the developer won't have control over the ids on the features. The really odd thing is that setFeatureState works fine with any string.