Merge pull request #59 from bitcoin-sv/rename-bux-to-spv-wallet

feat(BUX-588): transition to `spv-wallet` naming

.github/workflows/CODE_STANDARDS.md

@@ -45,7 +45,6 @@
     - [4.5 Markdown usage](#45-markdown-usage)
     - [4.5 Conclusion](#45-conclusion)
 
-
 ## Most important rules - Quick Checklist
 
 - [ ] Follow guidelines and local formatting and linting settings (like prettier) for style and formatting.
@@ -75,60 +74,62 @@
 
 ```ts
 const person = {
-  firstName: "Bill",
-  lastName: null,  // 🟥
-  lastName: "",    // ✅
+  firstName: 'Bill',
+  lastName: null, // 🟥
+  lastName: '', // ✅
 }
 ```
 
 - If for some reason a default value cannot be assigned or it is impractical to assign a default value, assign a `null` value rather than an `undefined` value.
 
 ```ts
 const person = {
-  firstName: "Bill",
+  firstName: 'Bill',
   address: undefined, // 🟥
-  address: null,      // ✅
+  address: null, // ✅
 }
 ```
 
 - When code you have no control over (external library) or JavaScript itself may return undefined, convert it to null (or preferably to a default value if possible).
 
 ```ts
-const found = arr.find((item) => item > 5);         // 🟥
-const found = arr.find((item) => item > 5) ?? null; // ✅
+const found = arr.find((item) => item > 5) // 🟥
+const found = arr.find((item) => item > 5) ?? null // ✅
 ```
 
 - Whenever writing TypeScript code, avoid using `any` and always annotate types for Props passed to a Component.
 
 ```ts
 interface MyComponentProps {
-  setName: any                                           // 🟥
-  setName: React.Dispatch<React.SetStateAction<string>>  // ✅
+  setName: any // 🟥
+  setName: React.Dispatch<React.SetStateAction<string>> // ✅
 }
 
-const MyComponent = (props: any) => {}                      // 🟥
-const MyComponent: FC<MyComponentProps> = ({setName}) => {} // ✅
+const MyComponent = (props: any) => {} // 🟥
+const MyComponent: FC<MyComponentProps> = ({ setName }) => {} // ✅
 ```
 
 - Use curly braces `{}` instead of `new Object()`.
 
 ```ts
-const newObject = new Object()  // 🟥
-const newObject = {}            // ✅
+const newObject = new Object() // 🟥
+const newObject = {} // ✅
 ```
 
 - Use brackets `[]` instead of `new Array()`.
- 
+
 ```ts
-const newArray = new Array()  // 🟥
-const newArray = []           // ✅
+const newArray = new Array() // 🟥
+const newArray = [] // ✅
 ```
 
 - Use `===` and `!==` instead of `==` and `!=`.
 
 ```ts
-if (oneObject == anotherObject) {}   // 🟥
-if (oneObject === anotherObject) {}  // ✅
+if (oneObject == anotherObject) {
+} // 🟥
+if (oneObject === anotherObject) {
+} // ✅
 ```
 
 - When writing html/jsx/tsx, use proper semantic html tags, suitable for a given component.
@@ -153,8 +154,8 @@ List of all categorized html tags with short description: [HTML Elements Referen
 - When an import needs to go to more than one directory above, use full-path imports.
 
 ```typescript
-import { MyComponent } from "../../../MyComponent"         // 🟥
-import { MyComponent } from "/src/components/MyComponent"  // ✅
+import { MyComponent } from '../../../MyComponent' // 🟥
+import { MyComponent } from '/src/components/MyComponent' // ✅
 ```
 
 ### 2.2 File structure
@@ -165,6 +166,7 @@ Style files should take the name of the component with the suffix .style.{js/ts}
 Custom hooks can take the name of use\<componentName\>.{js/tx}. For example: `useMyComponent.js`.
 
 Example:
+
 ```
 |-- index.html
 |-- index.js
@@ -183,7 +185,7 @@ Example:
 
 #### As a Developer
 
-- Refactoring tasks should be strategically undertaken; not every piece of code warrants modification. If a segment of code, despite comments, remains untouched and unproblematic, it is   likely fulfilling its purpose effectively.
+- Refactoring tasks should be strategically undertaken; not every piece of code warrants modification. If a segment of code, despite comments, remains untouched and unproblematic, it is likely fulfilling its purpose effectively.
 - When embarking on feature additions or bug fixes, and encountering commented code, consider extracting functions and creating a PR before proceeding with the primary task. This helps maintain code clarity and function.
 - Should you come across a superfluous comment during your changes, do take the initiative to remove it and create a PR for that. This practice contributes to keeping the repository neat and well-maintained.
 - Endeavor to minimize the addition of comments when making any changes to the code.
@@ -212,27 +214,27 @@ Developers are required to diligently cover their changes with tests and organiz
    - **Then**: Verify if the outcomes match the expectations.
 
    ```js
-   import { importantFunction } from "./index.js"
+   import { importantFunction } from './index.js'
 
-   test("Test Something Very Useful Is Happening", () => {
+   test('Test Something Very Useful Is Happening', () => {
      // given
-     const functionInput = "importantInput"
-     const expectedResult = "importantResult"
+     const functionInput = 'importantInput'
+     const expectedResult = 'importantResult'
 
      // when
      const result = importantFunction(functionInput)
 
      // then
      expect(result).toBe(expectedResult)
    })
-    ```
+   ```
 
 4. **Test Isolation**: Ensure test isolation by avoiding the use of global variables and shared state. Each test should be independent and not rely on the execution of other tests. If a test requires a shared state, use a setup function to create the state before each test.
 
 5. **Test Data**: Avoid random data in tests. Instead, use predefined data to ensure test consistency and reproducibility. If random data is required, use a seed to ensure the same data is generated each time the test is run.
 
 6. **Test Cases**: If you are writing a public functions - it should be covered by tests. We should have test cases for all possible scenarios. That means that **we should have tests for all possible errors** that can be returned from the function.
-Of course not only error paths should be covered - **we should highlight the happy path as well**.
+   Of course not only error paths should be covered - **we should highlight the happy path as well**.
 
 7. **Testing private (unexported) functions**: When testing private functions, we should test them through the public (exported) functions that use them. The exception is when the private function is too complex to be tested through the public function. Good example is for example a function that is implementing a complex algorithm. In this case we should test the private function directly.
 
@@ -353,8 +355,8 @@ Additional information and guidelines on Conventional Commits can be found [here
 
 Good example:
 
-```bash
-feat: add possibility to create a new user by admin (#BUX-123)
+```
+feat(#123): add possibility to create a new user by admin
 ```
 
 Bad example:

.github/workflows/PULL_REQUEST_TEMPLATE.md

@@ -5,8 +5,8 @@
 
 # Pull Request Checklist
 
-- [ ] 📖 I created my PR using provided  : [CODE_STANDARDS](https://github.com/bitcoin-sv/bux-wallet-frontend/blob/main/.github/CODE_STANDARDS.md)
-- [ ] 📖 I have read the short Code of Conduct: [CODE_OF_CONDUCT](https://github.com/bitcoin-sv/bux-wallet-frontend/blob/main/.github/CODE_OF_CONDUCT.md)
+- [ ] 📖 I created my PR using provided  : [CODE_STANDARDS](https://github.com/bitcoin-sv/spv-wallet-web-frontend/blob/main/.github/CODE_STANDARDS.md)
+- [ ] 📖 I have read the short Code of Conduct: [CODE_OF_CONDUCT](https://github.com/bitcoin-sv/spv-wallet-web-frontend/blob/main/.github/CODE_OF_CONDUCT.md)
 - [ ] 🏠 I tested my changes locally.
 - [ ] ✅ I have provided tests for my changes.
 - [ ] 📝 I have used conventional commits.

.github/workflows/checks.yaml

@@ -27,5 +27,5 @@ jobs:
       - name: Install dependencies with yarn
         run: yarn install --frozen-lockfile
 
-      - name: Run bux-wallet ESLint
+      - name: Run spv-wallet ESLint
         run: yarn lint

.gitignore

@@ -29,7 +29,6 @@ dist-ssr
 
 # docker compose
 data/
-bux-wallet-backend.env.private
 
 # overriden config
 /env-config.json

README.md

@@ -1,7 +1,7 @@
-# BUX WALLET APP
+# SPV WALLET WEB FRONTEND
 
-The `bux-wallet-frontend` is a referential frontend application for a custodial web wallet. 
-It is used in conjunction with the `bux-wallet-backend` component, which serves as the backend server.
+The `spv-wallet-web-frontend` is a referential frontend app designed as a part of the **SPV Wallet** which is a custodial wallet for Bitcoin SV.
+It utliizes the `spv-wallet` service as a non-custodial wallet in conjunction with the `spv-wallet-web-backend` as a backend server which is responsible for storing user data and private keys.
 
 ## Running the project
 
@@ -15,73 +15,53 @@ It is used in conjunction with the `bux-wallet-backend` component, which serves
 
 There are two way of running backend locally:
 
-#### Using ./start.sh script 
+#### Using ./start.sh script
 
-`bux-wallet-frontend` provides a `start.sh` script
-which is using `docker-compose.yml` file to starts up Bux Wallet Frontend, Backend and 
-Bux Server with selected database and cache storage. To start, we need to fill the 
-config json which we want to use, there is prepared custom config file `docker/envs/development.json`
-which is used in development environment. This script build local image of bux-wallet-frontend and use 
+`spv-wallet-web-frontend` provides a `start.sh` script
+which is using `docker-compose.yml` file to starts up `SPV Wallet` with web-frontend, web-backend and selected database and cache storage.
+This script build local image of spv-wallet-web-frontend and use
 already built ones for the rest of applications.
 
 Ports which are used:
-- 3002  - Bux wallet frontend
-- 3003  - Bux server
-- 5432  - PostgreSQL db
-- 6379  - Redis
-- 8080  - Pulse
-- 8081  - Bux wallet backend
+
+- 3002 - SPV wallet web-frontend
+- 8081 - SPV wallet web-backend
+- 3003 - SPV wallet (core service)
+- 5432 - PostgreSQL DB
+- 6379 - Redis
+- 8080 - Block Headers Service
 - 27017 - MongoDB
 
 There are three ways of running this script:
-1. With manual configuration - every option is displayed in terminal and user can choose
-   which applications should be started and configure how to run bux-server. Use command:
-  ```bash
-  ./start.sh
-  ```
-2. With flags which define how to set up docker services. Ever option is displayed when
-   you ran the script with flag `-h` or `--help`.
-  ```bash
-  ./start.sh -db postgresql -c redis -bs true -env development -b false 
-  ```
-3. With `-l/--load` flag. This option add possibility to use previously created `.env.config` file and run whole environment with simple command:
-  ```bash
-  ./start.sh -l
-  ```
-
-#### Using docker compose
-To run backend locally you can use docker compose
-
-Before you use it, you need to create a file named
-`bux-wallet-backend.env.private`
-containing at least one entry:
 
-`BUX_ADMIN_XPRIV=xprv...` where `xpriv...` should be replaced with valid admin xpriv
+1. With manual configuration - every option is displayed in terminal and user can choose
+   which applications should be started and configure how to run `spv-wallet`. Use command:
 
-You can do this for example with this command (just replace <<admin_xpriv>> with valid admin xpriv)
-```bash 
-echo 'BUX_ADMIN_XPRIV=<<admin_xpriv>>' > bux-wallet-backend.env.private 
+```bash
+./start.sh
 ```
 
-Now all you need to do is to run command:
+2. With flags which define how to set up docker services. Ever option is displayed when
+   you ran the script with flag `-h` or `--help`.
 
 ```bash
-yarn backend
+./start.sh -db postgresql -c redis -bs true -env development -b false
 ```
 
-And you can play with the backend on localhost:8080
-for example you can find there a swagger:
+3. With `-l/--load` flag. This option add possibility to use previously created `.env.config` file and run whole environment with simple command:
 
-http://localhost:8080/swagger/index.html
+```bash
+./start.sh -l
+```
 
 ### Repo structure
 
 - `src/` - workspace app
-    - `assets` - extra assets required to use inside components - images for example
-    - `componets` - reusable components which create views and app
-    - `styles` - global styles for app
-    - _(optional)_ `hooks` - custom React hooks for app
-    - _(optional)_ `views` - directory to place views which create application and include reusable components
+  - `assets` - extra assets required to use inside components - images for example
+  - `componets` - reusable components which create views and app
+  - `styles` - global styles for app
+  - _(optional)_ `hooks` - custom React hooks for app
+  - _(optional)_ `views` - directory to place views which create application and include reusable components
 
 ### Directory structure
 
@@ -91,10 +71,10 @@ component should have its own directory named the same as the component. The dir
 files:
 
 - `Component/`
-    - `index.ts` - re-exporting anything needed
-    - `Component.tsx` - component code
-    - _(optional)_ `Component.styles.ts` - any styles needed for the component
-    - _(optional)_ `Component.stories.tsx` - Storybook stories exploring different use cases/variants of the component
+  - `index.ts` - re-exporting anything needed
+  - `Component.tsx` - component code
+  - _(optional)_ `Component.styles.ts` - any styles needed for the component
+  - _(optional)_ `Component.stories.tsx` - Storybook stories exploring different use cases/variants of the component
 
 In terms of naming, `PascalCase` should be used for component names and Typescript types. Constants should be named
 using `UPPER_CASE`. Everything else should use `camelCase`.

index.html

@@ -3,18 +3,18 @@
   <head>
     <meta charset="UTF-8" />
     <meta name="viewport" content="width=device-width, initial-scale=1.0" />
-    <meta name="apple-mobile-web-app-capable" content="yes">
+    <meta name="apple-mobile-web-app-capable" content="yes" />
     <link rel="icon" type="image/png" href="/icons/512.png" />
-    <link rel="apple-touch-icon" href="/icons/256.png">
-    <meta name="theme-color" content="#333333">
-    <meta name="msapplication-TileColor" content="#da532c">
-    <link rel="manifest" href="/manifest.json" crossorigin="use-credentials"/>
+    <link rel="apple-touch-icon" href="/icons/256.png" />
+    <meta name="theme-color" content="#333333" />
+    <meta name="msapplication-TileColor" content="#da532c" />
+    <link rel="manifest" href="/manifest.json" crossorigin="use-credentials" />
 
-    <title>Bux wallet</title>
+    <title>SPV wallet</title>
 
-    <link rel="preconnect" href="https://fonts.googleapis.com">
-    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin>
-    <link href="https://fonts.googleapis.com/css2?family=Lato:wght@300;400;700&display=swap" rel="stylesheet">
+    <link rel="preconnect" href="https://fonts.googleapis.com" />
+    <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
+    <link href="https://fonts.googleapis.com/css2?family=Lato:wght@300;400;700&display=swap" rel="stylesheet" />
   </head>
   <body>
     <div id="root"></div>

public/config.default.json

@@ -1,5 +1,5 @@
 {
   "apiUrl": "http://localhost:3002",
-  "paymailDomain": "bux.com",
-  "wsUrl": "ws://localhost:8080/api/websocket"
+  "paymailDomain": "example.com",
+  "wsUrl": "ws://localhost:3002/api/websocket"
 }

public/manifest.json

@@ -1,6 +1,6 @@
 {
-  "name": "Bux wallet",
-  "short_name": "Bux wallet",
+  "name": "SPV wallet frontend",
+  "short_name": "SPV wallet frontend",
   "theme_color": "#9A51FA",
   "background_color": "#6324f9",
   "display": "standalone",