-
Notifications
You must be signed in to change notification settings - Fork 8
RD-888 Refactored Geocoding Control (WIP) #101
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
base: next
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
All in, I like the look of Lit. But I'm guessing it's all still in progress?
I'm not a big fan of the label / goto code and I think there's definitely some places where the logic could do with some refactoring / simplifying if at all possible (I'm thinking those nested if / else if / else statements)
I'd love for us to get rid of as many of the headaches as possible from the previous implementation.
Also some form of testing (even if it's just the base use cases) would be good and the readme etc.
|
|
||
| this.#setAndSaveData(undefined); | ||
|
|
||
| block: if (picked) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know this is probably lifted from the original geocoding control, but with the labels / gotos like this I feel it's difficult to read the code and they're generally considered bad juju. Maybe some of the logic could be inverted?
if (geoms.length > 0) {
const unioned = union(...);
if (unioned) { // instead of !unioned
setMask(...);
handled = true;
}
}Would it be difficult to refactor ahead of release?
| break ok; | ||
| } | ||
|
|
||
| setMask( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Also, this setMask function (which I know comes from the original geocoding control) being deliberately "not pure" is problematic for me. I think having that as a pure function that returns the mask (or null) would maybe be cleaner and more intuitive rather than passing a callback.
| } | ||
|
|
||
| if (handled) { | ||
| // nothing |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Same here, feels like the logic could be inverted and then the method could return early?
| type: "geojson", | ||
| data: this.#savedData, | ||
| }); | ||
| } else { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
would if (!source && !this.#savedData) return; work better?
| } | ||
| >; | ||
|
|
||
| // NOTE We can't use Maplibre `Event` - see https://github.com/maplibre/maplibre-gl-js/issues/5015 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think these events and types can all be moved out into a separate file, no?
| @@ -0,0 +1,888 @@ | |||
| import { | |||
| Evented, | |||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
is this just a backup file? Can probably get removed, no?
RD-888
Objective
Refactor the whole component into standalone component without svelte dependency
Description
Svelte has been removed, geocoder has been rewritten into Lit.js, it is now usable standalone, separate classes for MapLibre GL and MapTiler SDK were created, WIP
Acceptance
Manual testing in demos, WIP