Issue 1:
This came up in a twitter thread with @gaearon and @aweary and we decided to move the discussion here. I’ll try to summarize the conversation so far below.

The basic question was whether a build tool could extract the static parts of a component tree ahead of time into HTML, and ship smaller JS to the client with only the dynamic parts. This could have benefits for code size and hydration performance for statically generated sites. It would likely have a smaller impact on dynamically generated server rendered sites, but it’s possible there are static parts that could be extracted there too (e.g. header, footer, article content, etc.).

There are a couple potential ways to go about this, each with various tradeoffs.

Do something like what ember and other template compilers do and generate some kind of IR from components and inject dynamic content into slots at runtime. This would likely require a lot of changes to React itself. @aweary seems to be working on some kind of compiler to do just that.

Rewrite the JS with something like prepack, similar to what @trueadm did here (though it sounded like the output was quite variable in size).

Rewrite the component tree to generate a different but equivalent tree with the static parts hoisted out. Similar to this babel plugin but taken much farther to work at a whole tree level instead of a component level. Also to remove the static parts from JS altogether and generate static HTML to avoid duplicate content in JS and unnecessary hydration cost. Some way to allow static HTML in the middle of a tree to be reused might be needed, but maybe compiling to multiple roots would work?

Obviously a lot more thought is needed here. As @gaearon noted, a solid definition of “static” will be important for this discussion. Mine is that it could be rendered to HTML and never updated by JS, but perhaps people have other ideas.

Issue 2:
The problem is best expressed in terms of an example:

I've a function that acts as an plugs into my implementation of an isomorphic style loader. The function is simply set on the very high-level AppContext (that contains the application services, and components and the whole shebang) which is passed through root component as a context. So, a component inside essentially just needs to get that style applier function from the context and run them. And naturally, abstracting it into a higher order component would make the most sense to initiate the styles and dispose of them, paired with the lifecycle.

Note: A similar live implementation running my site, https://www.prasannavl.com is here: https://github.com/prasannavl/prasannavl.com/blob/0060cc4acbd8796f2495a68c3669b1b224476b15/src/modules/core/createStyled.ts (However, since its just my site, I'm duplicating the class to workaround the below mentioned problem)

However, I DO NOT want to couple this component into my app's context. So, essentially, I want something like this:

export function createStyledWith<T>(styleApplier: CssStyle.StyleApplierFunction, InnerComponent: T, ...styles: any[]) {
class StyledComponent extends React.Component<any, any> {
static displayName = getDisplayName(InnerComponent);
private removeCss: () => void;

componentWillMount() {
this.removeCss = styleApplier.apply(this, styles);
}

componentWillUnmount() {
const removeCss = this.removeCss;
setTimeout(removeCss, 0);
}

render() {
return React.createElement(InnerComponent as any, this.props);
}
}
// Trick the type system into thinking its the same component
return StyledComponent as any as T;
}

The problem: How do I create a styleApplier that pull the service from the context?

I simply cannot pass the decoupled style applier function into this component, unless I have it stored else where.

Why?

I have no access to the context outside of the component. Well, that can be solved by providing a closure that accesses the context, and pull the services. (Or so I thought). But since this doesn't have contextTypes, React will refuse to acknowledge the existence of context. So, there's really no way to make this work without another un-necessary abstraction - another higher order component - that pulls the styleapplier out of the context, and then provides it to this component that can then be called.

Higher order components may be gold. But if you fill an entire ship with gold, it will sink. Its great that the React community is insisting on the HOC pattern. But it seems a little dogmatic for that to be the only way to do certain things. Because, its seems totally wasteful to do this for components that are tiny, and exists in hundreds. HOCs may only have small processor time requirement, but does consume memory with each component. More diffing for react, more things to keep around, more lifecycle method executions and so on.

Note that, I'm only using the above as an example. My concern is more of the pattern involved. I encounter this on many scenarios, and seem to have to jump through hoops to access these if I do not want to use more higher order components, with no other good way to solve this.

Things that could potentially solve this:

Most reasonable one IMO: Make context validation optional. Don't shove it down the component's throat.

Provide a way to access context from the outside without using higher order components. (Well, I think this kinda breaks many encapsulations, but just leaving it out there since it would theoretically solve the issue)