This PR contains minor changes to adjust sequence of cadastrapp layers initializing.
It aims to change behavior described in #169 when layer with selected plots is drawn below the layer with raster (tiled) data.
Described issue can occur only in environment where raster data contains opaque data in tiles (e.g. solid figures).
The problem is caused by the fact that cadastrapp is making an attempt to sync vector layer data on the map with the state whenever set of actions occur. One of those actions is SET_STYLES and it is triggered upon one of the components mount, prior to the step when raster layer is added to the map.
RC-15 release mentioned in issue doesn't have this problem because of the way extension is initialized there. That release has a problem when extension ran setup process twice whenever cadastrapp panel is open.
The sequence there is: panel is open -> SET_STYLES / setup sequence requested -> vector layer created and populated with the data from state (if any) -> raster layer created -> both layers removed on extension tear down -> second setup sequence -> raster layer created -> vector layer created -> app signals setup is completed -> vector layer is populated with the selection data from state (if any).
RC-20 changed this behavior and removed redundant initializing cycle but this led to regression described above.
With the applied changes, layer sync will happen after setup sequence is completed and both raster and vector layers are added to the map; setting default styles upon extension initializing will not trigger layer data sync. App will start to listen to a set of events leading to the sync of layer data only after extension setup is completed. Sequence will change to:
panel is open -> SET_STYLES / setup sequence requested -> vector layer created -> raster layer created -> app signals setup is completed -> app signals that both layers are added to the map -> vector layer is populated with the selection data from state (if any)
Please check if the PR fulfills these requirements
Description
This PR contains minor changes to adjust sequence of cadastrapp layers initializing. It aims to change behavior described in #169 when layer with selected plots is drawn below the layer with raster (tiled) data.
Described issue can occur only in environment where raster data contains opaque data in tiles (e.g. solid figures). The problem is caused by the fact that cadastrapp is making an attempt to sync vector layer data on the map with the state whenever set of actions occur. One of those actions is
SET_STYLESand it is triggered upon one of the components mount, prior to the step when raster layer is added to the map.RC-15 release mentioned in issue doesn't have this problem because of the way extension is initialized there. That release has a problem when extension ran setup process twice whenever cadastrapp panel is open. The sequence there is: panel is open -> SET_STYLES / setup sequence requested -> vector layer created and populated with the data from state (if any) -> raster layer created -> both layers removed on extension tear down -> second setup sequence -> raster layer created -> vector layer created -> app signals setup is completed -> vector layer is populated with the selection data from state (if any).
RC-20 changed this behavior and removed redundant initializing cycle but this led to regression described above.
With the applied changes, layer sync will happen after setup sequence is completed and both raster and vector layers are added to the map; setting default styles upon extension initializing will not trigger layer data sync. App will start to listen to a set of events leading to the sync of layer data only after extension setup is completed. Sequence will change to: panel is open -> SET_STYLES / setup sequence requested -> vector layer created -> raster layer created -> app signals setup is completed -> app signals that both layers are added to the map -> vector layer is populated with the selection data from state (if any)
Please check if the PR fulfills these requirements
What kind of change does this PR introduce? (check one with "x", remove the others)
Issue
What is the current behavior?
169
What is the new behavior? As per description above
Breaking change
Does this PR introduce a breaking change? (check one with "x", remove the other)
Other useful information