|
1 | | -# React + TypeScript + Vite |
| 1 | +# Climate Action Data Trust User Interface |
2 | 2 |
|
3 | | -This template provides a minimal setup to get React working in Vite with HMR and some ESLint rules. |
| 3 | +This repository provides a graphical user interface (UI) for the [Climate Action Data Trust (CADT)](https://github.com/Chia-Network/cadt) application. CADT interfaces with the Chia Blockchain software and provides and API for entering and retrieving carbon data. This UI is a javascript application that connects to the CADT API for a convenient way to access the data. |
4 | 4 |
|
5 | | -Currently, two official plugins are available: |
| 5 | +*Note that this application was previously called the Climate Warehouse UI and that name may be used interchangeably in documentation and throughout this application.* |
6 | 6 |
|
7 | | -- [@vitejs/plugin-react](https://github.com/vitejs/vite-plugin-react/blob/main/packages/plugin-react/README.md) uses [Babel](https://babeljs.io/) for Fast Refresh |
8 | | -- [@vitejs/plugin-react-swc](https://github.com/vitejs/vite-plugin-react-swc) uses [SWC](https://swc.rs/) for Fast Refresh |
9 | 7 |
|
10 | | -## Expanding the ESLint configuration |
| 8 | +## Installation |
11 | 9 |
|
12 | | -If you are developing a production application, we recommend updating the configuration to enable type aware lint rules: |
| 10 | +The UI application can be hosted as a web application and accessed via the browser, or as a desktop application packaged with Electron. Currently the application is only packaged for x86 platforms, though building from source is expected to work on ARM. |
13 | 11 |
|
14 | | -- Configure the top-level `parserOptions` property like this: |
| 12 | +### Desktop Applications |
15 | 13 |
|
16 | | -```js |
17 | | -export default { |
18 | | - // other rules... |
19 | | - parserOptions: { |
20 | | - ecmaVersion: 'latest', |
21 | | - sourceType: 'module', |
22 | | - project: ['./tsconfig.json', './tsconfig.node.json'], |
23 | | - tsconfigRootDir: __dirname, |
24 | | - }, |
25 | | -} |
| 14 | +The [releases](https://github.com/Chia-Network/cadt-ui/releases) page provides desktop applications packaged for Windows, Mac, and Debian-based Linux distributions. |
| 15 | + |
| 16 | +#### Ubuntu Desktop via Apt |
| 17 | + |
| 18 | +For Ubuntu-based Linux desktops the CADT UI is available for install with `apt`. |
| 19 | + |
| 20 | +1. Start by updating apt and allowing repository download over HTTPS: |
| 21 | + |
| 22 | +``` |
| 23 | +sudo apt-get update |
| 24 | +sudo apt-get install ca-certificates curl gnupg |
26 | 25 | ``` |
27 | 26 |
|
28 | | -- Replace `plugin:@typescript-eslint/recommended` to `plugin:@typescript-eslint/recommended-type-checked` or `plugin:@typescript-eslint/strict-type-checked` |
29 | | -- Optionally add `plugin:@typescript-eslint/stylistic-type-checked` |
30 | | -- Install [eslint-plugin-react](https://github.com/jsx-eslint/eslint-plugin-react) and add `plugin:react/recommended` & `plugin:react/jsx-runtime` to the `extends` list |
| 27 | +2. Add Chia's official GPG Key (if you have installed Chia or [CADT](https://github.com/Chia-Network/cadt) with `apt`, you'll have this key already and will get a message about overwriting the existing key, which is safe to do): |
31 | 28 |
|
32 | | -### Contributing |
| 29 | +``` |
| 30 | +curl -sL https://repo.chia.net/FD39E6D3.pubkey.asc | sudo gpg --dearmor -o /usr/share/keyrings/chia.gpg |
| 31 | +``` |
| 32 | + |
| 33 | +3. Use the following command to setup the repository. |
| 34 | + |
| 35 | +``` |
| 36 | +echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/chia.gpg] https://repo.chia.net/cadt/debian/ stable main" | sudo tee /etc/apt/sources.list.d/cadt.list > /dev/null |
| 37 | +``` |
33 | 38 |
|
34 | | -All branches should be created from the `develop` branch and not from `main`. All pull requests should be made against the `develop` branch, unless it is a new release. The `develop` branch will be merged into the `main` branch to create a release. Automation in the CI will create the [release](https://github.com/Chia-Network/cadt/releases) and attach the installation files to it automatically whenever code is merged to `main`. Additionally, the changelog will automatically be updated in the `main` branch. Therefore, the `main` branch should always be a representation of the latest released code. |
| 39 | +4. Install CADT-UI |
| 40 | + |
| 41 | +``` |
| 42 | +sudo apt-get update |
| 43 | +sudo apt-get install cadt-ui |
| 44 | +``` |
| 45 | + |
| 46 | + |
| 47 | +### Web Application |
| 48 | + |
| 49 | +The CADT UI can be hosted as a web application, either for internal use, or made available to the public. When operating as a web application, the user's browser must be able to connect to the [CADT API](https://github.com/Chia-Network/cadt). This means the API must be available on the public internet if the UI is public. The `READ_ONLY` option on the API should be set when running a public observer node. |
| 50 | + |
| 51 | +To host the UI on the web, use the [web-build.tar.gz file from the releases page](https://github.com/Chia-Network/cadt-ui/releases). One of the simplest solutions is to uncompress these files into a [public S3 bucket](https://docs.aws.amazon.com/AmazonS3/latest/userguide/WebsiteAccessPermissionsReqd.html). These files could also be served by any webserver, such as Nginx or Apache. |
| 52 | + |
| 53 | +To make the CADT UI web application automatically connect to a CADT host by default, copy the `config.example.json` file to `config.json` and change the `apiHost` to be the CADT API hostname, including http:// and the path (everything before the `/v1` part of the API URL) |
| 54 | + |
| 55 | +### From Source |
| 56 | + |
| 57 | +*It is recommended to use the pre-built application from the releases page or the apt repo and only build from source if contributing code to the application* |
| 58 | + |
| 59 | + |
| 60 | +``` |
| 61 | +git clone [email protected]:Chia-Network/cadt-ui.git |
| 62 | +cd cadt-ui |
| 63 | +nvm install |
| 64 | +nvm use |
| 65 | +npm install |
| 66 | +npm install -g git-authors-cli |
| 67 | +
|
| 68 | +npm run start |
| 69 | +``` |
| 70 | + |
| 71 | +#### Prerequisites |
| 72 | + |
| 73 | +You'll need: |
| 74 | + |
| 75 | +- Git |
| 76 | +- [nvm](https://github.com/nvm-sh/nvm) |
| 77 | + |
| 78 | + This app uses `nvm` to align node versions across development, CI and production. If you're working on Windows you should consider [nvm-windows](https://github.com/coreybutler/nvm-windows) |
| 79 | + |
| 80 | +## Contributing |
| 81 | + |
| 82 | +Upon your first commit, you will automatically be added to the package.json file as a contributor. |
| 83 | + |
| 84 | +## Commiting |
| 85 | + |
| 86 | +This repo uses a commit convention. A typical commit message might read: |
35 | 87 |
|
36 | | -This repo uses a [commit convention](https://www.conventionalcommits.org/en/v1.0.0/). A typical commit message might read: |
37 | | - |
38 | 88 | ``` |
39 | 89 | fix: correct home screen layout |
40 | 90 | ``` |
41 | | - |
| 91 | + |
42 | 92 | The first part of this is the commit "type". The most common types are "feat" for new features, and "fix" for bugfixes. Using these commit types helps us correctly manage our version numbers and changelogs. Since our release process calculates new version numbers from our commits it is very important to get this right. |
43 | | - |
44 | 93 |
|
45 | 94 | - `feat` is for introducing a new feature |
46 | 95 | - `fix` is for bug fixes |
47 | 96 | - `docs` for documentation only changes |
48 | 97 | - `style` is for code formatting only |
49 | 98 | - `refactor` is for changes to code which should not be detectable by users or testers |
50 | | -- `perf` is for a code change that improves performance |
51 | 99 | - `test` is for changes which only touch test files or related tooling |
52 | 100 | - `build` is for changes which only touch our develop/release tools |
53 | | -- `ci` is for changes to the continuous integration files and scripts |
54 | | -- `chore` is for changes that don't modify code, like a version bump |
55 | | -- `revert` is for reverting a previous commit |
56 | | - |
57 | | - After the type and scope there should be a colon. |
58 | | - |
59 | | - The "subject" of the commit follows. It should be a short indication of the change. The commit convention prefers that this is written in the present-imperative tense. |
| 101 | +- `chore` is for housekeeping tasks such as hydrating from another branch |
| 102 | + |
| 103 | +After the type and scope there should be a colon. |
| 104 | + |
| 105 | +The "subject" of the commit follows. It should be a short indication of the change. The commit convention prefers that this is written in the present-imperative tense. |
| 106 | + |
| 107 | +### Commit linting |
| 108 | + |
| 109 | +Each time you commit the message will be checked against these standards in a pre-commit hook. Additionally all the commits in a PR branch will be linted before it can be merged to master. |
0 commit comments