Recompose: Compatibility with non-React VDOMs (e.g. Preact, Inferno)

[pl12133]

• [x] I have searched for similar issues, but found none.
• [x] I have read the README.
• [x] I attempted to read the CONTRIBUTORS guide, but found none.

I am wondering if there is interest within this project to support other VDOM implementations such as preact and inferno. I am currently using recompose with preact and I believe it adds a lot of value to our project; but there are bugs caused by accessing non-public React API's such as the use of Component.prototype.isReactComponent in isClassComponent.

If this is considered valuable for recompose I would be happy to contribute towards that direction. Thanks for the quality library.

[istarkov]

can you provide an example of opensource library with support of react preact and inferno where tests are shared across all frameworks.
what the minimal changes we can make to run jest tests?

[istarkov]

BTW I dont like the idea to add official support of all that react-like libs. As since that to implement any change or to add a new feature we will need to have a knowledge about implementation details of all that libraries.
IMO its the problem of compatibility wrappers of preact and inferno to implement needed features.

[pl12133]

I doubt I could find a library which is tested against all three of these VDOM implementations. I have seen in the past that popular component modules become forked for compatibility, such as react-side-effect being forked into both preact-side-effect and inferno-side-effect. To fork recompose in this way would be a large undertaking, and I would like to avoid the need for that.

I wouldn't suggest targeting anything other than React, just that the public API should be preferred over diving into the "private" API. I agree the majority of the work should be handled in compatibility wrappers, and this could be an issue to be raised with preact-compat.

[billneff79]

What about using something that is in the public API for Component, like checking for the existence of the setState and/or forceUpdate functions, to determine if something is a React Component class? Those are both publicly documented, and are only on Component, not on PureComponent or any of the other classes from https://github.com/facebook/react/blob/ae430b79139777b74167b124719b3dc311aa5294/src/isomorphic/modern/class/ReactBaseClasses.js

[developit]

Best to check for render() - it's technically the only required method for a component to implement. I submitted PR #463 for the change.

[billneff79]

To maintain compatibility with what he is already doing in isClassComponent, it would have to return true for React.Component but false for React.PureComponent and React.AsyncComponent, since React.Component is the only one that has the isReactComponent prop. All of them would have render, but only React.Component has setState and forceUpdate. If he doesn't care about changing it so it returns true for PureComponent then checking for render would work as well.

[developit]

Yup. A quick scan indicates the desired semantics (and tests) are basically "is this a component that is not a PFC", which would point to the render check:

• usage to check if a component is a functional component before converting it to a class
• usage to check if a component is a _pure_ functional component

[ericclemmons]

I was attempting to use recompose with preact (after seeing #463 ship v0.25.0), but found that react is still required and throws a run-time error if missing.

By adding babel-plugin-lodash, I was able to see that some features (not all) require react (e.g.withStateHandlers).

Lastly, by aliasing in preact-compat, I was able to get everything to work.

I don't know if it's possible for more of recompose to exist without react as an explicit dependency, but I would like to investigate it.

Anecdotally, we've leveraged recompose + react on a large codebase, but have needed to severely cut file size down for our partners, requiring preact + preact-compat, but are eagerly attempting to cut every Kb (including preact-compat).

[ericclemmons]

Confirmed that resolve: { alias: { react: "preact" } } is enough for this to work with preact!

I can't answer for Inferno, but would that warrant an update to the README.md, since preact support isn't advertised yet?

[istarkov]

Having that it work, it would be nice to extend readme :-)

[neerav-mehta-jabong]

@ericclemmons preact-compat is still required as only aliasing gives an error:
./node_modules/recompose/dist/Recompose.esm.js 759:33-46
"export 'createFactory' was not found in 'react'