JSX pragma for inlining components during compilation

[snnsnn]

Hi, I was wondering if you could implement a pragma for inlining a component, that amortizes function calls during compilation. Its syntax could be an expression like {/* @inline */ <Icon /> }:

 const Icon = () => (
    <svg width="1em" height="1em" viewBox="0 0 20 20">
      <path d="M14.386 14.386l4.0877 4.0877-4.0877-4.0877c-2.9418 2.9419-7.7115 2.9419-10.6533 0-2.9419-2.9418-2.9419-7.7115 0-10.6533 2.9418-2.9419 7.7115-2.9419 10.6533 0 2.9419 2.9418 2.9419 7.7115 0 10.6533z"  />
    </svg>
  );

export const Input: Component<InputProps> = (props) => {
  return (
    <span>
      {/* @inline */ <Icon /> }
      <input {...props} />
    </span>
  )
}

Compiled output should be equal to its handwritten equivalent:

export const Input: Component<InputProps> = (props) => {
  return (
    <span><svg width="1em" height="1em" viewBox="0 0 20 20"><path d="M14.386 14.386l4.0877 4.0877-4.0877-4.0877c-2.9418 2.9419-7.7115 2.9419-10.6533 0-2.9419-2.9418-2.9419-7.7115 0-10.6533 2.9418-2.9419 7.7115-2.9419 10.6533 0 2.9419 2.9418 2.9419 7.7115 0 10.6533z" /></svg>
      <input {...props} />
    </span>
  )
}

The use case is sometimes we need to insert an element in multiple different positions inside the parent component. Rather than typing the element multiple times, it is more convenient to abstract it into a component and use that component. But it brings an extra cost which could be eliminated easily during compilation.

I don't know how JSX is parsed and transpiled but a simple replacement should not bring that much complexity.

Components without props will work out of the box but if component has props, responsibility of making sure that props resolve to a value should befall on the developer.

 const Icon = (props) => (
    <svg width={props.size} height={props.size} viewBox="0 0 20 20">
      <path d="M14.386 14.386l4.0877 4.0877-4.0877-4.0877c-2.9418 2.9419-7.7115 2.9419-10.6533 0-2.9419-2.9418-2.9419-7.7115 0-10.6533 2.9418-2.9419 7.7115-2.9419 10.6533 0 2.9419 2.9418 2.9419 7.7115 0 10.6533z" />
    </svg>
  );

export const Input: Component<InputProps> = (props) => {
  return (
    <span>
      {/* @inline */ <Icon size={props.size} /> }
      <input {...props} />
    </span>
  )
}

By the way, if if parent has the same props as the replaced child, a simple replacement still works:

export const Input: Component<InputProps> = (props) => {
  return (
    <span><svg width={props.size} height={props.size}  viewBox="0 0 20 20"><path d="M14.386 14.386l4.0877 4.0877-4.0877-4.0877c-2.9418 2.9419-7.7115 2.9419-10.6533 0-2.9419-2.9418-2.9419-7.7115 0-10.6533 2.9418-2.9419 7.7115-2.9419 10.6533 0 2.9419 2.9418 2.9419 7.7115 0 10.6533z"  /></svg>
      <input {...props} />
    </span>
  )
}

[lxsmnsyc]

I don't know how JSX is parsed and transpiled but a simple replacement should not bring that much complexity.

Unironically, it happens to be that way. There's a lot of reasons why this isn't ideal (or achievable), but to back up this claim, I guess it doesn't matter if it should be inlined or not, there's not much performance gain anyways.

[snnsnn]

Please don't be quick to dismiss ideas. Here, I discovered an actual use case, rather than the one I offered on the initial post:

We rendered a list using Index component and each item was using 5-10 sub-components. We though subcomponents was good for styling and maintenance. What we discovered is when the component gets fragmented in a way to include many subcomponents performance degrades considerably and UI becames laggy even though UI was taking advantage of memos and caching . So, we had to discard the subcomponents and write everything as a single component. So, inlining could be a way to improve performance.

[lxsmnsyc]

I dismissed it because it requires cross-file analysis, something beyond Babel itself and the optimization step is too complex even though the idea is simple

[lxsmnsyc]

Mind you we've discussed even having cross-template merging but like that's just a dream implementation. The theoretical benefit is there but the implementation is unrealistic. Even then the scenario you shared, without realistic repro, can easily be dismissed. This is all Hitchens's razor.

[juanrgm]

I'm experiencing the same problem with a list of only 300 items (about 10 components per item).