Change Breadcrumbs to accept a single breadcrumb instead of an array

[itwasmattgregg]

WHY are these changes introduced?

Breadcrumbs has only been using a single breadcrumb for a while now. Instead of allowing consumers to pass an array without knowing why only a single link is being used, we should remove the ability to pass an array and make the component easier to understand implicitly.

WHAT is this pull request doing?

UI will not change. The Breadcrumbs component was already only using the last breadcrumb link in the array.

This PR changes the props for breadcrumbs and also the implementation on the Page component.

Migration path

Since this PR removes the breadcrumbs[] prop in favor of breadcrumb all uses of Page, and Breadcrumbs will need to be migrated.

It will look something like this:

//before
const breadcrumbs = [
      {
        content: 'Products',
        url: 'http://test.com',
      },
];
<Page {...mockProps} breadcrumbs={breadcrumbs} />

//after
const breadcrumb = {
  content: 'Products',
  url: 'http://test.com',
};
<Page {...mockProps} breadcrumb={breadcrumb} />

How to 🎩

Check the Breadcrumbs and Page components in storybook

🎩 checklist

• Tested on mobile
• Tested on multiple browsers
• Tested for accessibility
• Updated the component's README.md with documentation changes
• Tophatted documentation changes in the style guide

[github-actions]

size-limit report 📦

Path	Size
polaris-react-cjs	211.33 KB (-0.01% 🔽)
polaris-react-esm	136.47 KB (-0.02% 🔽)
polaris-react-esnext	191.69 KB (-0.02% 🔽)
polaris-react-css	41.76 KB (0%)

[itwasmattgregg]

Not sure how to fix the linting errors.

[kyledurand]

Not sure how to fix the linting errors.

/home/runner/work/polaris/polaris/polaris-react/src/components/Collapsible/Collapsible.tsx
@shopify/polaris:lint: 26:3 error 'preventMeasuringOnChildrenUpdate

This probably snuck back into this branch from me updating earlier today.

If you update v11-major locally and rebase this branch against it then push it back up you should be good

[alex-page]

@itwasmattgregg would you consider creating a migration for this work? We have a migration package and it would help Polaris developers onboard to the breaking change.

[itwasmattgregg]

@itwasmattgregg would you consider creating a migration for this work? We have a migration package and it would help Polaris developers onboard to the breaking change.

I can try for sure. Haven't written one before. Is that a separate PR? @alex-page

[alex-page]

@itwasmattgregg I would make another PR. We have a bunch of documentation/examples here https://github.com/Shopify/polaris/tree/main/polaris-migrator

[BPScott]

When introducing a breaking change, aim to introduce the new approach in minor version, so that people can gradually adopt the new approach rather than it having perform the migration to the new approach in the major update PR.

What do you think to splitting this into two PRs:

• A PR against the main branch that allows consumers to specify breadcrumbs as an array or a single object
• A PR against the v11 branch that removes the ability to specify breadcrumbs as an array.

Doing so would allow people to start using the single-object style immediately, and we can transition web to that style, prior to the v11 PR (whenever that appears)

[itwasmattgregg]

When introducing a breaking change, aim to introduce the new approach in minor version, so that people can gradually adopt the new approach rather than it having perform the migration to the new approach in the major update PR.

What do you think to splitting this into two PRs:

• A PR against the main branch that allows consumers to specify breadcrumbs as an array or a single object
• A PR against the v11 branch that removes the ability to specify breadcrumbs as an array.

Doing so would allow people to start using the single-object style immediately, and we can transition web to that style, prior to the v11 PR (whenever that appears)

There's not really a way to mark the array version as "deprecated" is there.

[alex-page]

There's not really a way to mark the array version as "deprecated" is there.

No need to mark a prop type as deprecated. This would make moving a big repo like shopify/web across to this change easier. We can do the heavy lifting without it all being in a giant PR of breaking changes.

[BPScott]

There's not really a way to mark the array version as "deprecated" is there.

Not that I can think of. You can mark a whole prop as deprecated,however adding a new prop with a new name and removing the old prop feels like overkill here. I think no deprecation notice for this is fine.