This repository provides building blocks usable to create Wildcat screens.
This repository holds the design atoms we use in CitizenNet applications. These atoms can be built, styled, and rigorously tested without being forced into the context of the application. That allows for faster fixes and iteration in a sandbox environment so we can isolate errors, and more importantly, it allows easy access for business and design teams to verify our components without having to wait for a staging release or build anything locally.
This separation of concerns carries the same benefits as functional programming generally and fits well with using Tachyons (functional css) and PureScript. The Wildcat repository focuses on building a robust, usable application for our end users, whereas the CN UI repository focuses on providing self-contained, well-tested design atoms that can be dropped into any Wildcat screen and just as easily be updated or replaced.
There are three relevant parts to this project:
- The root folder, which contains the pre-built components (styling generally included) we can drop into Wildcat screens;
testfolder, which contains a tiny PureScript application we can use to test our components and their styling;
docsfolder, which is generated by the tests and publishes the GitHub Pages site so anyone can use it.
cssfolder, which contains our modified version of Tachyons
Preview & Testing
One of the major goals of this project is to provide a minimal environment to test the UI components we build and ensure the behaviors and styling are correct without coupling them to a particular screen in the app. Once the individual units are built and tested, we know we can safely import and use them in the app.
- Components can be viewed and tested by anyone at the documentation site. This is generated from the PureScript app in
- TODO: There are no tests yet.
- TODO: There is no continuous integration yet.
One of the primary aims of this project is to provide a way for non-PureScript developers to view and test our components. That ability is provided by the generated documentation site, but we have to actually generate that site if we've made changes.
To do that, ensure that any commit to the master branch is preceded by a call to
npm run docs:
npm run docs git commit -m "..." git push origin master