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 <featurename> 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 <featurename>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:
```swift
// MARK: - State
struct <featurename>State: Equatable { }
extension <featurename>State {
// anything but placeholder
}
// MARK: - Action
// ...
```
## Structure of Store & View files
Use the appropriate name for a feature you want to build. The <featurename> must be bare bone of any TCA definition including the folder encapsulating the swift file(s). Example:
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 <featurename>
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<dependencyname>.swift
Utils
<util>.swift
Dependencies
<dependencyname>.swift
Features
<featurename>
<featurename>Store.swift
<featurename>View.swift
Views (optional)
UI Components
<componentname>
<componentname>.swift
Resources
Generated (by swiftgen)
Fonts
<anyotherresourcesgohere>
```
## 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:
- 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.
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:
```swift
<featurename>Flow
<featurename>FlowStore.swift
<featurename>FlowView.swift
Views
<some1st>View.swift
<some2nd>View.swift
<somenth>View.swift
```
## Resources
All project resources should be placed in this folder. Images, fonts, generated files (by swiftgen for example), sounds, assets, string files, ...
[//]: # (These are reference links used in the body of this note and get stripped out when the markdown processor does its job. There is no need to format nicely because it shouldn't be seen. Thanks SO - http://stackoverflow.com/questions/4823468/store-comments-in-markdown-syntax)