Layer ordering

[cyrilchapon]

Following up on #35

before is actually working, but this would be a great improvement (in the declarative-to-imperative approach) if before could actually be computed automatically on Map layer children, wouldn't it?

Think of this :

const CustomMap = (props) => (
  <Map>
    <Layer id='1' />
    { props.myConditon && <Layer id='2' /> }
    <Layer id='3' />
  </Map>
)

If you now display

<CustomMap />

Then dynamically changes it to

<CustomMap my-condition />

Layer 3 is rendered before Layer 2 This is a bit counter-intuitive because children order is respected when not dynamically adding/removing them, but broke only when doing so.

In that situation, I have to put a before on Layer 2 and it's ok.

But in my personal case, I have like 30 layers to put before on, with different conditions. This leads to ultra-complex, dynamically-conditioned befores and kill all the readability of the declarative approach this module brings.

[snickell]

My app is similarly getting /extremely/ complicated as a result of needing to use before= clauses to specify ordering. The desired behavior is pretty simple:

• by default, react-mapbox-gl should addLayer() and moveLayer so that the order of layer in props.children is the same as the order of layers in mapbox-gl.

[snickell]

Is there interest in a PR for this? If there's agreement that the behavior specified by @cyrilchapon and myself is correct, I would be happy to write the patch.

btw, this is how leaflet etc work: the order you declare your layers in the declarative level is the order they are rendered in! with the current behavior, if you don't carefully and painfully specify before= for every single possible layer combo, if a layer is added or removed in respond to a react event it goes straight to the top! In my case, they are raster layers that cover the whole screen, so this is especially bad!

[thomasm-kh]

Hi. A numeric “z-index” property, like the one in CSS, would be nice.