Switch to React 16

[forabi]

Currently has to be tested using NO_TYPE_CHECK=1 yarn dev

[forabi]

I got it to work, although there is a ton of TypeScript issues. Everything works, including server-side rendering.

Here is a comparison of the bundles with React 16 vs Preact:

React 16:

Preact:

[forabi]

I ran some benchmarks against a local production build, and to eliminate network variations, the app was built against a local API instance as well:

React 16:

❯ echo "GET http://localhost:3001/Tom_Hanks" | vegeta attack -duration 60s -rate 100 | tee results.bin | vegeta report
Requests      [total, rate]            6000, 100.02
Duration      [total, attack, wait]    1m0.000133875s, 59.989999871s, 10.134004ms
Latencies     [mean, 50, 95, 99, max]  16.617495ms, 12.18481ms, 35.455429ms, 48.908762ms, 79.393735ms
Bytes In      [total, mean]            149796000, 24966.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:6000  
Error Set:

Preact:

❯ echo "GET http://localhost:3001/Tom_Hanks" | vegeta attack -duration 60s -rate 100 | tee results.bin | vegeta report
Requests      [total, rate]            6000, 100.02
Duration      [total, attack, wait]    1m0.003478528s, 59.989999392s, 13.479136ms
Latencies     [mean, 50, 95, 99, max]  18.488392ms, 15.312506ms, 39.258539ms, 52.198818ms, 84.178161ms
Bytes In      [total, mean]            150114000, 25019.00
Bytes Out     [total, mean]            0, 0.00
Success       [ratio]                  100.00%
Status Codes  [code:count]             200:6000  
Error Set:

[wholesomedev]

I'm not sure how to interpret the first image that shows the sizes. I guess it shows the relative difference? React doesn't seem that bad, except React DOM is pretty big 😄

As for the performance, the two are comparable from what I can tell with React having somewhat of an edge.

[forabi]

I'm not sure how to interpret the first image that shows the sizes. I guess it shows the relative difference? React doesn't seem that bad, except React DOM is pretty big smile

Yeah, this shows the relative module sizes using Webpack Bundle Analyzer (yarn build && yarn app/analyze). Here are the actual sizes:

• vendor.js with React 16: 104KB gzipped, 420KB uncompressed (exceeds the enforced max size of 100KB).
• vendor.js with Preact: 79KB gzipped, 338KB uncompressed.

The benchmarks above test the performance of SSR. It seems that React and Preact are comparable in performance and the difference is negligible.

[forabi]

It turns out that the TypeScript issues were due to multiple, incompatible versions of @types/react being installed in node_modules. Each @types/* package for a React library defines a different range for @types/react as a dependency:

❯ find ./node_modules -wholename "*/react/index.d.ts"
./node_modules/@types/react-router/node_modules/@types/react/index.d.ts
./node_modules/@types/react-router-redux/node_modules/@types/react/index.d.ts
./node_modules/@types/react-redux/node_modules/@types/react/index.d.ts
./node_modules/@types/react/index.d.ts
./node_modules/@types/react-router-dom/node_modules/@types/react/index.d.ts
./node_modules/@types/react-dom/node_modules/@types/react/index.d.ts

Removing all of these (except ./node_modules/@types/react/index.d.ts) fixed all the issues with typings.

This is why peerDependencies is a good idea 😄

Luckily, yarn has a feature to flatten a specific dependency so that only one version of it is installed. To do so, I added a resolutions field to package.json:

  "resolutions": {
    "@types/react": "^16.0.35"
  },

... and now everything works!

[forabi]

One thing I noticed is that Preact is much more permissive regarding SSR vs client markup mismatch issues. It tries to fix the mismatches and does so silently. React on the other hand throws an error and does not fix it and the page ends up broken.

[wholesomedev]

Interesting.

Perhaps the libraries follow different philosophies with regard to failing loud vs failing silently? I wonder if React offers the option to be more tolerant of that issue. Though, if the React engineers think this is a significant issue that should be fixed instead of suppressed, they probably wouldn't offer the option to silence it.

[forabi]

This is relevant: facebook/react#10591

The styles not being patched up is expected. That's an intentional breaking change. The idea behind that is that most sites stabilize once they have a solid SSR infra in place and therefore these things don't happen, yet they would have to spend all that time validating unnecessarily when they know it's not going to change. So it's an optimization.

[forabi]

This one too: facebook/react#11064

In my understanding it is not expected to patch up the differences since doing that in production is too expensive and negates the performance benefits from the new approach.

[forabi]

Oops! Please dismiss the review request. This still need some work. Because React does not like SSR/client mismatches, we have to come up with a reproducible random string for the collapsable ID. We'll need to use React Context API for this.

[forabi]

Using the current context API with TypeScript proved to be a little tricky. I ended up moving the responsibility of defining the collapsable ID to the consuming component. Hopefully, a new React version, with the new context API, gets released soon so that we can move back to auto-generated IDs.

[wholesomedev]

Nice 👍