Access to other files source code can be established by populating the full dependency graph. Tools like browserify, webpack, systemjs or assetgraph give you that

@Munter This is not currently available by default nor set up in people's build systems. At any kind of large code base it is also too slow to just read/parse these files randomly. It needs to be smarter, parallelize and cache info. It's certainly not impossible to build but it just isn't integrated. We'd have to build it and get adoption before this particular transform is possible.

To illustrate what @sebmarkbage is talking about rollup limitations, here is a pseudo code of the example above:

http://rollupjs.org/#%7B%22options%22%3A%7B%22format%22%3A%22es%22%2C%22moduleName%22%3A%22myBundle%22%2C%22globals%22%3A%7B%7D%7D%2C%22modules%22%3A%5B%7B%22name%22%3A%22main.js%22%2C%22code%22%3A%22import%20Foo%20from%20'.%2Ffoo.js'%3B%5Cnimport%20Classes%20from%20'.%2Fcssclasses.js'%3B%5Cnexport%20default%20function%20Bar(props)%20%7B%5Cn%20%20return%20new%20Foo(%7Bdata%3A%20%7B%20type%3A%20'img'%2C%20src%3A%20props.src%20%7D%2C%20className%3A%20Classes.bar%7D)%3B%5Cn%7D%22%7D%2C%7B%22name%22%3A%22foo.js%22%2C%22code%22%3A%22export%20default%20function%20Foo(props)%20%7B%5Cn%20%20if%20(props.data.type%20%3D%3D%3D%20'img')%20%7B%5Cn%20%20%20%20return%20new%20Img(%7Bsrc%3A%20props.data.src%2C%20className%3A%20props.className%2C%20alt%3A%20props.alt%7D)%3B%5Cn%20%20%7D%5Cn%20%20return%20new%20Span(props.data.type)%3B%5Cn%7D%5CnFoo.defaultProps%20%3D%20%7B%5Cn%20%20alt%3A%20%5C%22An%20image%20of%20Foo.%5C%22%5Cn%7D%3B%5Cn%5Cnexport%20function%20thisWillBeRemoved()%20%7B%5Cn%20%20%20%2F%2F%20code%20will%20be%20eliminated%5Cn%7D%22%7D%2C%7B%22name%22%3A%22cssclasses.js%22%2C%22code%22%3A%22export%20default%20%7B%5Cn%20%20bar%3A%20'bar'%5Cn%7D%3B%5Cn%5Cnexport%20const%20thisWillBeAlsoIgnored%20%3D%201%3B%22%7D%5D%7D

Then, running the output of rollup thru closure compiler, you will get this:

module.exports =  = function(b) {
         b = {data:{type:"img", src:b.src}, className:"bar"};
         return "img" === b.data.type ?
                 Img({src:b.data.src, className:b.className, alt:b.alt}) :
                 Span(b.data.type);
};

In other words, the precedent is there, and certainly, rollup's tree-shaking capabilities can be improved to cover other primitives, but we will need much more optimizations in terms of how react uses the components to achieve what you described.

/cc @Rich-Harris

This reminds me a bit of @jeffmo's talk about using Flow for tree-shaking at React Europe.

I thought about it a lot and there would probably be a need of some sort of cursor to edit what to fold and what not to fold regarding code size no ?

After a lot of folding, there would logically be the original component definition (if we couldn't fold everything ?) + the number of time it was folded * the size of what was folded.

Depending on what was done; the bundled size could jump a lot. Unless I'm missing something, this component folding should only fold one liners for webApp, and high to no limitations for server side rendering (if you build your backend) and desktop apps (electron & stuff).

Great

@sebmarkbage isn't this only half of the final frontier? In my mind the final frontier of React includes (in addition to component folding) compiling away any virtual DOM diff when possible. For example:

import React, { useState } from 'react'
const ChristmasButton = () => {
  const [color, setColor] = useState('green')
  return (
    <button
      style={{backgroundColor: color}}
      onClick={() => setColor(color === 'green' ? 'red' : 'green')}
    />
  )
}

What if React could compile the onClick handler to just:

() => {
  color = color === 'green' ? 'red' : 'green'
  button.style.backgroundColor = color
}

@jedwards1211 That seems to contradict React's design philosophy of preserving control over scheduling, if I understand correctly. That thin layer allows prioritizing more critical updates over less important ones that may otherwise noticeably degrade performance.