Rename createSyncRoot to createBlockingRoot

[gaearon]

"Sync" is easy to confuse with the Legacy mode. It also might sound too positive.

While I'm renaming createSyncRoot to createBlockingRoot, I also did some find-and-replace in comments and internal naming. Let's standardize on:

• Legacy Mode: The old one.
• Blocking Mode: createBlockingRoot
• Concurrent Mode: createRoot

[acdlite]

Can we consider passing an option to createRoot instead, like {disableConcurrentRendering: true}? (This options object already exists for enabling hydration.) I think the original reason we went with a separate API was because we didn't want to expose createBatch to the non-concurrent version. But createBatch no longer exists.

[acdlite]

I'm just not convinced "blocking" is a thing people will intuitively understand and I'm worried the additional terminology is more confusing than it's worth.

[gaearon]

Concurrent Mode with "disabled concurrent rendering" isn't that much easier to explain IMO though — and we need to refer to this concept somehow when discussing adoption strategy.

[sizebot]

Size changes (experimental)

No significant bundle size changes to report.

Generated by 🚫 dangerJS against be0ce36

[acdlite]

But like what is the difference between "blocking" and "concurrent"? Are they mutually exclusive? Can you have one without the other? Technically legacy is also blocking. Why not createNonConcurrentRoot? I don't get what "blocking" buys us as an additional terminology.

[sizebot]

Size changes (stable)

No significant bundle size changes to report.

Generated by 🚫 dangerJS against be0ce36

[acdlite]

To clarify, I have two separate objections:

• Do we need two separate methods, instead of using an option? Given that the end game is to get rid of "blocking" mode and move everyone to concurrent mode.
• Is it worth adding a new term "blocking" when most people won't know what that means without an extra explanation, at which point we might as well keep using "concurrent."

[acdlite]

OTOH I don't think it's any worse than what we already have, so I don't mind if we merge this for now. I would prefer to bikeshed it more before the actual release, though.

[sebmarkbage]

There are a number of considerations for an options object:

• Future additions to the api (such as adding createBatch back) that are mode specific.
• Tree shaking, or clearly defined separate modules (like /legacy), makes it easier to create separate builds for it in the future.
• It encourages dynamic usage in wrappers. In fact that’s exactly what we do with hydration at FB.

That said, these arguments mostly apply to hydration too and we already said we didn’t want a combinatorial explosion.

[sebmarkbage]

I mostly suggested it because Sync looked bad in the column. I’m all for bikeshedding this further before release.

However we should decide the name of the column now “Legacy Mode”, “??? Mode”, “Concurrent Mode”.

[acdlite]

What I like about "legacy" is that describes the target use case as opposed to the technical characteristics. Maybe we could do the same here. "Compatibility Mode"?

[sebmarkbage]

Tests failing.

[gaearon]

Oops. Pushed