RFC: Magical replacement of components

[eric-burel]

Cross post of https://github.com/VulcanJS/Vulcan/issues/2549

Dream goal

Goal is to replace the dynamic Component replacing pattern by explicit exports that would "magically" replace components.

Imagine a component structured like this:

// datatable.js
const DatatableHeader = () => (<header>default header</header>)

const DatatableFooter = () => (<footer>default footer</footerr>)

const DatatableContent = ({children}) => (
    <div>
        <DatableaHeader />
            {children}
        <DatatableFooter />
</div>

const Datatable = () => (
    <div>
        <DatatableContent />
    </div>
)

You may want to replace the Header, and the Content with your own components:

// my-overrides.js, a special file that contains my Vulcan components override. Could be detected at build time.
export * from "vulcan/ui-react" // magically imports DatatableFooter, DatatableHeader, DatatableContent and Datatable
export const DatatableHeader = () => (<header> I AM OVERRIDEN </header>) // first override
export const DatatableContent = () => (<div><DatatableHeader/> <div> Hello </div> <DatatableFooter /></div> // second override

Then you consume them like this, business as usual:

// my-page.js
import { Datatable } from "vulcan/ui-react" // import default components + my custom override

export const MyPage = () => (<Datatable>Hello!</Datatable>) // DatatableContent has magically been replaced in Datatable

It's probably undoable with Meteor, but it could prove doable with Webpack. The tricky part is that you want to override only certain component, that are themselves nested into other replaceable component. You get a kind of recursive/circular import issue.

What's doable today

This pattern is already implementable with one level of imports like this:

// my-ui.js
export * from "vulcan/react"
export const DatatableHeader = () => (...) // will reexport, overriding default DatatableHeader from "vulcan/react"

but it's not enough to handle more deeply nested component replacement, for complex components like DataTable or SmartForm that have multiple layers of replaceable component.

Possible implementation

Step 1: detecting "magic" replacement

First step is defining a syntax for magic components.

Possibilities:

• Prefixing components, eg <@Datatable>: can be detected component by component but it's not very clean

• "Magic import syntax", eg import { ComponentToReplace } from "vulcan/magic-component"/ export * from "vulcan/magic-components": detect that we want to import "magic components" or override them

• a special file name for files that exports component override

• explicitely declaring dependencies between components eg export { component: Datatable, dependsOnMagic: ["DatatableContents"] }

Step 2: build

The difficulty is to handle deeply nested replaceable component.

• Datatable is defined with default components
• We detect that DatatableFooter is overridden by user
• We rebuild DatatableContents with overridden DatatableFooter export
• We rebuild Datatable, which depends on DatatableContents which contains an overridden export.

The build would probably look like a recursive structure or a tree, where we rebuild everything until all nested components are replaced by user's overrides.

[EloyID]

And sth like export const SmartForm = customizeSmartForm({components: {FormHeader: MyOwnFormHeader}}) in your own packages? We can reuse the components prop to override those used for the smartForm like a HOC

customizeSmartForm = (props) => { return (props2) => <SmartForm {...props} {...props2}> }

[eric-burel]

That's a way indeed, you would define your component as a closure: const SmartForm = components => (props) => {...} so you can pass different type of components

Currently the Datatable accepts something similar but with components as a prop, so technically we could already be able to implement something like that.