Skip to content

PageHeader allow title to wrap instead of overflow #6296

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 7 commits into from
Sep 7, 2022
Merged

PageHeader allow title to wrap instead of overflow #6296

merged 7 commits into from
Sep 7, 2022

Conversation

halocline
Copy link
Collaborator

@halocline halocline commented Aug 23, 2022 •
edited
Loading

What does this PR do?

Closes #6295 by:

  • Adds overflowWrap prop to Heading which accepts any valid overflow-wrap CSS.
  • Updates PageHeader implementation to wrap instead of overflow.

Also, for backwards compatibility, ensures Calendar Header overflows instead of wrapping which is its current behavior.

Where should the reviewer start?

Heading.js

What testing has been done on this PR?

Jest suite, Storybook, plus added snapshot test.

How should this be manually tested?

Lengthy word(s) within Heading and PageHeader.

<Heading>bluevelvet.aixncc.ig.acmecorp.com</Heading>
<Heading overflowWrap="break-word">
    bluevelvet.aixncc.ig.acmecorp.com
</Heading>
<PageHeader>
    title="bluevelvet.aixncc.ig.acmecorp.com"
    actions={[<Button label="click me" />]}
/>

Do Jest tests follow these best practices?

  • screen is used for querying.
  • The correct query is used. (Refer to this list of queries)
  • userEvent is used in place of fireEvent.
  • asFragment() is used for snapshot testing.

Any background context you want to provide?

What are the relevant issues?

#6295

Screenshots (if appropriate)

Screen Shot 2022-08-23 at 2 14 17 PM

Screen Shot 2022-08-23 at 2 15 14 PM

Do the grommet docs need to be updated?

No. Proposing the overflowWrap be internal only and undocumented for now unless others feel like it would be valuable to document.

Should this PR be mentioned in the release notes?

Yes.

Is this change backwards compatible or is it a breaking change?

Backwards compatible.

@halocline halocline requested a review from taysea August 23, 2022 20:14
taysea
taysea approved these changes Aug 23, 2022
View reviewed changes
Copy link
Collaborator

@taysea taysea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM!

@taysea taysea requested a review from ericsoderberghp August 23, 2022 20:35
@halocline halocline mentioned this pull request Aug 23, 2022
Merged
@ericsoderberghp
Copy link
Contributor

I'm wondering if we should always have a wrap. Is there ever a rationale to not break at all? Could we default to break-word and detect if this isn't enough and automatically switch to anywhere? That way the caller doesn't have to do anything, since it could be difficult to predict which one to use since it might depend on translations, user data, and resolution.

@halocline
Copy link
Collaborator Author

I'm wondering if we should always have a wrap. Is there ever a rationale to not break at all?

I having a hard time coming up with a rationale, and definitely not one that wouldn't be an edge case. If there were one, the caller would have overflowWrap="normal" or truncate as options.

Could we default to break-word and detect if this isn't enough and automatically switch to anywhere? That way the caller doesn't have to do anything, since it could be difficult to predict which one to use since it might depend on translations, user data, and resolution.

I would be okay with defaulting to break-word. What's the mechanism for detecting where break-word is not enough?

@ericsoderberghp
Copy link
Contributor

I'm wondering if we should always have a wrap. Is there ever a rationale to not break at all?

I having a hard time coming up with a rationale, and definitely not one that wouldn't be an edge case. If there were one, the caller would have overflowWrap="normal" or truncate as options.

This seems infrequent enough to me to not need to formalize it as a property.

Could we default to break-word and detect if this isn't enough and automatically switch to anywhere? That way the caller doesn't have to do anything, since it could be difficult to predict which one to use since it might depend on translations, user data, and resolution.

I would be okay with defaulting to break-word. What's the mechanism for detecting where break-word is not enough?

I was envisioning comparing offset width and scroll width in some manner.

ericsoderberghp
ericsoderberghp previously approved these changes Sep 2, 2022
View reviewed changes
@ericsoderberghp
Copy link
Contributor

This seems like a notable regression

Screen Shot 2022-09-02 at 2 50 46 PM

@ericsoderberghp ericsoderberghp dismissed their stale review September 2, 2022 21:51

Calendar heading regression

@halocline halocline requested a review from taysea September 7, 2022 21:59
taysea
taysea approved these changes Sep 7, 2022
View reviewed changes
Copy link
Collaborator

@taysea taysea left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM! Thanks for fixing the calendar one.

@halocline
Copy link
Collaborator Author

This seems like a notable regression

Screen Shot 2022-09-02 at 2 50 46 PM

Addressed. Set Calendar Heading to use overflowWrap="normal" for backwards compatibility.

@ericsoderberghp ericsoderberghp merged commit 7fb15ff into grommet:master Sep 7, 2022
@halocline halocline deleted the heading-wordbreak branch September 7, 2022 22:52
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@taysea taysea taysea approved these changes

+1 more reviewer

@ericsoderberghp ericsoderberghp ericsoderberghp approved these changes

Reviewers whose approvals may not affect merge requirements
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.

PageHeader heading with long string overflows rather than breaking
3 participants
@halocline @ericsoderberghp @taysea