[CuriouslyC]

I have very mixed feelings about the new context api. On one hand, you're taking a foot-gun away, which I approve of having worked on code bases that abused it. On the other hand, it's very clunky, and I think people who abused the old context will just start making components larger, and wrapping them in a single context, rather than doing the right thing with many small components individually wrapped. Personally I think props inheritance, with IsolatedComponent as an escape hatch/boundary would have been much cleaner.

[mrdoops]

I think it's more intended to be utilized as an abstraction in something like Apollo. It'll be interesting to see what sort of cleaner patterns emerge out of using Contexts under the hood.

[brianvaughn]

Would you elaborate on what you find clunky about the new context API? :)

[CuriouslyC]

Well, I tend to make a lot of very small stateless components. If a component is 1-6 JSX tags, the new context API represents a boilerplate overhead of between 100 and ~17%. Additionally, the semantics of having a consumer's props.children be an immediately invoked function are a little bit unintuitive to me. I think having multiple ways to pass "props" increases the api surface area, having everything "just be props" would be simpler.

[brianvaughn]

> Well, I tend to make a lot of very small stateless components. If a component is 1-6 JSX tags, the new context API represents a boilerplate overhead of between 100 and ~17%.

Not if you use a HOC (e.g. `withContext(Component)`) like a couple of the docs examples showed.

> Additionally, the semantics of having a consumer's props.children be an immediately invoked function are a little bit unintuitive to me.

That's fair! I would encourage you to give it a chance though. I think it's a pattern that really grows on you after a short time. :)

[danabramov]

What is props inheritance and IsolatedComponent?

[CuriouslyC]

If you're familiar with the scope inheritance behavior of angular 1.x, that would basically be a reasonable model (i.e. setProtoTypeOf on props objects down the chain). That would avoid people taking the shortcut of doing {...spreadProps} when they have to pass a lot of properties to many small child components, and let you distinguish locally passed props vs inherited props during debugging.

IsolatedComponents wouldn't inherit props from their parents. The idea of an IsolatedComponent would be to present a boundary on inherited props. That would give you the simplicity of the old context api, but with more fine-grained control over how it is propagated (hopefully leading to fewer foot gun moments).