what if we got rid of x-engine and x-interaction? hahaha just kidding. ...unless?

[apaleslimghost]

tl;dr: it's not 2018 anymore, we can make better choices now, and these packages are poorly understood and issue-prone.

x-engine

why it exists

• to allow consumers to use their chosen JSX runtime, and have it injected into x-dash components they depend on
• to allow different runtimes to be used on server and client

what's wrong with it

• it's seen as magic (derogatory)
• it obfuscates how x-dash components actually render
• there's an occasional misconception that consuming apps also need to use x-engine
• it makes it seem like x-dash isn't directly compatible with React without a compatibility layer
• we don't actually need to be (and actually it's not possible to be) that flexible re: Runtimes. everybody uses either React or Preact.

what would we do instead

• nothing, pretty much
• internally in x-dash, we'd replace x-engine with direct React imports
• if a consumer needs to use Preact, they'd use aliasing in their bundler in the usual way

x-interaction

why it exists

• to allow x-dash components to be stateful and respond to events in a deliberately-restricted way (to ensure ft-app compatibility)
• to support server-side rendering with client-side hydration

what's wrong with it

• i did the thing where i tried to solve a people problem with technology
• it's so so complex
• higher-order components were the shit for about five minutes but now Hooks are a thing
• it's difficult to reason about where data or actions are coming from

what would we do instead

• migrate withActions to React Hooks, mostly useState and useEffect
• some simpler, better, more standard way of hydrating server-side rendered components with clientside interaction(?????)

[ivomurrell]

There are 8 projects which use hyperons instead of React or Preact. It doesn't look like it has a compatibility layer either like Preact has. Would we be dropping support for the framework as part of this change?

[apaleslimghost]

i think dropping support for Hyperons would help reduce a lot of the current confusion around x-dash/x-engine. people expect switching runtimes in their x-engine config to Just Work, which of course it doesn't if e.g. they switch to something like Hyperons where render returns a string instead of mounting a component. react-dom/server's renderToStaticMarkup, or preact-render-to-string, can be used in place of Hyperons

[ivomurrell]

Would we actually be getting rid of x-interaction here or are we instead releasing a new major version which uses modern React idioms?

[apaleslimghost]

so, there's two parts to x-interaction: stateful components using withActions, and SSR serialisation & hydration. i'm mainly thinking of replacing the withActions part (i don't have a better solution for hydration right now). withActions rewritten with Hooks would basically be just useState. a lot of the complexity of x-interaction is in the implementation of withActions and its state logic, and we'd be able to just wholesale delete that. there'd be no point having any kind of wrapper around Hooks at that point.

[magsallen]

Nice! So for x-dash components, will we need to break their dependency on x-engine before it can be removed from any apps which are consuming x-components? I think some apps install x-engine only because they're using x-follow-button or similar

[apaleslimghost]

yes. i'd release it as a new major version with a migration guide that consumers can upgrade to at their leisure. we release all x-dash components at the same version, so we can tell people "if you're using v10 you still need x-engine, if you're using v11 you don't"

[apaleslimghost]

worth noting that the only component that supports serialisation/hydration is x-live-blog-wrapper. this can be handled as an application-specific concern in next-article.