https://github.com/chantastic/elements
Created with CodeSandbox
https://github.com/chantastic/elements
Last synced: 2 months ago
JSON representation
Created with CodeSandbox
- Host: GitHub
- URL: https://github.com/chantastic/elements
- Owner: chantastic
- Created: 2018-10-31T20:22:15.000Z (over 7 years ago)
- Default Branch: master
- Last Pushed: 2018-11-07T18:21:09.000Z (over 7 years ago)
- Last Synced: 2025-03-22T03:11:45.893Z (about 1 year ago)
- Language: JavaScript
- Homepage: https://codesandbox.io/s/github/chantastic/elements
- Size: 87.9 KB
- Stars: 1
- Watchers: 2
- Forks: 0
- Open Issues: 0
-
Metadata Files:
- Readme: readme.md
Awesome Lists containing this project
README
# Elements
## What is this
It's an exploration of of a design system artifact at planning center.
It uses standard CSS for styling and theming.
It uses JS (likely TS soon) functions to augement className composition.
It will expose React components for use in React environments.
## What's a design system
Let's start with what it's not.
It's not an artifact in your favorite tech.
A design system is rules and boundaries.
It's like [The Elements of Style](https://www.amazon.com/Elements-Style-William-Strunk-Jr/dp/194564401X) by William Strunk .
Or [The Elements of Typographic Style](https://www.amazon.com/Elements-Typographic-Style-Version-Anniversary/dp/0881792128/ref=sr_1_3?s=books&ie=UTF8&qid=1541017945&sr=1-3&keywords=robert+bringhurst) by Robert Bringhurst.
A design system is the what and why.
Not the how.
Our design system lives in articles at [planningcenter.design](https://planningcenter.design).decodeURI
This is an artifact, using the elements of ui style retained there.
## Core concepts
### Standard
Standards stand the test of time.
They're widely documented.
They're easier to train people in.
They're easier to hire for.
They're stack agnostic.
The main exports of this project are browser-standard — CSS and JavaScript.
In addition, there are non-standard React component consumers.
## Thinking as of 11/4
This is how it decomposes:
```jsx
// App-level
// primary-library-export
import Action from "@planningcenter/elements/action"
// library-level export
export function Action(props) {
return
}
// browser-output
```
## Thinking as of 11/1
### "button" is the wrong abstraction
I find `button` to be subtly subversive.
I question if it's the main contributor to poor markup in the anchor/button decision.
During a Free-Week research project, I floated the idea of `action` to Dustin, Jon, and Allie.
They were on board.
It maps better to the action driven names I proposed to Groups/Giving years ago.
Dustin says they feel like a very robust primitive.
I'm going to roll with those and see how it goes.
I'd like to see these classes present themselves as markup-agnostic.
This would be inline with that goal.
Example: `create-action`, `destroy-action`, `navigation-action | route-action`.
## Thinking as of 10/31
This is how it decomposes:
```jsx
// App-level
// primary-library-export
// secondary-library-export
// browser-output
```