Primary button, stylesheet restructure#20
Conversation
All stylesheet imports should only go one way - from the primary stylesheet in 'styles/index.sass'
Pull Request Test Coverage Report for Build 246
💛 - Coveralls |
6a4ed2d to
3614956
Compare
fb40068 to
890b3e1
Compare
mingyokim
left a comment
There was a problem hiding this comment.
Quick review for now - will complete review later
| <button | ||
| onClick={onClick} | ||
| type="button" | ||
| className={`primary ${disabled ? 'disabled' : ''}`}> |
There was a problem hiding this comment.
Can we disable buttons by doing <button disabled>Button</button> instead?
https://stackoverflow.com/questions/14750078/style-disabled-button-with-css
There was a problem hiding this comment.
That's much cleaner thanks, addressed in 7b2f778
mingyokim
left a comment
There was a problem hiding this comment.
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
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 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 |
mingyokim
left a comment
There was a problem hiding this comment.
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 /> |
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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: noneThere was a problem hiding this comment.
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.
| @@ -0,0 +1,7 @@ | |||
| button.primary | |||
| @include gradient-hover-animation($gradient-primary, $gradient-primary-highlight) | |||
| @@ -0,0 +1,13 @@ | |||
| button.secondary | |||
| background: $gradient-secondary | |||
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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
There was a problem hiding this comment.
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 😞
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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)
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
| @@ -0,0 +1,7 @@ | |||
| import PrimaryButton from './PrimaryButton'; | |||
There was a problem hiding this comment.
Question about the location of the button component: is button an input?
There was a problem hiding this comment.
| // $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 ) |
| @@ -0,0 +1,20 @@ | |||
| /* colors */ | |||
| $white: #FFFFFF | |||
There was a problem hiding this comment.
yaaas we need this - we should also consider having a set variables for spacing as well.
@sherryyx is there currently a spacing schema?
There was a problem hiding this comment.
(^ not part of this PR) - something to consider going forward
| @import ./animations | ||
|
|
||
| /* components */ | ||
| @import ../components/index |
There was a problem hiding this comment.
💪i like how the order of import is really clear here
|
@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. |
| test('should not be clickable', () => { | ||
| expect(wrapper.find('button').props().disabled).toBeTruthy(); | ||
|
|
||
| // Enzyme click simulations do not respect 'disabled' attribute. |
|
|
||
| test('should be clickable', () => { | ||
| wrapper.find('button').simulate('click'); | ||
| expect(clicked).toBeTruthy(); |
😍 😍 😍 😍 😍 😍 😍 😍 😍 |
👷 Changes
frontendcomponentsintodemocolors.sass- choose from these from now on!Updated with disabled states
Updated with animated transitions
💭 Notes
For stylesheets, there should only be one import for general styles in
index.js:All other styles should be imported via
styles/index.sass:etc etc.
🔦 Testing Instructions
then go to http://localhost:8080/ui_demo