Skip to content
This repository was archived by the owner on Jun 24, 2021. It is now read-only.

Primary button, stylesheet restructure#20

Merged
bobheadxi merged 18 commits into
masterfrom
web/primary-button
Jul 14, 2018
Merged

Primary button, stylesheet restructure#20
bobheadxi merged 18 commits into
masterfrom
web/primary-button

Conversation

@bobheadxi

@bobheadxi bobheadxi commented Jul 10, 2018

Copy link
Copy Markdown
Contributor

👷 Changes

  • Primary button based on figma design
  • Moved frontendcomponents into demo
  • Reorganized button styles
  • Reorganized stylesheet imports
  • Color declarations in colors.sass - choose from these from now on!

Updated with disabled states

image

Updated with animated transitions

buttonanimatation

💭 Notes

For stylesheets, there should only be one import for general styles in index.js:

import React from 'react';
import ReactDOM from 'react-dom';

import App from './components/app/App';
import './styles/index.sass';

ReactDOM.render(<App />, document.getElementById('app'));

All other styles should be imported via styles/index.sass:

/* core */
@import ./colors
@import ./typography

/* components */
@import ../components/index

/* containers */
@import ../containers/index

etc etc.

🔦 Testing Instructions

make web

then go to http://localhost:8080/ui_demo

@coveralls

coveralls commented Jul 10, 2018

Copy link
Copy Markdown

Pull Request Test Coverage Report for Build 246

  • 5 of 10 (50.0%) changed or added relevant lines in 4 files are covered.
  • No unchanged relevant lines lost coverage.
  • Overall coverage increased (+31.02%) to 31.019%

Changes Missing Coverage Covered Lines Changed/Added Lines %
web/components/app/App.js 0 1 0.0%
web/components/demo/index.js 0 4 0.0%
Totals Coverage Status
Change from base Build 227: 31.02%
Covered Lines: 48
Relevant Lines: 172

💛 - Coveralls

@bobheadxi bobheadxi force-pushed the web/primary-button branch from 6a4ed2d to 3614956 Compare July 11, 2018 06:41
@bobheadxi bobheadxi force-pushed the web/primary-button branch from fb40068 to 890b3e1 Compare July 11, 2018 07:39
@bobheadxi bobheadxi mentioned this pull request Jul 11, 2018

@mingyokim mingyokim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Quick review for now - will complete review later

<button
onClick={onClick}
type="button"
className={`primary ${disabled ? 'disabled' : ''}`}>

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Can we disable buttons by doing <button disabled>Button</button> instead?
https://stackoverflow.com/questions/14750078/style-disabled-button-with-css

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

That's much cleaner thanks, addressed in 7b2f778

@sherryyx sherryyx left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

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

nice transition 🌹

@mingyokim mingyokim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I just noticed that PrimaryButton and SecondaryButton are basically the same except the class name. I think it’d be nice to refactor them into one component, and maybe pass in an additional prop like “type” that specifies whether the button is primary/secondary

@bobheadxi

bobheadxi commented Jul 12, 2018

Copy link
Copy Markdown
Contributor Author

@mingyokim

refactor them into one component, and maybe pass in an additional prop like “type” that specifies whether the button is primary/secondary

I think that's a pretty bad idea - having them be distinct classes is useful and is in line with how I've seen stateless React components being used (small, simple, occasionally very similar bits and pieces you can use elsewhere). If we pass a button type as a prop, we might as well forgo the React component entirely and just use a bare <button ... /> element when we need buttons, since we're assigning all the same properties anyway.

The more props a component takes, the closer to a normal HTML element we get, and in this case if we add a "type" we're basically back to a bare HTML element, which sort of defeats the whole purpose.

IMO the current implementation is fine, and more convenient to use, without too much repetition. Maybe if we have TertiaryButton, QuaternaryButton, QuinaryButton it might be more prudent to have the type be a prop, but I don't forsee that happening

@mingyokim mingyokim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Some minor feedback: we should probably add some really basic tests to the button component and refactor primary/secondary button into a single component

</div>
<br />
<div>
<PrimaryButton text="Primary" onClick={ButtonCallback} disabled />

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

I would like to see some specs that ensures onClick callback is not called when it's disabled, and that it's called when it's not disabled

@bobheadxi bobheadxi Jul 12, 2018

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

I'll look into adding a few simple tests for this PR, though I'll just point out that the disabled-ness is enforced in the CSS:

  &:disabled
    pointer-events: none

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Yeah I get that's enforced in the CSS but we can't predict how the CSS file would change later on - tests help us ensure that our components are still working as expected no matter how much our code changes in the future.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

See 941495c

@@ -0,0 +1,7 @@
button.primary
@include gradient-hover-animation($gradient-primary, $gradient-primary-highlight)

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎉

@@ -0,0 +1,13 @@
button.secondary
background: $gradient-secondary

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

We should make the styling for SecondaryButton the same as PrimaryButton either in this PR or create a follow-up issue.

OR we could refactor PrimaryButton and SecondaryButton into one component as I've already mentioned

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Ok we've decided not to refactor it, but i'd still like to see consistent sass between the two components? Like I'm not seeing the @include gradient-hover-animation($gradient-primary, $gradient-primary-highlight) piece here

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

What do you mean about the styling? I might agree on making them the same with only colour variations, but the special CSS required to make linear-gradient transition properly sorta makes that more effort than its worth IMO 😞

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Like I'm not seeing the @include gradient-hover-animation($gradient-primary, $gradient-primary-highlight) piece here

The secondary button transitions to a flat color $secondary-highlight, which works with -webkit-transition, but the primary button's gradient-to-gradient transition doesn't rip, hence the need for the mixin on one and not the other.

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

A lot of the shared styles are already in index.sass of buttons, which worked pretty well since they pretty much all applied to the progress group buttons as well (see the CSS in #21)

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

Thought: we should be careful about making the styling too tightly coupled between the components, because it makes us really inflexible when changes are requested - it's easier to copy styles across multiple components than it is to disentangle a property from tightly coupled styles.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Okay nevermind, i see what you mean

and yeah i'm a noob to css so i don't fully understand the pros/cons of the two approaches but i think if we have a fully fleshed out style guide then it's possible to achieve styles that are tightly coupled between the components

i guess let's bring it up in our channel/next meeting?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

🚀

@@ -0,0 +1,7 @@
import PrimaryButton from './PrimaryButton';

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Question about the location of the button component: is button an input?

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

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

// $main linear-gradient to use as normal background
// $hover linear-gradient to transition to upon hover
// $transition [optional] transition time, defaults to $transition-time
@mixin gradient-hover-animation($main, $hover, $transition: $transition-time )

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

...OK i trust you

Comment thread web/styles/colors.sass
@@ -0,0 +1,20 @@
/* colors */
$white: #FFFFFF

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

yaaas we need this - we should also consider having a set variables for spacing as well.

@sherryyx is there currently a spacing schema?

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

(^ not part of this PR) - something to consider going forward

Comment thread web/styles/index.sass
@import ./animations

/* components */
@import ../components/index

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

💪i like how the order of import is really clear here

@mingyokim

Copy link
Copy Markdown
Contributor

@bobheadxi Sure, we can just leave it as two separate components until we start seeing a lot of repetitions - which as you've mentioned is probably unlikely.

@bobheadxi bobheadxi requested review from chamkank and mingyokim and removed request for chamkank July 13, 2018 06:57

@mingyokim mingyokim left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

Looks good, ship it! 🚀

Btw @sherryyx added the clicked state for the buttons but let's make that a separate PR

test('should not be clickable', () => {
expect(wrapper.find('button').props().disabled).toBeTruthy();

// Enzyme click simulations do not respect 'disabled' attribute.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

😞


test('should be clickable', () => {
wrapper.find('button').simulate('click');
expect(clicked).toBeTruthy();

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

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

🎉

@bobheadxi

Copy link
Copy Markdown
Contributor Author

Btw @sherryyx added the clicked state for the buttons but let's make that a separate PR

😍 😍 😍 😍 😍 😍 😍 😍 😍

@bobheadxi bobheadxi merged commit ba8666a into master Jul 14, 2018
@bobheadxi bobheadxi deleted the web/primary-button branch August 1, 2018 05:30
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.

4 participants