An open API service indexing awesome lists of open source software.

https://github.com/rodleviton/cake-components

Perfectly baked and decorated components for any occasion.
https://github.com/rodleviton/cake-components

Last synced: about 2 months ago
JSON representation

Perfectly baked and decorated components for any occasion.

Awesome Lists containing this project

README

        

# Cake Components
Perfectly baked and decorated components for any occasion.

## Background of project
Complex web applications are no longer created as a collection of views that represent an entire page/route. Instead developers are taking queues from the functional programming paradigm and composing components to form complex application views. The component architecture has been spearheaded by the Open Source JavaScript library [React](https://facebook.github.io/react/) and the miriad of 'React' like libraries such as [Inferno](https://github.com/infernojs/inferno), [Preact](https://github.com/developit/preact) etc... The problem with so many frameworks and libraries tackling this is the need to re-engineer the same components over and over again based on the particular framework you are using.

## What is Cake?
Cake is not so much a 'thing' but more of an approach to building highly reusable, semantic and easily themeable components. Cake attempts to formalise an approach to thinking about building components in a way that reduces one of the burdens that accomponies framework fatigue.

```
source -> compile (based on consuming framework) -> output
```

### 1. Source
The underlying source of a component should be the same irrespective of consuming framework. Components should be built using a well defined, agreed upon common api.

### 2. Compile
This can be thought of as the 'middleman'. Whether your project is using [Angular](https://angularjs.org/), [React](https://facebook.github.io/react/), [Vue](https://vuejs.org/)... The __Compile__ step should alow you to translate the __Source__ into a common __Output__.

### 3. Output
The component __Output__ should be in a form that is consumable by your project without any further transpilation.

## Anatomy of a Cake component
The following prescribes a default list of ingredients that go into building a Cake Component. Your specific implementation may vary (e.g. structure, naming conventions...), but the end goal is the same: 'build once, build it right, use everywhere'.

### 1. Base
Just like any good cake base recipe, this should never be changed once perfected. The base of a Cake Component should be semantically correct, accessible and not include extra markup to achieve bespoke design requirements. The base is the foundation to which we apply the rest of the ingredients on top of. Bake all the good stuff in!

A primary goal of the base implemenation is to allow for extensibility. We need to be mindful that when a component is created that it does not include anything 'theme' or 'context' specific. We should be able to simply `import` our base component into our project and go from there.

#### Example Base structure

```markdown
base
└── [component-name]/
├── [component-name].base.html
├── [component-name].base.js
└── [component-name].base.css
```

##### HTML
```
[component-name].base.html
```
The `base.html` file should contain the semantic html structure of your component template. This does not necessarily have to be contained within a seperate `.html` file, in the case of [JSX](https://facebook.github.io/react/docs/jsx-in-depth.html) this template would be generated within a `.js` or `.jsx` file.

##### JavaScript
```
[component-name].base.js
```
The `base.js` file should contain the minimal amount of javascript required to make your component operational and achieve accessibilty requirements. Again, this file is not neccessarily required.

##### CSS
```
[component-name].base.css
```
The `base.css` file is a minimal stylesheet that is generally used to create a 'vanilla' version of your component and reset default styles generated by specific browser implementations.

### 2. Sprinkles
As the name suggests sprinkles can be thought of as the decoration on top of your component base. Sprinkles are very much 'theme' and 'context' specific and should not be required to make a component work.

#### Example Sprinkles structure
How you structure your component 'Sprinkles' is completely up to you and your team but the goal is to clearly seperate the 'theme' layer of our components so that they can be used in any project and within any context.

```markdown
sprinkles
└── [component-name]/
├── [component-name].sprinkles.js
└── [component-name].sprinkles.css
```

##### JavaScript
```
[component-name].sprinkles.js
```
The `sprinkles.js` file should only contain visual and functionality enhancements for your component e.g. programatic animation sequence.

##### CSS
```
[component-name].sprinkles.css
```
The `sprinkles.css` file should contain theme specific styles e.g. colours, borders, padding etc.