-
-
Notifications
You must be signed in to change notification settings - Fork 23
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
Stop maintaining fork of ol3-google-maps #99
Comments
|
I implemented the described workaround. Renaming this issue to "Stop maintaining fork of ol3-google-maps"... to be continued... |
**Why?** The strategy of loading the Google maps API via a script tag prior to initializing farmOS-map was one of the primary drivers of slow loading - even when Google maps wasn't used. See performance testing at farmOS#112 Although the strategy of splitting each behavior into its own chunk mostly mitigates any cost of including Google maps support in farmOS-map, it will be better for the maintainability of farmOS-map not to directly include Google maps support (RE: farmOS#99) and a contrib module for farmOS is a cleaner place for the integration to live anyway since such a contrib module could be fully optional and could include optimizations about how/when to load the Google maps API JS.
**Why?** The strategy of loading the Google maps API via a script tag prior to initializing farmOS-map was one of the primary drivers of slow loading - even when Google maps wasn't used. See performance testing at farmOS#112 Although the strategy of splitting each behavior into its own chunk mostly mitigates any cost of including Google maps support in farmOS-map, it will be better for the maintainability of farmOS-map not to directly include Google maps support (RE: farmOS#99) and a contrib module for farmOS is a cleaner place for the integration to live anyway since such a contrib module could be fully optional and could include optimizations about how/when to load the Google maps API JS.
**Why?** The strategy of loading the Google maps API via a script tag prior to initializing farmOS-map was one of the primary drivers of slow loading - even when Google maps wasn't used. See performance testing at farmOS#112 Although the strategy of splitting each behavior into its own chunk mostly mitigates any cost of including Google maps support in farmOS-map, it will be better for the maintainability of farmOS-map not to directly include Google maps support (RE: farmOS#99) and a contrib module for farmOS is a cleaner place for the integration to live anyway since such a contrib module could be fully optional and could include optimizations about how/when to load the Google maps API JS.
@symbioquine: Curious how we should proceed with this issue now that the dependency on farmOS-map is no longer depending on it, but technically the |
I think it's still mainly a matter of getting your issue mapgears/ol3-google-maps#285 resolved. I can try following up on that. Maybe I can find a strategy that they'll accept a PR for... |
Looks like we'll be able to stop using/supporting the farm_map_google module once we update to OpenLayers 9 - and maybe add some core behavior to support it... https://openlayers.org/en/latest/examples/google.html |
This is a bit of a thorny issue... opening this to document it for future reference... I may end up working around it in the short-term, at least until a proper upstream fix is available.
Back story:
farmOS-map includes the ol3-google-maps library for Google Map layer support (added via #8). However, when Google Layers are put in a layer group, they do not work. This is documented in this upstream issue: mapgears/ol3-google-maps#285
I dug into it and figured out the cause, described here: mapgears/ol3-google-maps#285 (comment)
I managed to fix the issue for farmOS's immediate needs, but it is not a "complete" solution, so it was not ready for a pull request to be opened and merged upstream. I didn't had time to work on it further, so I simply created a fork with a
farmOS-map
branch containing the fixes we needed and updated farmOS-map'spackage.json
to point to that fork+branch.See this commit:9cb8311
And this comment: #8 (comment)
Fast forward to today:
Now, we are trying to pull farmOS-map into farmOS 2.x via Composer (https://www.drupal.org/project/farm/issues/3186641). We decided that we need to host farmOS-map on NPM and pull it in via asset-packagist.org (the reasoning for this is described in that issue).
See related issue: #64
However, after publishing v1.3.0 to NPM, attempting to pull it in via Composer results in the following error:
It seems that asset packagist does not support github fork+branch dependencies.
I found this issue, which sounds like it is the same, but no solutions: hiqdev/asset-packagist#133
Proper long-term solution
The correct solution to this is to fix mapgears/ol3-google-maps#285 upstream, so that we can simply pull in
olgm
via NPM normally.Potential short-term solution
A potential short-term solution would be to publish my fork+branch on NPM so that we can reference it directly. I hate maintaining a fork like that, but we don't have the resources to dig into the proper solution right now. Ideally, we can just delete the NPM package in the future when mapgears/ol3-google-maps#285 is fixed, and collapse/simplify this whole thing (and close this issue). But for now, I think that's the approach I'm going to take...
The text was updated successfully, but these errors were encountered: