Proposal: ComponentsProvider for Link components

[thomasdigby]

Open to comments/suggestions.

This new provider would allow the component library to render React Router or Next.js Link in place of a. We currently use NavigateHandler to mimic the SPA behaviour in atom-core, but there are a few weird edge-cases and bugs that can only really be resolved by using Link components directly. This context layer allows any @atom-learning/components component to access the "Link", and we can still combine that internally with logic for internal/external URLs and rendering a or Link.

I named it ComponentsProvider as I wanted it to be fairly generic and we don't really have a name for our component library. Very happy to rename, tweak the structure, props, etc.

Atom core

import { Link } from 'react-router-dom'
import { ComponentsProvider } from '@atom-learning/components'

const Providers = ({ children }) => (
  <ComponentsProvider Link={({ href, ...props }) => <Link to={href} {...props} />}>
    {/* Other Providers */}
    {children}
  </ComponentsProvider>
)

Marketing site

import RouterLink from 'next/link'
import { ComponentsProvider } from '@atom-learning/components'

const Providers = ({ children }) => (
  <ComponentsProvider Link={RouterLink}>
    {/* Other Providers */}
    {children}
  </ComponentsProvider>
)

[thomasdigby]

@miaambt Tagging you if you have any q's about integration with Next.js router

[andoulla]

Open to comments/suggestions.

This new provider would allow the component library to render React Router or Next.js Link in place of a. We currently use NavigateHandler to mimic the SPA behaviour in atom-core, but there are a few weird edge-cases and bugs that can only really be resolved by using Link components directly. This context layer allows any @atom-learning/components component to access the "Link", and we can still combine that internally with logic for internal/external URLs and rendering a or Link.

I named it ComponentsProvider as I wanted it to be fairly generic and we don't really have a name for our component library. Very happy to rename, tweak the structure, props, etc.

import { Link } from 'react-router-dom'
import { ComponentsProvider } from '@atom-learning/components'

const Providers = ({ children }) => (
  <ComponentsProvider value={{ Link: ({ href, ...props }) => <Link to={href} {...props} /> }}>
    {/* Other Providers */}
    {children}
  </ComponentsProvider>
)

I have a few questions:

• Will we need to add this component at the app-base level, or next to each link, do we need to use the react-router link? What is the advice there?
• I'm wondering if this will affect any of the unit-tests in core as it might make mocking difficult (however we could do it in the new customRender that Marty created)

[thomasdigby]

Open to comments/suggestions.
This new provider would allow the component library to render React Router or Next.js Link in place of a. We currently use NavigateHandler to mimic the SPA behaviour in atom-core, but there are a few weird edge-cases and bugs that can only really be resolved by using Link components directly. This context layer allows any @atom-learning/components component to access the "Link", and we can still combine that internally with logic for internal/external URLs and rendering a or Link.
I named it ComponentsProvider as I wanted it to be fairly generic and we don't really have a name for our component library. Very happy to rename, tweak the structure, props, etc.

import { Link } from 'react-router-dom'
import { ComponentsProvider } from '@atom-learning/components'

const Providers = ({ children }) => (
  <ComponentsProvider value={{ Link: ({ href, ...props }) => <Link to={href} {...props} /> }}>
    {/* Other Providers */}
    {children}
  </ComponentsProvider>
)

I have a few questions:

* Will we need to add this component at the app-base level, or next to each link, do we need to use the react-router link? What is the advice there?

* I'm wondering if this will affect any of the unit-tests in core as it might make mocking difficult (however we could do it in the new customRender that Marty created)

It will just be a single provider, which we can just replace in the existing slot that the NavigateHandler currently lives in. Everything else stays the same. You keep using <Link /> and <Button /> from @atom-learning/components.

The unit tests in core should be unaffected as we'll be rendering this in the test-providers.