`ReactLayersMixin`.

[jordwalke]

I really like our ReactLayersMixin plugin and we should open source it. It allows us to implement not just the render function, but also the renderLayers function. The render is the same as its always been (describe your structure at any point in time. The renderLayers API allows you to describe your modal layers at any point in time. So that means you can open and close layers as a function of props/state just like your render() function can "react" to props/state.

Assigning to @yungsters who mastered the React/Layers stuff on FB's stack, but @petehunt also has great experience using and building out layers integration with React. So whoever has time/need.

[petehunt]

FB layers has so many internal deps that we don't even use them at IG. Instead I suggest we open source the react layers stuff plus the light IG shim. You don't get the nice behaviors but the value for the community lies mostly in the architecture IMO.

@yungsters if we redid layers today would we do it any differently (ie I think we could do it with composition)? This could be a nice greenfield opportunity.

[yungsters]

To be honest, I don't know if I would have done anything that differently. The Layer abstraction has held up really well — we have been able to extend it and make improvements over time without much code decay.

[petehunt]

@yungsters yeah Layer is awesome -- what I'm wondering is why we use a mixin rather than composition to hook it up to React.

[yungsters]

I guess I'm not sure what you mean by using composition to hook Layers up to React. Are you asking why we use renderLayers instead of returning the <Layer> components in render?

[petehunt]

Yeah

[yungsters]

Layers are not inherently anchored to any position in the DOM. For example:

render: function() {
  return <div><button>Show Dialog</button><Dialog /></div>;
}

It does not make sense for <Dialog /> to exist in the returned tree. What we actually want is for render to return the subtree as well as a list of Layer components.

[petehunt]

That makes sense, but the return value for renderLayers() is a little confusing (I've never used multiple layers in a component before), and it's not clear at first glance that it follows React's normal data flow.

[yungsters]

When I designed renderLayers, I debated whether or not to allow returning a single Layer component. However, I did not want engineers to have to learn something new just because their use case requires more than one Layer component.

Also, I felt like it was not too painful to have to return a map with one key. Keep in mind that at the time, this was the standard way of passing in children with keys into a React component.

[petehunt]

So I think that if we had frags I wouldn't mind putting the components in the render() method. While it would be kind of weird that it is not anchored to the DOM, if we had frags we would have precedent for components that don't render to anything in that place in the DOM and it would just be 1 paradigm to learn.

[yungsters]

I would not be strongly opposed to that, but I don't think it makes the code easier to read. It makes the following questions harder to answer:

• Does this component render any Layers?
• Is any given component returned by rendera Layer component?
• Does this component render into any non-Layer?

[jordwalke]

I think it's odd to return things in the render() output that don't exist in the physical render tree. A component that has layers has the ability to have multiple distinct render tree roots. The ReactLayermixin in FB reflects that - but if the return value is too confusing, we can constrain it a bit - that should be very easy to do - we would just require that a single component be returned and modify existing code use. If we did allow them to be returned within frags, it would make sense that they are required to be at the top of the render tree - nothing deeper, and I'd probably be interested in making use of a more general abstraction that solves not only Layers but also other cases when you want a DOM subtree to actually exist on another part of the page, yet be controlled by your component. Think of it as a "Portal" to another part of the page:

But even just something as simple as our current ReactLayerMixin would be quite awesome. If released as a separate project, I wouldn't even mind bringing in a ton of extra JS resources. Pete, we could also just open source the Insta one quickly too, but I'd rather make it conform to ReactLayerMixin until we get frags, thoughts?

[petehunt]

To be clear we do use ReactLayer and ReactLayeredComponentMixin at IG, just not any of the FB layer behaviors or Layer impl itself (yet), but they are API compatible for FB layers and behaviors by design. I am in favor of bringing all that to open-source, just want to make sure that we think about making any API cleanup before doing it.

[yungsters]

Just spoke with @petehunt. Instead, we will publish a blog post with a rudimentary layer implementation and ReactLayersMixin that demonstrates how such a system would be built.