A fast lane for bringing features to life.
- For Developers: to allow developers to focus on features and functionality through re-usable, configurable components
- For Users: provide consistent and comfortable UI interactions to spend more time outside of the app, than in
- To provide stand-alone components for common UI interactions
- To reduce duplication of work
- To provide configurable and progressively enhanced components
- To provide unique and customizable styling
- To ensure that components are tested for cross-browser use
- To focus on providing functionality across select targeted projects - Katello, Foreman and Aeolus
- To build upon proven, tested libraries
- Current users are Rails applications with a large codebase of views, JS and CSS that need progressive changes
- UI components should be deliverable via a gem, engine and asset pipeline
- Large projects want a single dependency that enables the use of many pieces
- How a component is deployed/packaged and how it is developed are not the same
- Remove connection to Rails from all components (see Magnum Opus below)
- Make testing front and center
- Restrict components to:
- JS
- SCSS/CSS
- HTML (potentially HAML)
- Develop Components using:
- AngularJS Directives
- SCSS
- Bower/Yeoman packaging
- Jasmine & Testacular for Tests
- Build Components using:
- Bower/Yeoman
- component.json package specification
- AngularJS - http://angularjs.org/
- jQuery
- CSS
- Rails Asset Pipeline
- AngularJS - http://angularjs.org/
- Testacular - http://testacular.github.com/0.6.0/index.html
- Jasmine - https://github.com/pivotal/jasmine
- SCSS / Compass
- jQuery
- Yeoman - http://yeoman.io
- Bower - https://github.com/twitter/bower
- Core dependency of all components
- Provides only the bare necessities
- Provides common SCSS and JS
- Handles configuration and customization
- Developer and User Guide
- Built using the same components and technology we develop
- Rails Application
Magnum Opus (http://en.wikipedia.org/wiki/Magnum_opus_(alchemy))
- Brings all components together
- Packaged as a Gem and RPM (single gem/RPM management makes life easier)
- Built as a Rails Engine for asset delivery
- Manage Packages and Dependencies via Yeoman/Bower
- No direct code, only used to bring assets together into a single package
- Essentially becomes a repository for UI assets that deals only in adding new assets, or updating existing ones, wrapping that grouping into a deployable gem/engine/rpm
Q: Why rely on Angular?
A: The project has a test first attitude which is lacking an important in the multi-browser ecosystem. Angular is also built with the idea of building new components that appear like standard HTML components. Further, the way the project is built, small pieces of an application can be upgraded over time as opposed to re-writting the entire application. Further, large community, and backed by a company means reliability.
Q: Why use Bower for packaging?
A: Bower gets out of our way and allows us to keep the libraries in our own git repositories, but easily update and add new ones.
Q: Is this over-engineered?
A: I don't think it does. The focus is on building components that do one thing well and are tested which means changes in one should not affect another. Moving to javascript based tooling and definitions keeps the components close to their native constructs and stays close to where the modern web is headed.
Q: I am a Rails developer. How is this useful to me?
A: You just include the MagnumOpus gem, and start linking in the assets you need where you want to place them within your application.
- Rename alchemy-workbench to workbench
- Rename 'alchemy' to 'magnum_opus'
- Create 'alchemy' or 'alchemy-core' repository
- Pull components out of current alchemy into core
- Register alchemy/alchemy-core with Bower
- Wire up MagnumOpus to include Alchemy and point to assets
- Wire up Workbench for changes
- Craft tables component
- Add tables component to MagnumOpus
- Test on Workbench
- Move components into their own repositories over time
Using alchemy-tables as an example for a proposed layout based on componentjs, Yeoman scaffolding and angular-seed. See https://github.com/ui-alchemy/component-scaffold
alchemy-tables/
app/
scripts/
app.js
styles/
main.css
index.html
component/
styles/
table.css.scss
scripts/
directives/
tables.js
templates/
alchemy_table.html
alchemy_table.html.js
dist/
component.json
tables.js
tables.scss
tables.css
test/
directives/
table_test.js
testacular.conf.js
Gruntfile.js
README
LICENSE
This layout reflects what a release of a component looks like. This is done in a branch using git subtrees and tags. This directory structure is what bower will install, and is intended to be a flat structure with all templates bundled to JS to make path resolution easier and for caching of templates into the JS and reduce the number of trips.
dist/
component.json
tables.js
tables.scss
tables.css