"use strict"; const {Fragment: _Fragment, jsx: _jsx, jsxs: _jsxs} = arguments[0]; function _createMdxContent(props) { const _components = { a: "a", code: "code", em: "em", h2: "h2", h3: "h3", h5: "h5", li: "li", p: "p", pre: "pre", ul: "ul", ...props.components }; return _jsxs(_Fragment, { children: [_jsxs(_components.p, { children: ["Composition over configuration is a key tenet in ", _jsx(_components.a, { href: "https://mdxjs.com", children: "MDX" }), "\nand where it departs from existing Markdown approaches. It allows authors\nto import and mix in functionality (as a component) rather than overloading\nMarkdown syntax."] }), "\n", _jsx(_components.p, { children: "Not to mention, syntax overloading is typically done at the build tool level\nwhich means a plugin that's intended to target a handful of pages happens\nacross the board." }), "\n", _jsx(_components.p, { children: "Composition is powerful because it's a \"simple\" abstraction that's\nmeant to combine functionality between two otherwise separate parts.\nIt tends to be less leaky than configuration-based approaches and\navoids framework coupling. Another benefit is the fact that composition\nbecomes more flexible and explicit." }), "\n", _jsx(_components.p, { children: "In essence, composition can be boiled down to:" }), "\n", _jsx(_components.h5, { id: "object-composition", children: _jsx(_components.a, { href: "#object-composition", children: _jsx(_components.a, { href: "https://en.wikipedia.org/wiki/Object_composition", children: "Object composition" }) }) }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-js", children: "const newThing = {\n ...someValues,\n color: \"tomato\",\n};\n" }) }), "\n", _jsx(_components.h5, { id: "or-functional-composition", children: _jsxs(_components.a, { href: "#or-functional-composition", children: ["Or ", _jsx(_components.a, { href: "https://en.wikipedia.org/wiki/Function_composition_(computer_science)", children: "functional composition" }), ":"] }) }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-js", children: "f(g(x));\n" }) }), "\n", _jsxs(_components.p, { children: ["For the purposes of this post we'll be mostly focusing on functional\ncomposition and how it relates to components in React/", _jsx(_components.a, { href: "https://mdxjs.com", children: "MDX" }), "."] }), "\n", _jsx(_components.p, { children: "First, let's consider where configuration falls short." }), "\n", _jsx(_components.h2, { id: "configuration-is-typically-global", children: _jsx(_components.a, { href: "#configuration-is-typically-global", children: "Configuration is (typically) global" }) }), "\n", _jsxs(_components.p, { children: ["In most cases, configuration is applied globally to a project or framework.\nFor example, let's consider remark plugins in ", _jsx(_components.a, { href: "https://gatsbyjs.org", children: "Gatsby" }), "."] }), "\n", _jsxs(_components.p, { children: ["When you apply a plugin to the global remark transformer it will affect\nevery document in the project. This can be problematic when you only need\nto add a responsive Youtube embed in a single Markdown file. What's also\ninteresting, is a project will typically ", _jsx(_components.em, { children: "already" }), " have a Youtube component\nthat's used somewhere else (perhaps in a JSX-based page)."] }), "\n", _jsx(_components.h2, { id: "suboptimal-workflow", children: _jsx(_components.a, { href: "#suboptimal-workflow", children: "Suboptimal workflow" }) }), "\n", _jsx(_components.p, { children: "The plugin workflow also departs from the parts of the project you're spending\nmost of your time in. If you're building for the web you're typically writing\ncontent or building components for new pages, layouts, etc. You're operating\nat an abstraction layer that's typically above the notion of configuration and\nplugins (which is a good thing!)." }), "\n", _jsx(_components.h2, { id: "components-over-configuration", children: _jsx(_components.a, { href: "#components-over-configuration", children: "Components over configuration" }) }), "\n", _jsx(_components.p, { children: "In the frontend world we're already operating with a compositional\nabstraction, the very components we're working with day in and day\nout. We operate with a syntactic wrapper (JSX) and pass data to\na tree of components to render UI. Technically speaking JSX is a\nDomain Specific Language (DSL), but it's one that is generally accepted\nin the wider community and really isn't much more than a shortcut\nfor function calls." }), "\n", _jsx(_components.p, { children: "JSX and components provide an expressive syntax for composition\nthat can cut out configuration in a lot of cases. This is a good thing\nbecause composition is only introduced where it's invoked and doesn't\ncause global side effects." }), "\n", _jsx(_components.h3, { id: "natural-layering", children: _jsx(_components.a, { href: "#natural-layering", children: "Natural layering" }) }), "\n", _jsx(_components.p, { children: "Component composition allows you to layer specific needs." }), "\n", _jsx(_components.h5, { id: "components-can-be-wrapped", children: _jsx(_components.a, { href: "#components-can-be-wrapped", children: "Components can be wrapped" }) }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-js", children: "\n \n\n" }) }), "\n", _jsx(_components.h5, { id: "components-can-be-siblings", children: _jsx(_components.a, { href: "#components-can-be-siblings", children: "Components can be siblings" }) }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-js", children: " $\"numbers\"$ \n\n" }) }), "\n", _jsx(_components.h5, { id: "components-can-be-abstracted", children: _jsx(_components.a, { href: "#components-can-be-abstracted", children: "Components can be abstracted" }) }), "\n", _jsx(_components.p, { children: "When there's a common usage, a composition can be tucked away." }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-js", children: "\n" }) }), "\n", _jsxs(_components.p, { children: ["It's important to note that ", _jsx(_components.code, { children: "ImageWithCitation" }), " is a contrived example\nthat is better expressed as two separate, sibling components."] }), "\n", _jsx(_components.h3, { id: "combining-common-elements", children: _jsx(_components.a, { href: "#combining-common-elements", children: "Combining common elements" }) }), "\n", _jsx(_components.p, { children: "In the above example you might find that as a project evolves that\nall Youtube components are accompanied by a wrapping ResponsiveIframe\ncomponent. After that pattern becomes solidifed you can create a\nnew component, ResponsiveYoutube and begin using that in its place." }), "\n", _jsx(_components.p, { children: "This allows small changes to be made in one place that will be reflected\nin all call sites for the component." }), "\n", _jsx(_components.p, { children: "What makes this especially powerful is the fact that you don't have\nto immediately port the existing usage right away. That can happen\nover time. Additionally, when there are edge cases that need some type\nof one-off functionality you find yourself working at the component\nlayer rather than overloading a plugin, syntax, or configuration option." }), "\n", _jsx(_components.h3, { id: "breaking-them-back-apart", children: _jsx(_components.a, { href: "#breaking-them-back-apart", children: "Breaking them back apart" }) }), "\n", _jsx(_components.p, { children: "Similarly to Legos you can break apart components when further customization\nis needed. Libraries can expose more \"batteries included\" components as\nthe primary API surface area which can be broken back apart to create something\nmore bespoke." }), "\n", _jsxs(_components.p, { children: ["If ", _jsx(_components.code, { children: "CustomYoutube" }), " component consists of ", _jsx(_components.code, { children: "ResponsiveIframe" }), " and ", _jsx(_components.code, { children: "Youtube" }), "\nyou can break away from the composite component to add one-off usage."] }), "\n", _jsx(_components.pre, { children: _jsx(_components.code, { className: "language-js", children: "\n \n \n \n\n" }) }), "\n", _jsx(_components.h2, { id: "composition-is-evolving", children: _jsx(_components.a, { href: "#composition-is-evolving", children: "Composition is evolving" }) }), "\n", _jsxs(_components.p, { children: ["React Hooks introduce a new method of composition in components that provide\nthe power of mixins without the drawbacks. Granted, Hooks, have a lot of\n", _jsx(_components.a, { href: "https://reactjs.org/docs/hooks-faq.html#what-is-the-prior-art-for-hooks", children: "prior art" }), ",\nbut their introduction makes it more accessible to framework users and it's\nbuilt in."] }), "\n", _jsx(_components.h2, { id: "conclusion", children: _jsx(_components.a, { href: "#conclusion", children: "Conclusion" }) }), "\n", _jsx(_components.p, { children: "Configuration-based systems are necessary at low-levels to ensure underlying\ntooling is flexible. This posts isn't meant as a jab at any of the tools we\nuse on a day-to-day basis. In fact, I love that they're so flexible and pluggable\nso we can focus time and energy on making those tools bulletproof for the greater\ncommunity. However, for the vast majority of developers, we can work at the\nnext layer of abstraction which can, and should, favor composition." }), "\n", _jsx(_components.h2, { id: "related", children: _jsx(_components.a, { href: "#related", children: "Related" }) }), "\n", _jsxs(_components.ul, { children: ["\n", _jsx(_components.li, { children: _jsx(_components.a, { href: "https://compositor.io/blog/introducing-kit#components-over-configuration", children: "https://compositor.io/blog/introducing-kit#components-over-configuration" }) }), "\n", _jsx(_components.li, { children: _jsx(_components.a, { href: "https://clojurefun.wordpress.com/2012/08/17/composition-over-convention/", children: "https://clojurefun.wordpress.com/2012/08/17/composition-over-convention/" }) }), "\n"] })] }); } function MDXContent(props = {}) { const {wrapper: MDXLayout} = props.components || ({}); return MDXLayout ? _jsx(MDXLayout, { ...props, children: _jsx(_createMdxContent, { ...props }) }) : _createMdxContent(props); } return { default: MDXContent };