Using "component" instead of "library" for Fill definition (Slot & Fill pattern)

🗣 Feature Discussions Awaiting Development
,
1

Description

In the implementation proposal of “Slot and Fills” pattern, the “library” property is described as:

library: Name of the component they want to use. Required.

Why not use the name component for this propety?

Examples

Possible solution

Use a component property in the configuration object to define the Fill for the Slot and Fills pattern

const state = {
  fills: {
    namespace: {
      nameOfTheFill: {
        slot: "Name of the slot they want to feel",
        component: "AnyComponentWeWantToUseForTheFill",
        priority: 5,
        props: {
          // Object with props that will be passed to the component.
        },
      },
    },
  },
};
2

I named it library because configuring things in the state that require a function that is stored in libraries is going to be a recursive pattern in Frontity.

I felt like if it was named library, it was easier to remember where it’s coming from.

Two ideas that may follow a similar pattern are handlers and processors.

Source handlers:

import { archive, taxonomy, ... } from "./handlers";

export default {
  state: {
    source: {
      handlers: {
        home: {
          pattern: "/",
          library: "wpSource.archive",
        },
        categories: {
          pattern: "/category/:slug",
          library: "wpSource.taxonomy",
          options: {
            type: "post",
          },
        },
        // ...
      },
    },
  },
  libraries: {
    source: {
      handlers: {
        wpSource: {
          archive,
          taxonomy,
          // ...
        },
      },
    },
  },
};

Html2React processors:

import { twitter } from "./processors";

export default {
  state: {
    html2react: {
      processors: {
        script: {
          priority: 5,
          library: "html2react.script", // Added to libraries by html2react.
        },
        twitter: {
          priority: 9
          library: "theme.twitter",
          options: {
            lazy: true
          }
        }
      },
    },
  },
  libraries: {
    html2react: {
      processors: {
        theme: {
          twitter
        }
      }
    }
  }
};

I was trying to be consistent with the syntax.

3

Thanks for suggesting this @juanma.

I was literally going to suggest the same thing - I’ve made a private note on Monday but haven’t shared it yet :smile:

Basically, I also felt confused by the library name and component is much clearer to me. Even having worked with the processors before, I haven’t made the connection between that API and the Slot and Fill API, so I think that I would sacrifice the consistency for clarity in this case :slight_smile:

4

Okay, then it seems it makes sense to change it. As this feature is not a beta, we should make it backwards compatible. I guess that wouldn’t be a problem right?

5

nope, not a problem :slight_smile:

We can add a deprecation warning now and remove it in Frontity 2.0 later.

6

I’m still not convinced about this. Remember that it includes the namespace. It is not:

component: "AnyComponentWeWantToUseForTheFill",

But:

component: "namespace.AnyComponentWeWantToUseForTheFill",

which points to libraries.fills.namespace.AnyComponentWeWantToUseForTheFill.

With library I was trying to:

  • Inform the user where the code can be found.
  • Reduce a bit the long string by only using namespace.component.

If we rename it to component, we will be removing that part of the information. So I agree to rename it to component but if we add libraries to the string, to counter for the loss of information:

component: "libraries.fills.namespace.AnyComponentWeWantToUseForTheFill",

And we would have to follow the same approach for this pattern in the future:

Source handlers:

handler: "libraries.source.handlers.namespace.someHandler",

Html2React processors:

processor: "libraries.html2react.processors.namespace.someProcessor",