Expose MapviewAPI for programatic consumption of Search Providers

[cdloh]

As mentioned in #138 I've created a API class that can be used to expose various parts of the API to be then consumed by other plugins like QuickAdd

I did some refactoring of the geosearch files to make it slightly easier to consume. If you'd like me to undo / change some of that please let me know.

Haven't tested completely yet but wanted to get something out there as I worked on it.

[esm7]

Thank you for this PR, the refactoring is great and the upcoming API will be super useful!

[esm7]

Sorry about the misunderstanding; that's not what I meant in our discussion.
If you expose the searchProvider and searcher fields as an API this way, then you actually expose geosearch.OpenStreetMapProvider, geosearch.GoogleProvider, GooglePlacesAPI and GeoSearcher, and all of then now become an API that must be maintained. Every single thing we ever change in GeoSearcher is a potential API breakage and that's a lot of maintenance burden to consider.
What I think we should do instead is that this MapViewAPI class exposes a single method geosearch with the least dependencies possible, or maybe 2-3 methods if you want to provide some more functionality, and mask away all of the implementation.

[cdloh]

The main reason I want to expose those API calls directly is that abstracting them away again makes it hard to manipulate the raw data (which in my case I want to do, understand if this isn't the direction you want to take it).

How would you suggest exposing the raw response from the search API and things like the Google Places API details endpoints?

Other then exposing the searchProvider directly I don't see a nice way.

If those APIs change would the release not just be a breaking change.

[Nitero]

I could really use this feature, is it still planned?

To me it would be sufficient if there was just a search method I could use from templater to get the location of a search string

[esm7]

I could really use this feature, is it still planned?

To me it would be sufficient if there was just a search method I could use from templater to get the location of a search string

I sure wouldn't object if someone added this functionality, but this specific PR didn't converge eventually, and in my own list of priorities this is currently not very high :-/

[cdloh]

@esm7 I'm happy to give this another go but I never heard back from you on the above review bits.

[esm7]

Actually, re-reading the old code, I'm much less opinionated against the solution you provided. Would you mind giving it a refresh so it works with the latest version?