-
Notifications
You must be signed in to change notification settings - Fork 15
Load GeoJSON data on addLayer in a store plugin #553
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
Conversation
store.commit('updateLayer', { layer: updatedExternalLayer }) | ||
store.dispatch('updateLayer', updatedExternalLayer) |
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.
Just for my comprehension why changing from commit to dispatch here ?
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.
So that it may go through the layer validation present, post-commit, in the action.
But that isn't mandatory, just that I prefer not touching mutation much, and using action whenever I can (only store modules themselves should use mutations)
It will greatly ease the future migration to pinia not to use mutation in the code outside of store modules.
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.
Ok good to know I'll try to stick to actions then
return new Promise((resolve, reject) => { | ||
axios | ||
.get(geoJsonLayer.styleUrl) | ||
.then((response) => response.data) |
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.
What about if the service return something else as 200 ? I'm not sure that axios is raising an exception in this case. Is this function only calling our backend ? Because if not I would consider adding a timeout.
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.
Only our backend is requested, with URLs coming from our backend listing of layers. I don't think it make much sense to double proof the content of what is served
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.
Ok
32c0ad1
to
ef4d180
Compare
ef4d180
to
a4b3d68
Compare
so that this logic can be shared between Cesium and OL (was implemented twice in each "flavor") the styleFromLiterals.js file was modifying values received as function args, I changed that because it was triggering store error (as sometimes, these arguments were coming straight from the store, and are thus immutable outside of a store action) I also changed the store action "updateLayer" so that the payload can be directly a layer (no need to wrap it in an object anymore)
a4b3d68
to
f115896
Compare
so that this logic can be shared between Cesium and OL (was implemented twice in each "flavor")
the styleFromLiterals.js file was modifying values received as function args, I changed that because it was triggering store error (as sometimes, these arguments were coming straight from the store, and are thus immutable outside of a store action)
I also changed the store action "updateLayer" so that the payload can be directly a layer (no need to wrap it in an object anymore)
Test link