fix(asinput): Add danger theme to asInput component #91

MichaelRoytman · 2017-12-05T20:17:53Z

Add danger theme to asInput component to add alert icon, red text for validation message, and red border to input element

coveralls · 2017-12-05T20:44:52Z

Coverage increased (+0.005%) to 99.515% when pulling 529cd3b on mroytman/asInput-danger-theme into 57c13c4 on master.

MichaelRoytman · 2017-12-05T20:46:05Z

src/asInput/index.jsx

-              ...this.props.className,
-            ]}
+              styles['form-inline'],
+              { [styles['is-invalid']]: !this.state.isValid && this.props.theme.includes('danger') },


I have no strong feelings about this theme's name. Any opinions?

My only thought is that if we ever want to add additional styling in the future whenever !this.state.isValid (like always making the background color red or something) we'd probably want to name that style is-invalid, right?

But even if we have to rename this class it won't be a breaking change (right?), so I don't think it's a big deal either way.

MichaelRoytman · 2017-12-05T20:51:39Z

src/asInput/index.jsx

-          <div className={styles['form-control-feedback']} id={errorId} key="0">
-            {this.state.validationMessage}
+
+          <div className={classNames(styles['form-control-feedback'], { [styles['invalid-feedback']]: this.props.theme.includes('danger') })} id={errorId} key="0">


I can pull out the this.props.theme.includes('danger') condition into a variable, as the condition is being used twice here, but I was interested to see whether it would be an issue as we add more themes. Is the idea that, as we add more themes, we conditionally apply classnames this way? I'll add a 'hasDangerTheme' variable if this looks good to everyone, otherwise.

MichaelRoytman · 2017-12-05T20:53:23Z

src/asInput/index.jsx

+
+          <div className={classNames(styles['form-control-feedback'], { [styles['invalid-feedback']]: this.props.theme.includes('danger') })} id={errorId} key="0">
+            { this.props.theme.includes('danger') &&
+            <span


This is an alert icon, which follows UI/UX guidelines laid out here.

MichaelRoytman · 2017-12-05T20:53:50Z

src/asInput/index.jsx

@@ -89,15 +101,17 @@ const asInput = (WrappedComponent, labelFirst = true) => {
    render() {
      const { description, error, describedBy } = this.getDescriptions();
      return (
-        <div className={styles['form-group']}>
+        <div className={classNames(styles['form-group'])}>


Any harm in adding classNames?

I don't think there is any harm, but why do you think it is useful here if there are no class names to join?

Ah, my bad. I had added class names and then removed them. I'll switch it back.

coveralls · 2017-12-05T21:18:38Z

Coverage increased (+0.006%) to 99.516% when pulling 9993c2b on mroytman/asInput-danger-theme into 57c13c4 on master.

MichaelRoytman · 2017-12-05T21:27:30Z

I'd be interested in thoughts about this "theme". It's a solution we discussed when considering the modal and styling that studio-frontend needed for the modal, but I haven't gotten around to it because of the accessibility form. Does this look like what was envisioned? I tried to use a similar rationale for this asInput theme.

P.S. If anyone has the bandwidth, it would be great to get this merged soon, since it's needed for the Studio accessibility form that's due by December 12th (although we wanted to get it pushed out by mid-day Friday).

jaebradley · 2017-12-06T14:31:28Z

src/asInput/index.jsx

@@ -22,6 +24,7 @@ export const inputProps = {
  onBlur: PropTypes.func,
  validator: PropTypes.func,
  className: PropTypes.arrayOf(PropTypes.string),
+  theme: PropTypes.arrayOf(PropTypes.string),


Naming nit: if this is an array of strings should this be called themes instead?

Good catch!

jaebradley · 2017-12-06T14:37:52Z

src/asInput/index.jsx

@@ -49,9 +52,20 @@ const asInput = (WrappedComponent, labelFirst = true) => {
      const desc = {};

      if (!this.state.isValid) {
+        const hasDangerTheme = this.props.theme.includes('danger');


Since the this.props.theme.includes('danger') check is implemented in getDescriptions and render you could consider moving this to it's own helper method and that way if you ever have to adjust it / add a theme value, you can do it in one place instead of having to remember to do it in two places.

coveralls · 2017-12-06T16:35:23Z

Coverage increased (+0.007%) to 99.522% when pulling da6ab3e on mroytman/asInput-danger-theme into 1d25dfc on master.

jaebradley

@MichaelRoytman this looks good - let's hold off merging until @arizzitano takes a look?

I know there is a bit of a time component here but I want to throw something out there:

There's a great post on Medium about lessons learned from doing code reviews. One of the lessons is to not use strings when another type should be used (an enum or a UUID) - this is obviously more applicable for something like Java vs. Javascript. Here's the author's example gist.

There are two points to all of this:

That the themes prop seems to be more like an enum? Like we could have a themes enum in a constants.js where you can pick and choose the themes you want to apply via an interface like <Component... themes={[Theme.DANGER, Theme.UNDERLINE]} />. I know this may seem like a lot of (potentially unnecessary) overhead, but I think it makes the API more accurate. It could also allows us to implement better prop type checking / demonstrate the intention of the themes prop by specifying a specific enum / class vs. PropType.string.
It feels like we're trying to conflate two ideas - this idea of theming, and then this idea of supporting custom class names. They seem (and obviously are) coupled together - I can't tell if this will lead to some pitfall in the future, nor do I know what the right solution is right now, but I'm generally paranoid of exposing two API points that change the same piece of data (in this case, the component's class).

Edit: The more I think about the second point the less I'm worried - I think this is fine for now.

dsjen · 2017-12-06T18:18:01Z

@arizzitano -- do you want to take a look? We are under time pressure, and if you intend to look at this, we'd appreciate if you could do so at your earliest convenience so that we can wire everything up.

arizzitano

🚢 this looks fine for now -- the enum vs. string concerns are probably not a big deal since the danger theme is only being used in this one place. If we want to change it we can circle back later.

jaebradley · 2017-12-06T18:59:23Z

@MichaelRoytman @dsjen hold on, I'm investigating if style will bump the version - regardless, I'm not sure this is a style anyways. This feels like a fix since you're adding functionality.

Update: here are the default release rules used by semantic-release

{type: 'feat', release: 'minor'},
{type: 'fix', release: 'patch'},
{type: 'perf', release: 'patch'},

Since style is not on that list of release rules there will be no release tag associated with them, which means no new NPM version will be published.

jaebradley

I think the commit message should be fix(asinput): Add danger theme to asInput component - this will guarantee that a new version of Paragon will be published to NPM (and thus, Studio can incorporate the changes).

Add danger theme to asInput component to add alert icon, red text for validation message, and red border to input element

jaebradley

After updating the commit message with @fysheets, I think this is ready to merge after the build succeeds.

coveralls · 2017-12-06T21:10:39Z

Coverage increased (+0.007%) to 99.522% when pulling d545540 on mroytman/asInput-danger-theme into 1d25dfc on master.

coveralls · 2017-12-06T21:10:39Z

Coverage increased (+0.005%) to 99.515% when pulling 529cd3b on mroytman/asInput-danger-theme into 57c13c4 on master.

MichaelRoytman added the work in progress label Dec 5, 2017

MichaelRoytman commented Dec 5, 2017

View reviewed changes

MichaelRoytman added ready for review and removed work in progress labels Dec 5, 2017

jaebradley reviewed Dec 6, 2017

View reviewed changes

MichaelRoytman force-pushed the mroytman/asInput-danger-theme branch from 9993c2b to da6ab3e Compare December 6, 2017 16:31

jaebradley approved these changes Dec 6, 2017

View reviewed changes

arizzitano approved these changes Dec 6, 2017

View reviewed changes

jaebradley suggested changes Dec 6, 2017

View reviewed changes

fix(asinput): Add danger theme to asInput component

d545540

Add danger theme to asInput component to add alert icon, red text for validation message, and red border to input element

jaebradley force-pushed the mroytman/asInput-danger-theme branch from da6ab3e to d545540 Compare December 6, 2017 21:06

jaebradley changed the title ~~style(asinput): Add danger theme to asInput component~~ fix(asinput): Add danger theme to asInput component Dec 6, 2017

jaebradley approved these changes Dec 6, 2017

View reviewed changes

jaebradley merged commit 4f253ff into master Dec 6, 2017

jaebradley deleted the mroytman/asInput-danger-theme branch December 6, 2017 21:10

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

fix(asinput): Add danger theme to asInput component #91

fix(asinput): Add danger theme to asInput component #91

MichaelRoytman commented Dec 5, 2017

coveralls commented Dec 5, 2017 •

edited

Loading

MichaelRoytman Dec 5, 2017

jaebradley Dec 6, 2017

MichaelRoytman Dec 5, 2017

MichaelRoytman Dec 5, 2017

MichaelRoytman Dec 5, 2017

jaebradley Dec 6, 2017

MichaelRoytman Dec 6, 2017

coveralls commented Dec 5, 2017 •

edited

Loading

MichaelRoytman commented Dec 5, 2017 •

edited

Loading

jaebradley Dec 6, 2017 •

edited

Loading

MichaelRoytman Dec 6, 2017

jaebradley Dec 6, 2017

coveralls commented Dec 6, 2017 •

edited

Loading

jaebradley left a comment •

edited

Loading

dsjen commented Dec 6, 2017

arizzitano left a comment

jaebradley commented Dec 6, 2017 •

edited

Loading

jaebradley left a comment

jaebradley left a comment

coveralls commented Dec 6, 2017

coveralls commented Dec 6, 2017 •

edited

Loading

fix(asinput): Add danger theme to asInput component #91

fix(asinput): Add danger theme to asInput component #91

Conversation

MichaelRoytman commented Dec 5, 2017

coveralls commented Dec 5, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Dec 5, 2017 • edited Loading

MichaelRoytman commented Dec 5, 2017 • edited Loading

jaebradley Dec 6, 2017 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

coveralls commented Dec 6, 2017 • edited Loading

jaebradley left a comment • edited Loading

Choose a reason for hiding this comment

dsjen commented Dec 6, 2017

arizzitano left a comment

Choose a reason for hiding this comment

jaebradley commented Dec 6, 2017 • edited Loading

jaebradley left a comment

Choose a reason for hiding this comment

jaebradley left a comment

Choose a reason for hiding this comment

coveralls commented Dec 6, 2017

coveralls commented Dec 6, 2017 • edited Loading

coveralls commented Dec 5, 2017 •

edited

Loading

coveralls commented Dec 5, 2017 •

edited

Loading

MichaelRoytman commented Dec 5, 2017 •

edited

Loading

jaebradley Dec 6, 2017 •

edited

Loading

coveralls commented Dec 6, 2017 •

edited

Loading

jaebradley left a comment •

edited

Loading

jaebradley commented Dec 6, 2017 •

edited

Loading

coveralls commented Dec 6, 2017 •

edited

Loading