Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define pattern for breadcrumbs/history in Page #672

Open
chris-at-jobber opened this issue Sep 21, 2021 · 1 comment
Open

Define pattern for breadcrumbs/history in Page #672

chris-at-jobber opened this issue Sep 21, 2021 · 1 comment

Comments

@chris-at-jobber
Copy link
Contributor

chris-at-jobber commented Sep 21, 2021

A few one-off instances of "back button" breadcrumbs have been used alongside Page - a good indicator that it's time to incorporate this mechanism into the component itself, so end users can just use the pattern without having to solve it themselves.

An initial idea explored in a since-closed exploratory PR was to add a single small tertiary button that would simply jump the user up one level in the hierarchy of the application. For example, if you were looking at something like...

settings/notifications

the Back button would return you to

settings.

image

Outstanding Questions

Some other considerations that we would want to resolve (thanks @joelwarrington-jobber!) are:

Multi-level breadcrumbs

If multi-level breadcrumbs were to be a possibility, we could make it so that the breadcrumb type is an array, if the length is 1, use the button style and then some other type of style for multiple?

Additional properties

For added flexibility, would we be able to have 2 additional properties of a breadcrumb?

interface breadcrumb {
  label: string;
  /* Default = "../" */
  url?: string;
  onClick?(): void;
}

If the onClick property is passed, the url is ignored

History vs hierarchy

Do we need to account for the user's X recently-visited views in the breadcrumbs, rather than the application hierarchy? Is that the responsibility of a breadcrumb? E.g. in the above use case of being on a specific settings view...

History could look something like:

home / schedule / invoices ➡️ Notifications Settings (maybe there's a prompt on that view to adjust your invoicing notifications)

Hierarchy would look like:

settings ➡️ Notifications Settings

Does this need to be something that Page is even responsible for? (Could/should end-users configure Page to their needs?)

@joelzwarrington
Copy link
Contributor

@chris-at-jobber I'm open to working on this but am wondering what can be done to define the pattern. Is there are particular thoughts you have on the approach we should take or who we should consult?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

2 participants