Overriding/extending ReactHostComponent.createInternalComponent

[markbrocato]

It would be nice to be able to override or extend ReactHostComponent.createInternalComponent to expand the set of elements that can be rendered beyond html. In extjs-reactor we are doing this by patching the createInternalComponent function so that any tag that starts with a specified prefix (the default is x-) creates an Ext JS Component: https://github.com/sencha/extjs-reactor/blob/master/packages/reactor/src/index.js#L14

I'd love to have a more stable way of doing this. It looks like something along these lines was originally considered, but never fully implemented and recently removed:

461a741

Do you have any advice for a more sustainable approach or would you consider an API for this?

[gaearon]

We are working on reimplementation of React (you can search for "Fiber" in issues), so this particular internal API will definitely be removed, and project using it will break.

Instead Fiber will eventually provide an official way to create custom renderers. Projects like react-art will use that API instead of the current one. So you could use a custom renderer then.

Is there any particular reason you implement these as internal components instead of using React public API? It is not clear to me.

[markbrocato]

Thank you for reviewing this, Dan. Great news that there will be an official way to create custom renderers!

It would be nice to be able to extend or augment the built in html renderer rather than reimplementing rendering from scratch. React-art requires a specific root element as the context for rendering art element. I'd prefer to be able to render Ext JS and html components interchangeably, rather than manually switching contexts with a root element. I ask that you consider this use case when implementing the custom renderer API.

I chose to use internal components rather than using the public API for a few reasons, but these are probably the most important:

• The Ext JS codebase isn't currently organized as ES6 or commonJS modules, so users can't import component classes they way they would with other component libraries.
• It's probably safe to say that Ext JS has more components than any other library. We'd prefer not to create React-specific wrapper components for all Ext JS components. That would be a lot of code and would bloat builds.

That said, nothing is set in stone. We just published this package last week, so it's still fairly early. I'm certainly open to suggestions to improve and future-proof our implementation.

Do you think using a higher order component to wrap Ext JS components would be a more sustainable solution? For example, user's code would look something like:

import { reactify } from '@extjs/reactor';

const Grid = reactify('Ext.grid.Panel');

export default function MyComponent() {
    return <Grid ... />
}

[gaearon]

Yes that would be a better solution in longer term I think.
These internals break every few versions so you really shouldn’t rely on them.

[gaearon]

Going to close as it's not actionable for us right now, and seems like you have a way forward.

[markbrocato]

@gaearon Do you have an estimate of when the fiber-based reimplementation of react will be released and what the version number will be? What's the best way for me to track your progress?

Thank you for your help. Switching to a higher order component turned out to be a fairly simple change with little impact on my existing code.

[gaearon]

You can track the progress in #7925. I hope React 17 will use Fiber, we'll also likely provide it as opt-in in a few months.

[Kurara]

reactify doesn't work for me when I use override instead of extends in a Ext.define