Ecosyste.ms: Awesome
An open API service indexing awesome lists of open source software.
https://github.com/VAnsimov/MVI-SwiftUI
https://github.com/VAnsimov/MVI-SwiftUI
Last synced: 3 months ago
JSON representation
- Host: GitHub
- URL: https://github.com/VAnsimov/MVI-SwiftUI
- Owner: VAnsimov
- Created: 2021-09-16T05:53:22.000Z (about 3 years ago)
- Default Branch: develop
- Last Pushed: 2024-06-13T14:13:35.000Z (5 months ago)
- Last Synced: 2024-06-13T17:10:41.077Z (5 months ago)
- Language: Swift
- Size: 1.44 MB
- Stars: 61
- Watchers: 1
- Forks: 5
- Open Issues: 0
-
Metadata Files:
- Readme: README.md
Awesome Lists containing this project
- fucking-open-source-ios-apps - MVI-SwiftUI
README
# SwiftUI and MVI
#### Publication: [medium.com/@vyacheslavansimov/swiftui-and-mvi-3acac8d4416a](https://medium.com/@vyacheslavansimov/swiftui-and-mvi-3acac8d4416a)
## MVI — brief history and principle of operation
This pattern was first described by JavaScript developer Andre Staltz. The general principles can be found [here](https://staltz.com/unidirectional-user-interface-architectures.html)
![](README_sources/image_001.jpeg)
- Intent: function from Observable of user events to Observable of “actions”
- Model: function from Observable of actions to Observable of state
- View: function from Observable of state to Observable of rendering
Custom element: subsection of the rendering which is in itself a UI program. May be implemented as MVI, or as a Web Component. Is optional to use in a View.MVI has a reactive approach. Each module (function) expects some event, and after receiving and processing it, it passes this event to the next module. It turns out an unidirectional flow.
In the mobile app the diagram looks very close to the original with only minor changes:
![](README_sources/image_002.png)
- Intent receives an event from View and communicates with the business logic
- Model receives data from Intent and prepares it for display. The Model also keeps the current state of the View.
- View displays the prepared data.To provide a unidirectional data flow, you need to make sure that the View has a reference to the Intent, the Intent has a reference to the Model, which in turn has a reference to the View.
The main problem in implementing this approach in SwiftUI is View. View is a structure and Model cannot have references to View. To solve this problem, you can introduce an additional layer Container, which main task is to keep references to Intent and Model, and provide accessibility to the layers so that the unidirectional data flow is truly unidirectional.
It sounds complicated, but it is quite simple in practice.## MVI
Container is independent of the life cycle of the View because it is @StateObject. Every time the View is reinitialization, Intent and Model remain the same.
![](README_sources/image_003.png)
There is a unidirectional data flow between the modules.
1) View receives the user's event.
2) Intent receives an event from View and communicates with the business logic
3) Model receives data from Intent and prepares it for display. The Model also keeps the current state of the View.
4) View displays the prepared data.![](README_sources/image_004.png)
# Templates for Xcode
### xctemplate
The template can be found in Templates-for-Xcode/xctemplate
Add the file *.xctemplate to the folder:
/Applications/Xcode.app/Contents/Developer/Library/Xcode/Templates/File TemplatesThe template can be found in the Xcode menu
File -> New -> File...### Router
The router is in Swift Package Manager and can be copied and reused in your projects
# How to use Router?
### Implementation Router
Below is the most complete version, if you don't need something, you don't have to write it.
**Step 1**: Create a `enum` for the list of screens the View will open to. It should implement the `RouterScreenProtocol` protocol.
```swift
enum SomeRouterScreenType: RouterScreenProtocol {case productScreen(id: UUID)
}
```**Step 2**: Create a `enum` for the list of alerts that the View will display. It should implement the `RouterAlertScreenProtocol` protocol.
```swift
enum SomeRouterAlertType: RouterAlertScreenProtocol {case error(title: String, message: String)
}
```**Step 3**: We need to implement RouterModifierProtocol is ViewModifier in your router.
```swift
struct SomeRouter: RouterModifierProtocol {// If you don't need Alerts, you can use `RouterDefaultAlert`. Example: RouterEvents
// If you do not need to go to other screens, then use `RouterEmptyScreen`. Example: RouterEvents
let routerEvents: RouterEvents
}
```**Step 4**: Implement the functions getScreenPresentationType(for:), getScreen(for:), onScreenDismiss(type:) in your router
```swift
extension SomeRouter {// Optional
func getScreenPresentationType(for type: SomeRouterScreenType) -> RouterScreenPresentationType {
.fullScreenCover
}// Optional
@ViewBuilder
func getScreen(for type: SomeRouterScreenType) -> some View {
switch type {
case let .productScreen(id):
Text("Product Screen View: \(id.uuidString)")
}
}// Optional
func onScreenDismiss(type: SomeRouterScreenType) {}
}
```**Step 5**: Implement the functions getAlertTitle(for:), getAlertMessage(for:), getAlertActions(for:) in your router
```swift
extension SomeRouter {// Optional
func getAlertTitle(for type: SomeRouterAlertType) -> Text? {
switch type {
case let .error(title, _):
Text(title)
}
}// Optional
@ViewBuilder
func geteAlertMessage(for type: SomeRouterAlertType) -> some View {
switch type {
case let .error(_, message):
Text(message)
}
}// Optional
@ViewBuilder
func getAlertActions(for type: SomeRouterAlertType) -> some View {
Button("Yes", role: .none, action: {
...
})
Button("Cancel", role: .cancel, action: {})
}
}
```### Use Router
How do I use the router? You can see this in the following example:
```swift
struct SomeView: View {let routerEvents = RouterEvents()
var body: some View {
Text("Hello, World!")
.modifier(SomeRouter(routerEvents: routerEvents))
.onAppear {
routerEvents.routeTo(.group(id: UUID()))
}
}
}
```# Maintainers
* [Vyacheslav Ansimov](https://www.linkedin.com/in/vansimov/)