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

Add responsiveColumn option to type of EuiDescriptionList #2166

Merged
merged 5 commits into from
Jul 26, 2019

Conversation

cchaos
Copy link
Contributor

@cchaos cchaos commented Jul 25, 2019

This was brought up in Kibana where the content dictated needing to switch from column to row layout on small screens.

This does that automatically so that consumers don't have to write the logic for it.

Checklist

  • This was checked in mobile
  • This was checked in IE11
  • [ ] This was checked in dark mode
  • Any props added have proper autodocs
  • Documentation examples were added
  • A changelog entry exists and is marked appropriately
  • [ ] This was checked for breaking changes and labeled appropriately
  • Jest tests were updated or added to match the most common scenarios
  • [ ] This was checked against keyboard-only and screenreader scenarios
  • [ ] This required updates to Framer X components

@snide
Copy link
Contributor

snide commented Jul 25, 2019

Before I look to deep at this. Any reason why we wouldn't just do this by default for type="column" without needing the prop? I assume using the responsive prop on type="row" doesn't do anything? I ask because if it's set to false by default, it likely wouldn't get used often by consumers? Feel like having it go from column to row makes sense all the time so the prop might not be needed?

@cchaos
Copy link
Contributor Author

cchaos commented Jul 25, 2019

I dont think that's necessarily true that columns should by default switch to rows. I think a very common scenario of usage is that the content is small enough that (couple words in each column) they display fine as they are on small screens. These don't tend to be big block level layouts like EuiFlexGroup. It's just text.

Copy link
Contributor

@thompsongl thompsongl left a comment

Choose a reason for hiding this comment

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

A couple doc suggestions. I'd be good with the code changes provided we keep with the current concept (i.e., not use Dave's suggestions).

Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

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

Maybe better idea? I'm mostly trying to avoid this.

image

/**
* Turns a column layout into normal row layout on small screens
*/
responsive?: boolean;
Copy link
Contributor

@snide snide Jul 26, 2019

Choose a reason for hiding this comment

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

That's a good point. How about we make a new type rather than adding the boolean then?type="responsiveColumn"

Sorry. I just really like to avoid conditional acting props because it's hard as a consumer to know how they actually change things without digging deep into the docs. Right now responsive really only changes this component if it happens to be type="column". It does nothing on row or inline. So to me, this is just a different type, not an additive property. Downside of course is if you end up adding a new type down the line where you always want to have a similar split nature, you're then adding something again, but we haven't really touched this one much over the years.

If responsive={true} by default i'd maybe think different, but if you have to go and hand touch these to turn it on anyway?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

It was more that I was trying to align the prop name/type with how we use it elsewhere. I agree that it does nothing to other display types and can create those dead selectors as you say. I don't really feel strongly either way, but I can change it to your suggestion and see how the component continues to develop (if at all). It could also a be a good test case for this way of adding responsive options.

Copy link
Contributor

Choose a reason for hiding this comment

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

You can make the call because I can see your side of it too. If you do go with the responsive prop I'd at least make the check to only apply that class when both values match. Then at least the dom output is a little cleaner.

@cchaos cchaos requested review from snide and thompsongl July 26, 2019 15:16
Copy link
Contributor

@snide snide left a comment

Choose a reason for hiding this comment

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

Thanks!

Copy link
Contributor

@thompsongl thompsongl left a comment

Choose a reason for hiding this comment

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

👍 for creating a new type. Tested locally. Changes LGTM

@cchaos cchaos changed the title Add responsive prop to EuiDescriptionList Add responsiveColumn option to type prop of EuiDescriptionList Jul 26, 2019
@cchaos cchaos changed the title Add responsiveColumn option to type prop of EuiDescriptionList Add responsiveColumn option to type prop of EuiDescriptionList Jul 26, 2019
@cchaos cchaos changed the title Add responsiveColumn option to type prop of EuiDescriptionList Add responsiveColumn option to type of EuiDescriptionList Jul 26, 2019
@cchaos cchaos merged commit 63a4b66 into elastic:master Jul 26, 2019
@cchaos cchaos deleted the responsive-description-list branch July 26, 2019 20:08
thompsongl pushed a commit to thompsongl/eui that referenced this pull request Sep 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants