Consistent and reliable layer hierarchy
See original GitHub issueThis is rather a conceptual problem we’re experiencing and not a code error or similar. Therefore, the issue template wasn’t applicable so far. Please just let me know if I should do something differently!
We’re trying to achieve a consistent order of layers in our App. Assume that we have the following layers we add.
- zone polygon
- user location
- zone markers
Now it’s clear that we can define this belowLayerID
or aboveLayerID
. The problem we’re having is that user location is only conditionally rendered in our App. What happens now when zone markers specify it as aboveLayerID
but it doesn’t exist? I’d assume it moves to the same level as zone polygon
which is not what we want.
We want to be deterministic no matter whether some layers of the “layer-chain” are rendered or not.
We were also looking into layerIndex
. But here the behaviour was also pretty surprising and dynamic. At least it appeared to us like this. Using very high numbers (10000+) for the lowest element did result in Mapbox errors (some out of bounds exception). It was working somehow when we used numbers below 116, but also then it was sometimes even below mapbox rendered layers.
Is there some idiomatic way how we can do this? Can you recommend an approach for us?
We also did not find proper docs for layerIndex
. Why is there a maximum number that we can give? We assumed it to be similar to z-index, but apparently there is something else behind it.
Thanks already everyone for making it that far reading through our issue! 😄 The example is of course simplified, there are many layers we are rendering in our App and it’s rather complicated.
Issue Analytics
- State:
- Created 2 years ago
- Reactions:5
- Comments:10 (3 by maintainers)
Top GitHub Comments
Something like this can be tried, where we have persistent empty separator layers and we position above/below those.
@mfazekas Could you provide a code snippet of how this would be implemented? I’m having trouble figuring out how to do that.