Skip to content
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

Reconsider the behavior of featureLayer.resetStyle() #488

Closed
patrickarlt opened this issue Mar 20, 2015 · 4 comments
Closed

Reconsider the behavior of featureLayer.resetStyle() #488

patrickarlt opened this issue Mar 20, 2015 · 4 comments

Comments

@patrickarlt
Copy link
Contributor

Working with a developer recently I ran into a whole bunch of issues with resetStyle() mostly that its behavior is difficult to predict. Currently it resets the style to whatever the style option on the feature layer is. This means that calling setStyle() will change the behavior of resetStyle().

What the developer was trying to do was this.

  1. On hover make a feature more prominent
  2. When a feature was selected make it extremely prominent
  3. When a feature was selected make all other features less prominent

Using setStyle() for 3 made it impossible to use resetStyle() on the previously hovered/selected features in 1 and 2.

I think resetStyle() should always reset back to the first style ever applied to a layer rather then whatever style option is. This would make the above use case much easier and allow allow better compatibility with Esri Leaflet Renderers for scenarios like the following.

  1. Load a feature layer with a complex renderer.
  2. Create separate styles for when features are selected/hovered
  3. When a feature is selected/hovered change styles of all other features
  4. resetStyle() will now restore the original complex renderer.

@jgravois @kneemer What do you think?

@patrickarlt
Copy link
Contributor Author

This also aligns more with L.GeoJSON https://github.com/Leaflet/Leaflet/blob/master/src/layer/GeoJSON.js#L49-L54

@kneemer
Copy link
Contributor

kneemer commented Mar 23, 2015

Seems reasonable to me.

@jgravois
Copy link
Contributor

agreed!

@patrickarlt
Copy link
Contributor Author

Resolved in #516

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants