Skip to content
This repository has been archived by the owner on May 24, 2024. It is now read-only.

Dialog - Add Theme and ActionHeader #1209

Merged
merged 25 commits into from
Feb 12, 2018
Merged

Conversation

saedar
Copy link
Contributor

@saedar saedar commented Feb 5, 2018

Resolves: #1157

Summary

Dialog has been updated to consume ActionHeader. I have also added theme variables to Dialog, Modal, and ModalOverlay.

Deployment URL

https://terra-core-deployed-pr-1209.herokuapp.com/static/#/site/dialog

I also updated Dialog to use subcomponents for body and footer. Since I am having to pass the header/footer/body content to ContentContainer via props, I was unsure if how I have it currently working is the best approach. If not, I welcome tips on a better path.

EDIT: Subcomponent implementation has been removed for simplicity.

@cerner/terra

@saedar saedar self-assigned this Feb 5, 2018
@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 5, 2018 20:01 Inactive
```

Note: This component has an i18n dependency that requires setup per [these steps](https://github.com/cerner/terra-core/#internationalization-i18n).
Copy link
Contributor Author

Choose a reason for hiding this comment

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

When trying to get ActionHeader working, I ran into issues because I didn't realize the need for Base as an ancestor. I wanted to include a link and brief description here to help future consumers avoid this confusion, too. Any tips on better wording appreciated.

expect(wrapper).toMatchSnapshot();
});

it('should render header & footer', () => {
Copy link
Contributor Author

Choose a reason for hiding this comment

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

Talked with Neal and Brett last week. Footer is required, so don't need the special test cases with and without.

@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 5, 2018 20:06 Inactive
@@ -13,9 +13,22 @@ Dialogs are temporary views that can be used in a myriad of ways. Dialogs have t
import React from 'react';
import Dialog from 'terra-dialog';

<Dialog header="Header Content" footer="Footer Content">some body content</Dialog>
const header = 'Header Content';

Copy link
Contributor

Choose a reason for hiding this comment

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

It'd be great if we can get this API consistent. Ex: Since header doesn't require a wrapper, do we need them for body and footer?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I suppose it depends on what you mean by "need." I didn't create one for header because ActionHeader is already the wrapper.

The wrappers were suggested by Brett, so I will discuss this with him when he gets in.

Copy link
Contributor

Choose a reason for hiding this comment

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

I'm thinking put the wrappers inside the Dialog, and the content will just populate the wrappers in the dialog.

Copy link
Contributor

Choose a reason for hiding this comment

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

Yeah, thinking on this some more that makes sense. For the dialog subcomponets, like<Dialog.Body>, these will switch to an internal implementation. Likely <div className={dialogBodyClasses}>{dialogBody}</div>

Copy link
Contributor Author

Choose a reason for hiding this comment

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

* The footer element to be placed within the footer area of the dialog.
* The footer content area will not display if this prop is not provided. UNDER EVALUATION
*/
footer: PropTypes.node.isRequired,
Copy link
Contributor

Choose a reason for hiding this comment

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

Remove the isRequired part, since it doesn't sound like it's required.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Actually, I forgot to update the doc. The footer is required now.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

footer: PropTypes.node.isRequired,
/**
* The children to be placed within the main content area of the dialog.
*/
children: PropTypes.node.isRequired,
Copy link
Contributor

Choose a reason for hiding this comment

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

I'd make this optional as well to be honest.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

What is a dialog with no content? Seems...wrong.

Copy link
Contributor

Choose a reason for hiding this comment

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

It does and I'm sure it's an unlikely case, but it's still an edge case that I'd feel safer having than not. I know for table cells that api is a little confusing in that you can't have an empty table cell.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I don't know. That seems like a different situation, in that an empty table cell feels appropriate. That signifies "No data point" rather than "No content".

Copy link
Contributor

Choose a reason for hiding this comment

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

I can't think of a case where we'd have a model without children content. Thats's not to say its not a valid case, but I think we can move forward with this as-is. If we come across the use-case, we'll re-evaluate.

Copy link
Contributor

Choose a reason for hiding this comment

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

But if a developer passes in null or no children, does it change the display logic of the component? If the dialog can't display if this is null or empty, I'm fine leaving it as required. However, it the dialog handles fine with null or empty children, I still vote to drop the isRequired off this prop. It doesn't change our implementation logic, but still allows for our API to handle that edge case.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

This conversation is dumb and not important. I have removed the required flag because the impact in either direction is minimal and not worth the effort already invested in the discussion.

74c002d

};

const Dialog = ({ header, footer, children }) => {
const defaultProps = {
header: null,
Copy link
Contributor

Choose a reason for hiding this comment

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

Anything required doesn't need a defaultProp I believe.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@@ -3,4 +3,19 @@
height: 100%;
width: 100%;
}

.header { // May not be needed if action header is already themeable.
Copy link
Contributor

Choose a reason for hiding this comment

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

In my opinion, I would still theme it. Terra-time-input had to apply individual styles to all of it's buttons and inputs so that it would all be aligned with each other.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

}

.dialog-body {
background-color: var(--terra-dialog-body-background-color, transparent);
Copy link
Contributor

Choose a reason for hiding this comment

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

How about the foreground? Typically, when you set a background, you also need to set a foreground. Or will that be handled by another component?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

]);

return (
<div className={DialogBodyClassNames}>
Copy link
Contributor

Choose a reason for hiding this comment

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

we should probably still provide the support for custom props on this component.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

import React from 'react';
import Dialog from 'terra-dialog';

const header = <span>Header Stuff</span>;
const header = 'Header Stuff';
Copy link
Contributor

Choose a reason for hiding this comment

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

If it's possible, it would be better if we allowed this to take in react nodes as well. With react nodes, you can build components that easily let you opt in and out of overflowing text

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can't. This gets passed into ActionHeader, which requires String.

const body = (<Dialog.Body>
<p>This is my body content.</p>
<p>This is some more content.</p>
</Dialog.Body>);

const DialogDefault = () => (
<div style={{ height: '200px', width: '350px', border: 'dashed' }}>
Copy link
Contributor

Choose a reason for hiding this comment

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

Given how large this hash is, I think it's best to extract it to a CSS file. Also, should the border be themeable? @neilpfeiffer

Copy link
Contributor

Choose a reason for hiding this comment

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

Disregard. This is an example page.

@@ -32,6 +32,7 @@
"classnames": "^2.2.5",
"prop-types": "^15.5.8",
"terra-base": "^2.0.0",
"terra-clinical-action-header": "^1.6.0",
Copy link
Contributor

Choose a reason for hiding this comment

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

Talked with @mjhenkes on this some, and we believe that it might be ideal to move action header to the core repository. terra-core was the building blocks for repos such as terra-clinical and terra-consumer, so it feels like a circular dependency when terra-core relies on stuff set inside one of the repos that extend off of this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Talked in Scrum. Current decision is to move forward with this review and add themes to the component in Clinical. Later, we are going to evaluate deprecating the clinical ActionHeader and including a new one in core.

};

const DialogBody = ({ children }) => {
const DialogBodyClassNames = cx([
Copy link
Contributor

Choose a reason for hiding this comment

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

This variable should probably be camelCase

Copy link
Contributor Author

@saedar saedar Feb 6, 2018

Choose a reason for hiding this comment

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

2fabef8

EDIT: The was actually a file I missed. Running tests now, but will update with proper commit in a bit.

EDIT 2: 92cd4ef

@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 6, 2018 20:21 Inactive
@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 7, 2018 15:24 Inactive
@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 8, 2018 18:08 Inactive
@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 8, 2018 20:05 Inactive
background-color: #fff;
border-radius: 5px;
background-color: var(--terra-modal-background-color, #fff);
border: var(--terra-modal-border, none);
Copy link
Contributor

Choose a reason for hiding this comment

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

If there is no property value for default theme, lets drop the fallback value for these theming properties.

e.g. switch border: var(--terra-modal-border, none); to border: var(--terra-modal-border);

Looks like this can be done for the following

  • border
  • box-shadow
  • color
  • height
  • margin
  • max-width
  • width

Copy link
Contributor Author

Choose a reason for hiding this comment

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

@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 9, 2018 15:04 Inactive
Copy link
Contributor

@JakeLaCombe JakeLaCombe left a comment

Choose a reason for hiding this comment

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

Looks good. My only last request is to see if we can reduce the size of those screenshots possibly. toMatchScreenshot can take a screenshot for a given selector, which we could probably get from the dialog wrapper.

@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 9, 2018 21:06 Inactive
@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 9, 2018 21:10 Inactive
@mmalaker
Copy link

mmalaker commented Feb 9, 2018

Functional verification completed. The dialog examples display and function correctly with the action header changes applied.

@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 9, 2018 23:10 Inactive
.dialog-header {
background-color: var(--terra-dialog-header-background-color, transparent);
border-bottom: var(--terra-dialog-header-bottom-border, none);
color: var(--terra-dialog-header-foreground-color, #000);
Copy link
Member

@neilpfeiffer neilpfeiffer Feb 12, 2018

Choose a reason for hiding this comment

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

@saedar - Minor color updates:

.dialog-header {
   color: var(--terra-dialog-header-foreground-color, #1c1f21);
}
.dialog-body {
   color: var(--terra-dialog-body-foreground-color, #1c1f21);
}
.dialog-footer {
   border-top: var(--terra-dialog-footer-bottom-top, 1px solid #dedfe0);
   color: var(--terra-dialog-footer-foreground-color, #1c1f21);
}

@neilpfeiffer
Copy link
Member

Tested: PR #1209
Resolves: Issue #1157 #416


Reviewed:

  • Follows pattern considerations documented in Cerner Design Standards: Dialogs
  • Follows UX defined design implementation for Terra-Dialog
  • Follows defined theme designs: terra-theme


Future Enhancments:

  • Action header will be uplifted to universal design in the future
  • Action footer will be created with universal design in the future


Verified by @scottwilmarth and @neilpfeiffer, Ready for Release after color updates.

Pass
UX Review

@bjankord bjankord temporarily deployed to terra-core-deployed-pr-1209 February 12, 2018 17:31 Inactive
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants