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

feat: add support for drawing many features on the same map #466

Merged
merged 5 commits into from
Aug 5, 2024

Conversation

jessicamcinchak
Copy link
Member

@jessicamcinchak jessicamcinchak commented Jul 31, 2024

Changes:

  • Adds a new drawMany prop which has default value false
  • Works for drawType "Polygon" or "Point"
    • Displays labels when drawMany is true (label text is auto-index)
  • Updates geojsonChange event to set properties
    • label will match visual text on map for any drawType
    • area replaces previously separate areaChange event when drawType="Polygon" - see comment
  • Also ran "organise imports" and linting on the main index.ts - sorry for extra noise!

Future scope / follow-up PRs:

  • "Reset" button clears all features as current behavior and resets to empty map, whereas we probably want to consider ability to remove one-by-one (or "last feature" undo?)
    • If removing out of order, should we shift label index or keep static?

Copy link

netlify bot commented Jul 31, 2024

Deploy Preview for oslmap ready!

Name Link
🔨 Latest commit 4a3c939
🔍 Latest deploy log https://app.netlify.com/sites/oslmap/deploys/66b0a1f1b9ca7a0008382467
😎 Deploy Preview https://deploy-preview-466--oslmap.netlify.app
📱 Preview on mobile
Toggle QR Code...

QR Code

Use your smartphone camera to open QR code link.

To edit notification comments on pull requests, go to your Netlify site configuration.

sketch.set("area", formatArea(sketchGeom, this.areaUnit));
}
});
}
Copy link
Member Author

@jessicamcinchak jessicamcinchak Aug 5, 2024

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is breaking change ⚠️ rather than dispatching a separate areaChange event when drawing polygons, this proposes simply setting area within the geojson properties and dispatching the single geojsonChange event.

A couple benefits:

  • Scales much more nicely between draw-one and draw-many, naturally accounts for extra label property too
  • End consumers only have to subscribe to a single thing and just parse different data from it
  • I can't think of any current use cases where you'd only subscribe to an areaChange and not care about the whole geojsonChange ??

Any objections or alternative ideas?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is super interesting. I think that this approach will work well and suit our requirements - I can't really think of an issue here.

Right now we just need the general concept of a change event, and don't really need granular details (e.g. to inform a consumer that the area property of feature 14 have updated). It's enough to say there's been an update to the FeatureCollection as a whole, and it will need to be updated. It's possible that in the future this could be required (seems unlikely and parsable by consumers anyway?), but for now a single "change" event is a lot simpler and meets all requirements 👍

@jessicamcinchak jessicamcinchak marked this pull request as ready for review August 5, 2024 10:05
@jessicamcinchak jessicamcinchak requested a review from a team August 5, 2024 10:05
Copy link
Contributor

@DafyddLlyr DafyddLlyr left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Nice change with a very small diff - love to see it 🙌

sketch.set("area", formatArea(sketchGeom, this.areaUnit));
}
});
}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah this is super interesting. I think that this approach will work well and suit our requirements - I can't really think of an issue here.

Right now we just need the general concept of a change event, and don't really need granular details (e.g. to inform a consumer that the area property of feature 14 have updated). It's enough to say there's been an update to the FeatureCollection as a whole, and it will need to be updated. It's possible that in the future this could be required (seems unlikely and parsable by consumers anyway?), but for now a single "change" event is a lot simpler and meets all requirements 👍

src/components/my-map/drawing.ts Show resolved Hide resolved
@jessicamcinchak jessicamcinchak merged commit 697cb17 into main Aug 5, 2024
5 checks passed
@jessicamcinchak jessicamcinchak deleted the jess/draw-many branch August 5, 2024 14:19
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

Successfully merging this pull request may close these issues.

2 participants