When we introduced the DataLayer.settings property, we did not run a
migration for existing datalayers (because there are millions in the
French server).
Now that we simplified the `DataLayer.isLoaded()` logic in the client,
we want to be sure that created DataLayer on the client have full
metadata.
When we introduced the DataLayer.settings property, we did not run
a migration for existing datalayers (because there are millions in the
French server).
Now that we simplified the `DataLayer.isLoaded()` logic in the client,
we want to be sure that created DataLayer on the client have full
metadata.
Co-authored-by: David Larlet <david@larlet.fr>
At the end, we only need two states: has this datalayer loaded the
data it should load ? yes / no.
Whether it local or remote data should not be a matter.
The scenario to reproduce is:
- peer A creates a datalayer
- peer B add a marker on that datalayer
- peer B saves the datalayer
Before this fix, after the save, peer A would get a new _referenceVersion
for this datalayer, and the render method would make a hide/show,
which would refetch the data from the server, duplicating it.
So forcing the _loaded to be true in this situation prevent this.
We may want to rework the "_loaded" pattern, maybe with the server
returning in a datalayer metadata the length of the data it get for
this given datalayer, so the client knows if it is worth getting
data for a layer when itself (the client) does not have any.
Co-authored-by: David Larlet <david@larlet.fr>
When a peer save the map, other peers in dirty state should not need
to save the map anymore.
That implementation uses the lastKnownHLC as a reference, but it changes
all dirty states at once. Another impementation could be to have each
object sync its dirty state, but in this case we do not have a HLC per
object as reference, and it also creates more messages.
Co-authored-by: David Larlet <david@larlet.fr>
This is more unified between markers and paths, and it allows paths to
be synced as soon as they have been drawn (instead of when closing the
edit panel, which created a race condition when changing its properties
that were then synced to other while the feature itself was not).
This also:
- change the "set center and zoom" to be a panel instead of
a direct action (including the "defaultView" setting
- refactor the "get started dialog"
This is a first step to remove our dependency to the unmaintained
Leaflet.Toolbar plugin.
When moving a path, this will put a once time listener on "moveend". If
we delete this feature, and move the map, we should not execute the
event callback.
A better fix would be to cancel the event listener on delete, but that
is much more work given how we deal with Leaflet events right now.
When moving a path, this will put a once time listener on "moveend".
If we delete this feature, and move the map, we should not execute the
event callback.
A better fix would be to cancel the event listener on delete, but that
is much more work given how we deal with Leaflet events right now.
This is more unified between markers and paths, and it allows paths to
be synced as soon as they have been drawn (instead of when closing the
edit panel, which created a race condition when changing its properties
that were then synced to other while the feature itself was not).
