First pass at styling the Price Plan selection component #2
Conversation
Since the HTTP API returns snake_case variables (I Think™), we'll need to be ok with using them as properties around the codebase. Variables are still verboten. I also disabled the camelcase rule from typescript-eslint, since naming-convention is a superset of that rule.
We'll use numeral for number formatting, since they'll do it a lot better than we will (gzipped bundle size is still quite small)
This adds a stylesheet, makes the story show three (identical for now) price plans, and adds a few classes to the PlanPicker components to start getting things styled
This would demonstrate how customization might happen
| @@ -0,0 +1,80 @@ | |||
| .octane-component { | |||
| /* Dark theme */ | |||
| --octane-bg-primary: #071420; | |||
There was a problem hiding this comment.
nit: probably could just omit the octane in the naming, maybe just --oc-bg-primary? wdyt?
There was a problem hiding this comment.
I spelled out octane just to make it really obvious for vendors (like this is octane stuff, not OpenCollective or any other company's stuff)
| --octane-border-primary: #c7dcd5; | ||
| --octane-fg-accent: #128475; */ | ||
|
|
||
| --octane-spacing: 6px; |
There was a problem hiding this comment.
nit: personal thoughts are we should try match the default chakra spacing which is 4px. That way there's more continuity if we want to copy over anything from our octane-portal repo.
There was a problem hiding this comment.
I usually pick 6 as a base unit because it can be split into both 2 and 3 in whole units. So anything that's a multiple of the spacing can be divided up without worrying about splitting pixels as often. If you feel strongly about 4 that's fine too.
src/components/PlanPicker.css
Outdated
| } | ||
|
|
||
| .octane-component .label { | ||
| font-size: 0.8rem; |
There was a problem hiding this comment.
nit: can you make font-size a variable too?
| } | ||
|
|
||
| .octane-component.price-plan-picker .price-plan-card { | ||
| display: inline-block; |
There was a problem hiding this comment.
thoughts on using flex here? considering the number of plans is dynamic it seems like flex may be a good option here, but curious to hear your thoughts.
There was a problem hiding this comment.
I used inline-block so that we could have a set width for all the plans to be, which would allow overflows to scroll horizontally (imagine if these end up on a phone, for example). I also like that this lets us focus on styling one dimension of plan card. We could totally make the plans adjustable in width too.For now, though, I'm gonna stick with inline-block for now just since it's generalizable, but I'm not mad at flex.
| <div className='price-plan-card'> | ||
| <div className='plan-name'>{displayName} </div> | ||
| <div className='base-price'> | ||
| <span className='label starting-at'>Starting at </span> |
There was a problem hiding this comment.
nit: starting-at seems unused?
There was a problem hiding this comment.
I wanted to give everything a unique way to be selected. The CSS file I've added is meant to be a guide / default, but I wanted it to be easy to write your own.
There was a problem hiding this comment.
makes sense. Do you feel like composing the container of these components with a generic flex element would oppose that thought (effectively a equivalent of a chakra <Box> wrapper)? Long as everything is labeled with classNames it seems like it would still be just as customizable, but have flex as a default
|
@zeppelinnn I feel you on repeated utils. My only other thought is pulling out common stuff that we use internally into its own package and sharing that between the portal and this repo, but I feel like that can happen when we have more shared deps. |
|
@zeppelinnn wrt sharing code, I have an incoming PR to share types based on the openapi schema file incoming. |
What's this?
This is some initial work to start the implementation and styling of a price plan component, and to use it in the price plan picker. It's getting mock data from the API right now. The top-level component is a flexible-width container that allows the plans inside of it to be scrolled horizontally.
All styling is done through a single CSS file, and all class names are semantic (i.e. it describes the thing, not how it should be styled) to make restyling easy.
Still to come:
Screenshots
Default theme
Example light theme
