CODE_STRUCTURE.md

Code Consistency & Project Structure

In our project the syntax check is done by swiftlint. However, the architecture we use is the TCA (The Composable Architecture) and therefore we need to follow some basic principles and rules to hold structure of the files as well as project. This document describes rules for the code as well as project files/folders structure we agreed on. We encourage you to kindly follow these principles.

Structure of the TCA Store file

For the Store and View as well as folder name we focus on features. So the is the bare bone of the TCA code, uppercased!

Store file

The TCA consists of 5 blocks (state, action, environment, reducer and store). The TCA code lives in the Store file. We defined the following order of sections in this file:

1. Typealiases for the Reducer, Store and a ViewStore.
2. State
3. Action
4. Environment - always present even when no dependencies are defined = never use Void
5. Reducer holding private Hashable Ids, always use static let default reducer. Try to avoid default: return .none for the actions, we want the switch exhaustiveness check.
6. Store
7. Viewstore
8. Placeholders

Any extension needed is defined under the relevant section except placeholders, those are separated at the very end of the file. Example:

// MARK: - State

struct <feature name>State: Equatable { }

extension <feature name>State {
    // anything but placeholder
}

// MARK: - Action
// ...

Structure of Store & View files

Use the appropriate name for a feature you want to build. The must be bare bone of any TCA definition including the folder encapsulating the swift file(s). Example:

// Project structure
// Folder <feature name> with following files:

// <feature name>Store.swift
struct <feature name>State: Equatable { }
enum <feature name>Action: Equatable { }
struct <feature name>Environment

// <feature name>View.swift
struct <feature name>: View {
    let store: <feature name>Store
    
    var body: some View {
        WithViewStore(store) { viewStore in EmptyView() }
    }
}

struct <feature name>_Previews: PreviewProvider {
    static var previews: some View {
    <feature name>(store: .placeholder)
    }
}

Do not omit Previews!

Navigation

Navigation is done using routes. Such mechanism consists of Route definition + state and Route action to update the state.

struct <feature>State
enum Route {
    case <route name>
}
var route: Route?
}

enum <feature>Action {
    case updateRoute(<feature>State.Route?)
}

XCode Template

We created a TCA template that automatically prepares the TCA files and code with the rules defined in this document. You can download it here.

To add them to Xcode, follow the next steps:

1. open Finder
2. press cmd + shift + G
3. paste /Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File Templates
4. copy paste the TCA.xctemplate to the MultiPlatform/Source/

The template is customizable and consists of 3 sections:

1. TCA Store text field. This is essentially the
2. View selector of either a. Empty (= TCA file with no navigation included) b. Navigation (= TCA file with the navigation)
3. Reducer selector of either a. Standalone (= only simple default reducer is created) b. Combined (= the default reducer is created so it combines more reducers)
4. Checkbox which allows you to create also a View file if requested.

Project Structure

The project follows the structure detailed below:

Models
    <model>.swift
Wrappers
    Wrapped<dependency name>.swift
Utils
    <util>.swift
Dependencies
    <dependency name>.swift
Features
    <feature name>
        <feature name>Store.swift
        <feature name>View.swift
        Views (optional)
UI Components
    <component name>
        <component name>.swift
Resources
    Generated (by swiftgen)
    Fonts
    <any other resources go here>

Models

Here are the models used in the project, usually data containers shared across several places. Examples:

• Transaction struct - holding the data for the transaction
• StoredWallet struct - holding the secured and sensitive data for the wallet

Wrappers

Here are the wrapped modules either from the SDK, iOS itself or wallet custom modules. Purpose of wrappers is to provide live implementation and other versions used testing purposes, usually one of the following:

• mock - mocked data
• throwing - throwing errors
• test - specific setup for particular tests

Examples of the wrappers:

• SDK: Mnemonic, DerivingTool, SDKSynchronizer, ...
• iOS: FileManager, UserDefaults, NotificationCenter, ...
• wallet: DatabaseFiles, WalletStorage, ...

Utils

Here are the utilities used in the project. Usually helpers or extensions of the build in types. Examples:

• helpers: navigation links, bindings, view modifiers, ...
• types: String extensions for the conversions, UInt/Int64 extensions to handle balance computations, etc.```

Dependencies

Modules used as dependencies by the reducers are located here. Some dependencies are already living in the SDK and only a wrapper is implemented (stored in the wrappers folder) for it. Sometimes the dependency is implemented in a way that it doesn't need to be wrapped (typically it uses some wrapped helper). In that case, the live vs. mocked static instances are implemented directly within the same file as the dependency.

Features vs. UI Components

We distinguish between smaller building blocks used in the composed complex UIs vs. screens and flows - understand features. Essentially we talk about two topics:

1. Features: typically views representing entire screeens, the whole flows, complex UIs and business logic that are usually not shared or used many times.
2. UI Components: smaller building blocks typically used across the application and features, like custom controls (buttons, input fields) or visual elements. Even when used just once, the nature of a UI component is to be reused so it's not forming standalone feature.

Examples:

• features: Send Flow, Onboarding Flow, Settings Screen, Scan Screen, Profile Screen, ...
• UI Components: buttons, chips, button styles, view modifiers, drawer, custom textfields, shapes, ...

When implementing something new, just ask yourself "Am I building something that can be shared and used several times or am I building a standalone feature?".

In case of a flow feature the following structure is used:

<feature name>Flow
    <feature name>FlowStore.swift
    <feature name>FlowView.swift
    Views
        <some 1st>View.swift
        <some 2nd>View.swift
        <some nth>View.swift

Resources

All project resources should be placed in this folder. Images, fonts, generated files (by swiftgen for example), sounds, assets, string files, ...