Fix typos (#507)
This commit is contained in:
parent
5c306a54a6
commit
a16de79a45
|
@ -36,7 +36,7 @@ Use the appropriate name for a feature you want to build. The <feature name> mus
|
|||
|
||||
```swift
|
||||
// Project structure
|
||||
// Folder <feature name> woth following files:
|
||||
// Folder <feature name> with following files:
|
||||
|
||||
// <feature name>Store.swift
|
||||
struct <feature name>State: Equatable { }
|
||||
|
|
|
@ -45,7 +45,7 @@ This information will help us review and fix your issue faster.
|
|||
|
||||
## Pull Requests
|
||||
|
||||
We **love** pull requests!
|
||||
We **love** pull requests!
|
||||
|
||||
All contributions _will_ be licensed under the MIT license.
|
||||
|
||||
|
@ -76,7 +76,7 @@ in the project's lifetime in a given context. A good record of the changes that
|
|||
occurred during the project's life helps to guarantee that it can outlive its
|
||||
stakeholders no matter how foundational or crucial these individuals (or
|
||||
groups) were. As any reading material, it is best appreciated and comprehended
|
||||
when there's a visible structure that readers can follow and reason about.
|
||||
when there's a visible structure that readers can follow and reason about.
|
||||
|
||||
For that we've defined a structure for commit messages that all contributors must
|
||||
follow to maintain coherence on the project's commit log. The proposed format
|
||||
|
@ -86,29 +86,29 @@ has been inspired by [this great article](https://cbea.ms/git-commit/)
|
|||
### Preparing to contribute to the project
|
||||
The first thing you should look for is an existing issue. It is possible
|
||||
that the contribution you are planning to work on was already discussed
|
||||
by other users and/or contributors in the past. If not present, file an
|
||||
issue following the criteria described in the preceeding sections.
|
||||
by other users and/or contributors in the past. If not present, file an
|
||||
issue following the criteria described in the preceding sections.
|
||||
|
||||
Every contribution must reference an existing Issue. This issue is important
|
||||
since it will be directly referenced in the title of your commit.
|
||||
since it will be directly referenced in the title of your commit.
|
||||
|
||||
Although we prefer small PR's. We encourage our contributors to use Squash
|
||||
commits extensively. Maintainers prefer avoiding _merge commits_ when possible.
|
||||
commits extensively. Maintainers prefer avoiding _merge commits_ when possible.
|
||||
It is very much likely that _if accepted_, your contribution will be _squash merged_.
|
||||
|
||||
When squashing commits, use your best judgement. In some situations, a refactoring may
|
||||
be done before actual behavior changes are implemented. It is reasonable to keep such
|
||||
a refactoring as a separate commit as it both makes review easier and allows for
|
||||
a refactoring as a separate commit as it both makes review easier and allows for
|
||||
these refactoring commit SHAs to be added to `.git-blame-ignore-revs`.
|
||||
|
||||
### Structuring a PR Commit
|
||||
|
||||
#### Commit Title
|
||||
The first line of your commit message constitutes its _title_. Maintainers will
|
||||
The first line of your commit message constitutes its _title_. Maintainers will
|
||||
use commit titles to create release notes. Your contribution will be featured
|
||||
in a public release of the project. Think of it as a newspaper headline. It
|
||||
should be descriptive and provide the reader a broad idea of what the commit is
|
||||
about. You can use a related github issue if it matches this criterion.
|
||||
about. You can use a related github issue if it matches this criterion.
|
||||
|
||||
**Preferred title format**
|
||||
|
||||
|
@ -155,7 +155,7 @@ Date: some date
|
|||
Add //TODO comment with the permanent fix for the problem
|
||||
````
|
||||
|
||||
When you open a PR with a commit like this one the first line will land on the GUI's title field,
|
||||
When you open a PR with a commit like this one the first line will land on the GUI's title field,
|
||||
and the body will be added as the description of the PR.
|
||||
|
||||
Adding the text `Closes #{issue_number}` will tell GitHub to close the issue when the PR is merged.
|
||||
|
|
|
@ -24,12 +24,12 @@ extension LocalAuthenticationClient: DependencyKey {
|
|||
if context.canEvaluatePolicy(.deviceOwnerAuthentication, error: &error) {
|
||||
return try await context.evaluatePolicy(.deviceOwnerAuthentication, localizedReason: reason)
|
||||
} else {
|
||||
/// No local authentication available, user's device is not protected, fallback to allow access to sensetive content
|
||||
/// No local authentication available, user's device is not protected, fallback to allow access to sensitive content
|
||||
return true
|
||||
}
|
||||
}
|
||||
} catch {
|
||||
/// Some interuption occured during the authentication, access to the sensitive content is therefore forbiden
|
||||
/// Some interruption occurred during the authentication, access to the sensitive content is therefore forbidden
|
||||
return false
|
||||
}
|
||||
}
|
||||
|
|
|
@ -9,8 +9,8 @@ import Foundation
|
|||
import ComposableArchitecture
|
||||
|
||||
/// `UserDefaults` is thread-safe class. Because of that we can mark it as `Sendable` on our own. If it's marked as `Sendable` in `Foundation` in
|
||||
/// future we can simply remove this line and be ok. This is probably simpliest and easiest way how to fix warnings about `UserDefaults` not being
|
||||
/// sendable.
|
||||
/// future we can simply remove this line and be ok. This is probably the simplest and easiest way how to fix warnings about `UserDefaults` not
|
||||
/// being sendable.
|
||||
extension UserDefaults: @unchecked Sendable { }
|
||||
|
||||
extension DependencyValues {
|
||||
|
|
|
@ -48,7 +48,7 @@ struct WalletStorage {
|
|||
language: MnemonicLanguageType = .english,
|
||||
hasUserPassedPhraseBackupTest: Bool = false
|
||||
) throws {
|
||||
// Future-proof of the bundle to potentialy avoid migration. We enforce english mnemonic.
|
||||
// Future-proof of the bundle to potentially avoid migration. We enforce english mnemonic.
|
||||
guard language == .english else {
|
||||
throw WalletStorageError.unsupportedLanguage(language)
|
||||
}
|
||||
|
|
|
@ -33,7 +33,7 @@ struct WalletStorageClient {
|
|||
/// - Throws:
|
||||
/// - `WalletStorageError.unsupportedLanguage`: when mnemonic's language is anything other than English
|
||||
/// - `WalletStorageError.alreadyImported` when valid wallet is already in the storage
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occured
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occurred
|
||||
let importWallet: (String, BlockHeight?, MnemonicLanguageType, Bool) throws -> Void
|
||||
|
||||
/// Load the representation of the wallet from the persistent and secured storage.
|
||||
|
@ -41,13 +41,13 @@ struct WalletStorageClient {
|
|||
/// - Returns: the representation of the wallet from the persistent and secured storage.
|
||||
/// - Throws:
|
||||
/// - `WalletStorageError.uninitializedWallet`: when no wallet's data is found in the keychain.
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occured.
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occurred.
|
||||
/// - `WalletStorageError.unsupportedVersion` when wallet's version stored in the keychain is outdated.
|
||||
var exportWallet: () throws -> StoredWallet
|
||||
|
||||
/// Check if the wallet representation `StoredWallet` is present in the persistent storage.
|
||||
///
|
||||
/// - Returns: the information wheather some wallet is stored or is not available
|
||||
/// - Returns: the information whether some wallet is stored or is not available
|
||||
var areKeysPresent: () throws -> Bool
|
||||
|
||||
/// Update the birthday in the securely stored wallet.
|
||||
|
@ -56,16 +56,16 @@ struct WalletStorageClient {
|
|||
/// - birthday: BlockHeight from SDK
|
||||
/// - Throws:
|
||||
/// - `WalletStorage.KeychainError.encoding`: when encoding the wallet's data failed.
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occured.
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occurred.
|
||||
let updateBirthday: (BlockHeight) throws -> Void
|
||||
|
||||
/// Update the information that user has passed the recovery phrase backup test.
|
||||
/// The fuction doesn't take any parameters, default value is the user hasn't passed the test
|
||||
/// and this fucntion only sets the true = fact user passed.
|
||||
/// The function doesn't take any parameters, default value is the user hasn't passed the test
|
||||
/// and this function only sets the true = fact user passed.
|
||||
///
|
||||
/// - Throws:
|
||||
/// - `WalletStorage.KeychainError.encoding`: when encoding the wallet's data failed.
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occured.
|
||||
/// - `WalletStorageError.storageError` when some unrecognized error occurred.
|
||||
let markUserPassedPhraseBackupTest: () throws -> Void
|
||||
|
||||
/// Use carefully: deletes the stored wallet.
|
||||
|
|
|
@ -15,7 +15,7 @@ struct BalanceBreakdownReducer: ReducerProtocol {
|
|||
private enum CancelId {}
|
||||
|
||||
struct State: Equatable {
|
||||
var autoShieldingTreshold: Zatoshi
|
||||
var autoShieldingThreshold: Zatoshi
|
||||
var latestBlock: String
|
||||
var shieldedBalance: WalletBalance
|
||||
var transparentBalance: WalletBalance
|
||||
|
@ -78,7 +78,7 @@ struct BalanceBreakdownReducer: ReducerProtocol {
|
|||
|
||||
extension BalanceBreakdownReducer.State {
|
||||
static let placeholder = BalanceBreakdownReducer.State(
|
||||
autoShieldingTreshold: Zatoshi(1_000_000),
|
||||
autoShieldingThreshold: Zatoshi(1_000_000),
|
||||
latestBlock: "unknown",
|
||||
shieldedBalance: WalletBalance.zero,
|
||||
transparentBalance: WalletBalance.zero
|
||||
|
|
|
@ -33,7 +33,7 @@ struct BalanceBreakdownView: View {
|
|||
|
||||
HStack {
|
||||
Spacer()
|
||||
Text("Auto Shielding Treshold: \(viewStore.autoShieldingTreshold.decimalString()) ZEC")
|
||||
Text("Auto Shielding Threshold: \(viewStore.autoShieldingThreshold.decimalString()) ZEC")
|
||||
}
|
||||
.padding(.horizontal, 50)
|
||||
}
|
||||
|
|
|
@ -85,7 +85,7 @@ struct RecoveryPhraseValidationFlowView: View {
|
|||
}
|
||||
|
||||
/// Following computations are necessary to handle properly sizing and positioning of elements
|
||||
/// on different devices (apects). iPhone SE and iPhone 8 are similar aspect family devices
|
||||
/// on different devices (aspects). iPhone SE and iPhone 8 are similar aspect family devices
|
||||
/// while iPhone X, 11, etc are different family devices, capable to use more of the space.
|
||||
extension RecoveryPhraseValidationFlowView {
|
||||
func circularFrameUniformSize(width: CGFloat, height: CGFloat) -> CGFloat {
|
||||
|
|
|
@ -76,7 +76,7 @@ struct RecoveryPhraseBackupFailedView: View {
|
|||
}
|
||||
|
||||
/// Following computations are necessary to handle properly sizing and positioning of elements
|
||||
/// on different devices (apects). iPhone SE and iPhone 8 are similar aspect family devices
|
||||
/// on different devices (aspects). iPhone SE and iPhone 8 are similar aspect family devices
|
||||
/// while iPhone X, 11, etc are different family devices, capable to use more of the space.
|
||||
extension RecoveryPhraseBackupFailedView {
|
||||
func circularFrameUniformSize(width: CGFloat, height: CGFloat) -> CGFloat {
|
||||
|
|
|
@ -77,7 +77,7 @@ struct RecoveryPhraseBackupSucceededView: View {
|
|||
}
|
||||
|
||||
/// Following computations are necessary to handle properly sizing and positioning of elements
|
||||
/// on different devices (apects). iPhone SE and iPhone 8 are similar aspect family devices
|
||||
/// on different devices (aspects). iPhone SE and iPhone 8 are similar aspect family devices
|
||||
/// while iPhone X, 11, etc are different family devices, capable to use more of the space.
|
||||
extension RecoveryPhraseBackupSucceededView {
|
||||
func circularFrameUniformSize(width: CGFloat, height: CGFloat) -> CGFloat {
|
||||
|
|
|
@ -8,7 +8,7 @@
|
|||
import ComposableArchitecture
|
||||
|
||||
/// In this file is a collection of helpers that control all state and action related operations
|
||||
/// for the `RootReducer` with a connection to the app/wallet initalization and erasure of the wallet.
|
||||
/// for the `RootReducer` with a connection to the app/wallet initialization and erasure of the wallet.
|
||||
extension RootReducer {
|
||||
enum InitializationAction: Equatable {
|
||||
case appDelegate(AppDelegateAction)
|
||||
|
|
|
@ -7,8 +7,8 @@
|
|||
|
||||
import SwiftUI
|
||||
|
||||
/// Neumorphic design is charasterictical with two shadows (light & dark) around the view
|
||||
/// Appereance in our case is influenced by two parameters:
|
||||
/// Neumorphic design is characteristical with two shadows (light & dark) around the view
|
||||
/// Appearance in our case is influenced by two parameters:
|
||||
/// - Parameters:
|
||||
/// - colorScheme: The light is using full neumorphic design while dark is limited to soft shadow only
|
||||
/// - isPressed: When the button is pressed, there are different behaviours for light vs. dark colorScheme
|
||||
|
@ -40,8 +40,8 @@ fileprivate struct Neumorphic: ViewModifier {
|
|||
}
|
||||
}
|
||||
|
||||
/// Neumorphic design is charasterictical with two shadows (light & dark) around the button
|
||||
/// Appereance in our case is influenced by two parameters:
|
||||
/// Neumorphic design is characteristical with two shadows (light & dark) around the button
|
||||
/// Appearance in our case is influenced by two parameters:
|
||||
/// - Parameters:
|
||||
/// - colorScheme: The light is using full neumorphic design while dark is limited to soft shadow only
|
||||
/// - isPressed: When the button is pressed, there are different behaviours for light vs. dark colorScheme
|
||||
|
|
|
@ -1,5 +1,5 @@
|
|||
//
|
||||
// Array+Chuncked.swift
|
||||
// Array+Chunked.swift
|
||||
// secant-testnet
|
||||
//
|
||||
// Created by Lukáš Korba on 12.05.2022.
|
||||
|
|
|
@ -10,8 +10,8 @@ import XCTest
|
|||
import ComposableArchitecture
|
||||
|
||||
class AppInitializationTests: XCTestCase {
|
||||
/// This integration test starts with finishing the app launch and triggering bunch of initialization proceedures.
|
||||
/// 1. The app calls .checkWalletInitialization delayed by 0.02 seconds to ensure keychain is successfuly operational.
|
||||
/// This integration test starts with finishing the app launch and triggering bunch of initialization procedures.
|
||||
/// 1. The app calls .checkWalletInitialization delayed by 0.02 seconds to ensure keychain is successfully operational.
|
||||
/// 2. The .respondToWalletInitializationState is triggered to decide the state of the wallet.
|
||||
/// 3. The .initializeSDK is triggered to set the state of the app and preparing the synchronizer.
|
||||
/// 4. The .checkBackupPhraseValidation is triggered to check the validation state.
|
||||
|
@ -130,7 +130,7 @@ class AppInitializationTests: XCTestCase {
|
|||
}
|
||||
|
||||
/// Integration test validating the side effects work together properly when no wallet is stored but database files are present.
|
||||
/// 1. The app calls .checkWalletInitialization delayed by 0.02 seconds to ensure keychain is successfuly operational.
|
||||
/// 1. The app calls .checkWalletInitialization delayed by 0.02 seconds to ensure keychain is successfully operational.
|
||||
/// 2. The .respondToWalletInitializationState is triggered to decide the state of the wallet.
|
||||
func testDidFinishLaunching_to_KeysMissing() throws {
|
||||
// setup the store and environment to be fully mocked
|
||||
|
@ -162,9 +162,9 @@ class AppInitializationTests: XCTestCase {
|
|||
}
|
||||
|
||||
/// Integration test validating the side effects work together properly when no wallet is stored and no database files are present.
|
||||
/// 1. The app calls .checkWalletInitialization delayed by 0.02 seconds to ensure keychain is successfuly operational.
|
||||
/// 1. The app calls .checkWalletInitialization delayed by 0.02 seconds to ensure keychain is successfully operational.
|
||||
/// 2. The .respondToWalletInitializationState is triggered to decide the state of the wallet.
|
||||
/// 3. The wallet is no prosent, onboarding flow is triggered.
|
||||
/// 3. The wallet is not present, onboarding flow is triggered.
|
||||
func testDidFinishLaunching_to_Uninitialized() throws {
|
||||
// setup the store and environment to be fully mocked
|
||||
let testScheduler = DispatchQueue.test
|
||||
|
|
|
@ -56,7 +56,7 @@ class SendTests: XCTestCase {
|
|||
|
||||
// simulate the sending confirmation button to be pressed
|
||||
_ = await store.send(.sendConfirmationPressed) { state in
|
||||
// once sending is confirmed, the attemts to try to send again by pressing the button
|
||||
// once sending is confirmed, the attempts to try to send again by pressing the button
|
||||
// needs to be eliminated, indicated by the flag `isSendingTransaction`, need to be true
|
||||
state.isSendingTransaction = true
|
||||
}
|
||||
|
@ -124,7 +124,7 @@ class SendTests: XCTestCase {
|
|||
|
||||
// simulate the sending confirmation button to be pressed
|
||||
_ = await store.send(.sendConfirmationPressed) { state in
|
||||
// once sending is confirmed, the attemts to try to send again by pressing the button
|
||||
// once sending is confirmed, the attempts to try to send again by pressing the button
|
||||
// needs to be eliminated, indicated by the flag `isSendingTransaction`, need to be true
|
||||
state.isSendingTransaction = true
|
||||
}
|
||||
|
@ -190,7 +190,7 @@ class SendTests: XCTestCase {
|
|||
|
||||
// simulate the sending confirmation button to be pressed
|
||||
_ = await store.send(.sendConfirmationPressed) { state in
|
||||
// once sending is confirmed, the attemts to try to send again by pressing the button
|
||||
// once sending is confirmed, the attempts to try to send again by pressing the button
|
||||
// needs to be eliminated, indicated by the flag `isSendingTransaction`, need to be true
|
||||
state.isSendingTransaction = true
|
||||
}
|
||||
|
|
|
@ -15,7 +15,7 @@ class BalanceBreakdownSnapshotTests: XCTestCase {
|
|||
func testBalanceBreakdownSnapshot() throws {
|
||||
let store = Store(
|
||||
initialState: BalanceBreakdownReducer.State(
|
||||
autoShieldingTreshold: Zatoshi(1_000_000),
|
||||
autoShieldingThreshold: Zatoshi(1_000_000),
|
||||
latestBlock: "unknown",
|
||||
shieldedBalance: WalletBalance(verified: Zatoshi(123_000_000_000), total: Zatoshi(123_000_000_000)),
|
||||
transparentBalance: WalletBalance(verified: Zatoshi(850_000_000), total: Zatoshi(850_000_000))
|
||||
|
|
|
@ -34,7 +34,7 @@ class WalletStorageTests: XCTestCase {
|
|||
deleteData(forKey: WalletStorage.Constants.zcashStoredWallet)
|
||||
}
|
||||
|
||||
func testWalletStoredSuccessfuly() throws {
|
||||
func testWalletStoredSuccessfully() throws {
|
||||
do {
|
||||
try storage.importWallet(bip39: seedPhrase, birthday: birthday)
|
||||
guard let data = data(forKey: WalletStorage.Constants.zcashStoredWallet) else {
|
||||
|
@ -48,7 +48,7 @@ class WalletStorageTests: XCTestCase {
|
|||
XCTAssertEqual(birthday, walletReceived.birthday, "Keychain: stored birthday and retrieved one must be the same.")
|
||||
XCTAssertEqual(seedPhrase, walletReceived.seedPhrase, "Keychain: stored seed phrase and retrieved one must be the same.")
|
||||
} catch let err {
|
||||
XCTFail("Keychain: no error is expected for `testWalletStoredSucessfuly` but received. \(err)")
|
||||
XCTFail("Keychain: no error is expected for `testWalletStoredSuccessfully` but received. \(err)")
|
||||
}
|
||||
}
|
||||
|
||||
|
|
|
@ -78,7 +78,7 @@ class ZatoshiTests: XCTestCase {
|
|||
XCTAssertEqual(
|
||||
result4.amount,
|
||||
Zatoshi.Constants.maxZatoshi,
|
||||
"Zatoshi tests: `testAddingZatoshi` the value is expected to be clapmed to upper bound but it's \(result4.amount)"
|
||||
"Zatoshi tests: `testAddingZatoshi` the value is expected to be clamped to upper bound but it's \(result4.amount)"
|
||||
)
|
||||
}
|
||||
|
||||
|
@ -119,7 +119,7 @@ class ZatoshiTests: XCTestCase {
|
|||
XCTAssertEqual(
|
||||
result4.amount,
|
||||
-Zatoshi.Constants.maxZatoshi,
|
||||
"Zatoshi tests: `testSubtractingZatoshi` the value is expected to be clapmed to lower bound but it's \(result4.amount)"
|
||||
"Zatoshi tests: `testSubtractingZatoshi` the value is expected to be clamped to lower bound but it's \(result4.amount)"
|
||||
)
|
||||
}
|
||||
|
||||
|
@ -131,7 +131,7 @@ class ZatoshiTests: XCTestCase {
|
|||
// but decimalString is rounding it to maximumFractionDigits set to be 8
|
||||
|
||||
// We can't compare it to double value 1.42857143 (or even Decimal(1.42857143))
|
||||
// so we convert it to string, in that case we are prooving it to be rendered
|
||||
// so we convert it to string, in that case we are proving it to be rendered
|
||||
// to the user exactly the way we want
|
||||
XCTAssertEqual(
|
||||
number.decimalString(formatter: usNumberFormatter),
|
||||
|
|
Loading…
Reference in New Issue