Namespace collision between grid areas components and custom component

What:

When using render prop of Composition component it generates areas components based on grid-template-areas. This often leads to semantic namespaces collision with corresponding custom React components:

import { Composition } from 'atomic-layout'
import Header from './components/Header'

const Page = () => (
  <Composition areas="header footer">
    {({ Header }) => (
      <>
        <Header><Header /></Header> // oops, collision!
      </>
    )}
  </Composition>
)

Why:

• It decreases the DX with the library
• Grid areas often reflect semantics of a layout, just as actual component’s names
• Polymorphic prop doesn’t help, as area component’s name already exists in scope in order to use polymorphic prop

[kettanaito]

Proposal: Area generic component

Atomic layout can expose a generic Area component that would act as a single domain for rendering and mapping components to grid areas.

Spec

• Area component accepts all prop aliases as the Box component
• Area component supports as: JSX.Element polymorphic prop.
• Area component supports name: string prop that produces grid-area ${props.name} mapping to CSS Grid areas
• (?) Component performs diff between responsive values of the areas props, wrapping conditional areas into <MediaQuery/> wrapper (as render prop functionality does now)

Usage

import { Area, Composition } from 'atomic-layout'
import { Header, Footer } from './components'

const Page = () => (
  <Composition areas="header footer">
    <Area name="header" as={Header} />
    <Area name="footer" as={Footer} />
  </Composition>
)

This also means that the value of name prop can be dynamic, switching the content of the area, without changing the area position. This can come in handy when combined with #132:

import { useResponsiveValue, Composition, Area } from 'atomic-layout'
import { Header } from './components'

const Page = () => {
  const areaName = useResponsiveValue({ lg: 'right' }, 'left')
  
  return (
    <Composition areas="left right">
      <Area name={areaName} as={Header} />
    </Composition>
  )
}

[MioQuispe]

Proposal: Dedicated default area

Composition component exposes a hard-coded default area in the render prop. That area component can be used to render other template areas parametrically without explicitly rendering their respective components.

Usage

const { Composition } from 'atomic-layout'
import Logo from './logo.svg'

const Header = () => (
  <Composition areas="logo menu actions">
    {({ Area, Menu }) => (
      <>
        {/* Renders "logo" area parametrically */}
        <Area name="logo" marginRight={10}>
          {/* Well, looks like no namespace collision */}
          <Logo />
        </Area>

        {/* Renders "menu" area as usual */}
        <Menu>{...}</Menu>

        <Area name="actions">{...}</Area>
      </>
    )}
  </Composition>
)

Area name is a suggestion. It can be Render, or anything else.

Benefits

• No namespace collision between custom namespaces and areas components.
• Retaining Composition context, as the default Area component is exposed and rendered within the respective parent Composition component.

Drawbacks

• The namespace of a default generic Area component is always taken, meaning you cannot have your custom area named areas="area".
• Area namespace may also overlap with other custom namespaces, however this chance is rather small and would be an edge case

How about <Area.Logo></Area.Logo> typescript autocomplete potential?