-
Notifications
You must be signed in to change notification settings - Fork 1
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
add onFeatures event #21
Conversation
320f743
to
c23f950
Compare
With the added
I think we should add a third call as part of
I think
I think an array of features makes sense. The |
I had a think about this, I'm considering that not having this 'results' event on What I'm going to do is show a map view with all the Features from the 'features' event, then once a 'select' event fires I'll just use that single Feature in the map view instead. If we had a 'results' event fire with an empty array and also a 'select' event fire, it would be more difficult for me to handle this, plus the order of the events would tightly couple the two UIs, for better or worse. The callee already has the option of clearing their copy of the Features on a 'select' event, so it sounds like it's more powerful to not have this additional call, although the README text "Dispatched when the GeoJSON features backing the UI change" isn't quite correct 🤔 |
c23f950
to
40a2224
Compare
agh I don't know, I can make it work on the listener side either way, I'll add this via rebase: diff --git a/src/autocomplete/autocomplete.js b/src/autocomplete/autocomplete.js
index 9a9f8cf..a834151 100644
--- a/src/autocomplete/autocomplete.js
+++ b/src/autocomplete/autocomplete.js
@@ -102,6 +102,8 @@ export default ({
// called user-supplied callback when an item is selected
const onSelectItem = ({ selectedItem }) => {
+ setResults(emptyResults)
+
if (typeof userOnSelectItem === 'function') {
userOnSelectItem(selectedItem)
} |
40a2224
to
b715816
Compare
b715816
to
6805b0a
Compare
6805b0a
to
74e4952
Compare
This PR adds a new event called
'features'
which emits the currentgeojson
array backing the UI. (it strips theFeatureCollection
envelope, but that's not a big deal)I would like to be able to expose the underlying data such that I can update a map with all the results currently shown in the UI, without something like this there is no way to expose the raw response data.
couple potential issues/improvements:
[]
appropriately (ie. when the UI is empty)discard
requestsfeatures
), I also consideredresults
event.detail
is an Array of features, would we possibly want more info later which would necessitate an object?