Proposal: Remove React.DOM (dom component factories) API and release as new module

[zpao]

The React.DOM API (not to be confused with ReactDOM) does not make sense in the greater scheme of the React API being used in other rendering environments like React Native or GL or <insert anything that isn't the DOM>. The React.* API is meant to be universal in that sense. We are never going to add React.iOS.

However, these factories don't actually have any implementation details that rely on actual DOM details, they essentially just map like so: React.DOM.div = (...args) => React.createElement('div', ...args), which is why they ended up in the universal React package and not in ReactDOM.

This would only impact people who don't currently use JSX and have held out using the function call syntax. <div/> now (and has for over a year) transforms to React.createElement('div'). The conveniences of the function syntax are a big deal for many people (especially coffeescript users and those who are strongly anti-JSX) so we don't want to break anybody, but we would like to migrate them from the core React API.

So the proposal would be a new package which just exports the exact set of things that React.DOM currently makes available. It would require some small changes to your code and a new package dependency, but is otherwise identical. Here's what the change might look like.

// before
{div, span} = React.DOM

// after
{div, span} = require('react-some-other-package');

[mxstbr]

👍

I discovered React.DOM.<element> recently, and was really confused as to why that was there. I think it's a good idea to have that in a separate package, though it would probably need a major version increase. (Depreciation with warnings maybe?)

[sophiebits]

These also work today:

const div = React.createFactory('div'); 
// then div(...)
const e = React.createElement;
// then e('span', ...)

[feifanzhou]

Would it make sense to add this as part of ReactDOM rather than adding to package fatigue with another module?

[zpao]

Potentially but we would have to change the API so there would be code changes required anyway (ReactDOM.DOM is bad). Personally I think it would make more sense in a standalone package. Ideally we'd like to move away from whitelists like this in React and ReactDOM itself. There's nothing stopping you from doing React.createElement('awesome-new-spec-element') but maintaining a whitelist requires a new release and it can be versioned independently and be used with different React versions. Adding React.DOM['awesome-new-spec-element'] would require a new release and would be truly obnoxious to add to every possible version so we'd likely only add it in the next minor version, not backporting. Whereas a separate package could get its own bump without having to pick up other React changes.

[matystl]

👍
Also what would be nice to get inspiration from hyperscript-helpers especialy have richer interface for element functions https://github.com/ohanhi/hyperscript-helpers#api

[sebmarkbage]

Which ReactDOM? react-dom, react-dom/server or react-dom-third-party...? The point is to not have a dependency from a normal component into the specific renderer so that you can switch out the renderer.

[zpao]

@matystl I really don't think we'll change any APIs or behaviors. The idea is not to make these methods more flexible and support different use cases, simply to move them from their current location. People are welcome to use hyperscript or similar if they want other APIs instead.

[jquense]

is there somethng to PR here? would you just add another build step to produce the package from the main repo, or a new repo just for the factories (perhaps in the reactjs org)? In any case I'd be happy to PR something, just not sure what the best way to do it might be

[zpao]

I would probably move it to a separate project in the org, but nothing for anybody to do at the moment.

[chicoxyzzy]

In future this could be implemented as easily as:

import { createFactory } from 'react'; // 'react-dom'? 'react/dom'?

export default new Proxy(Object.create(null), {
  get(target, type) {
    return createFactory(type);
  }
});

[syranide]

@chicoxyzzy Not if you care about browser support or GCC advanced optimization.

[moodysalem]

Does this already do it?
https://www.npmjs.com/package/r-dom

[zpao]

Yes however that depends on the react package (which we wouldn't directly, would probably be a peerDep?) and it supports adding extra properties (eg isRendered) which we also wouldn't do.

[chicoxyzzy]

about browser support

that's why I said "in future" :)

or GCC advanced optimization

this might be an issue but I think it could be solved

[tj]

Is there any reason to have these functions at all, vs JSX compiling to plain objects? It could be more user-friendly for the hand-written cases as well, and no need to import 'react' all the time or add it as a dep for many components.