[V2] Colour Sheet from Invision wireframes + added to Button + stories

[W3stside]

💧 into #1626

V2/Colour Sheet from Invision wireframes + added to Button + stories

Button stories use new colours, + small optimisation to button/styledButton base code

[gnosis-info]

Travis automatic deployment:

• 🎩 Dapp: Testing web app
• 📚 Storybook: Component stories

[fairlighteth]

Is it an idea to further abstract this away into a 'setMode' type of hook? So that the hook determines what mode we're on and returns either COLOURS.bgDark or COLOURS.bgLight ?

Down the road perhaps we can even further abstract it down to:
styles.backgroundDefault which first conditionally determines what mode we're on and then only return the bg color.

[W3stside]

Down the road perhaps we can even further abstract it down to:
styles.backgroundDefault which first conditionally determines what mode we're on and then only return the bg color.

how would you do this? styles is in another file and should remain there. To conditionally set it there wouldn't be possible unless it used some logic elsewhere or within a component.

The hook approach is imo the only viable solution, or at least the most straight forward without spending too much time. The user's selection would then be saved to localstorage and loaded on app load (as we do now in v1)

[W3stside]

for now this is just a lazy man's version of creating a decorator i needed for testing, it will be extrapolated into a hook down the line (sth to check in v1 if we already have, which i believe we do and can repurpose)

[fairlighteth]

Yeah was thinking something along the lines of a hook. Assuming we can call that from within the styles file context. So styles would only return you stuff, after checking the current mode with hooks.

[fairlighteth]

Can this whole StyledButton.ts be kept dryer so that instead doing:

   warning: {
    light: css`
      color: ${white};
      background: ${warningLight};
      &:hover {
        background: ${warningDark};
        border-color: ${warningDark};
      }
    `,
    dark: css`
      color: ${white};
      background: ${warningDark};
      &:hover {
        background: ${warningLight};
        border-color: ${warningLight};
      }
    `,
  },

doing

  warning: {
    css`
      color: ${white};
      background: ${warningBgDefault};
      &:hover {
        background: ${warningBgHoverDefault};
        border-color: ${warningBorderColorDefault};
      }
    `
  },

Then e.g. we could have a variable warningDefault (the above vars are a bit verbose, but for the sake of demo-ing) which conditionally returns a color, based on getting the current mode (either dark or light).

This keeps this styling code dryer for defaults. For overrides we can specifically override the colors in a individual component. Let me know your thoughts.

[anxolin]

why do we want to import this from the styles?
Is because we expect to use always the same border radius and u want to have it in a constant?

I mean, if we really want to all have the same value, ok, but I think the more independent the components are the better. I do see, that if we repeat ourselves a lot, we can have some fragments we reuse, just not sure this is the case.

[fairlighteth]

So in the context of a Button in my view it makes sense to use a default global value for the borderRadius. It is to be assumed that we'd use at most 2 distinct values for the border-radius. Where a lot of them will simply use a default.

This applies to other styled properties too.

[W3stside]

@anxolin I think for buttons this will and should be the case. For others, I 100% agree we should be more granular and create fragments where we need. In this case I believe it should remain this way, for consistency in the buttons