Skip to content

Commit c487fb3

Browse files
stephencelismluisbrown
authored andcommitted
Add deprecations to non-view WithViewStore initializers (#1323)
* wip * Deprecate WithViewStore overloads * wip * wip * wip * wip * wip * wip * docs on withviewstore performance * wip * wip * wip Co-authored-by: Brandon Williams <[email protected]> (cherry picked from commit a6fc9a2ed52f8958144a01391fa5e28ae211faa6) # Conflicts: # Sources/ComposableArchitecture/SwiftUI/WithViewStore.swift # Tests/ComposableArchitectureTests/WithViewStoreAppTest.swift
1 parent 8f27c58 commit c487fb3

File tree

4 files changed

+668
-411
lines changed

4 files changed

+668
-411
lines changed

Sources/ComposableArchitecture/Documentation.docc/Articles/Performance.md

Lines changed: 45 additions & 3 deletions
Original file line numberDiff line numberDiff line change
@@ -101,7 +101,7 @@ struct AppView: View {
101101
)
102102
.badge("\(viewStore.unreadActivityCount)")
103103

104-
104+
// ...
105105
}
106106
}
107107
}
@@ -131,7 +131,7 @@ So, instead of performing intense work like this in your reducer:
131131

132132
```swift
133133
case .buttonTapped:
134-
var result =
134+
var result = // ...
135135
for value in someLargeCollection {
136136
// Some intense computation with value
137137
}
@@ -144,7 +144,7 @@ and then delivering the result in an action:
144144
```swift
145145
case .buttonTapped:
146146
return .task {
147-
var result =
147+
var result = // ...
148148
for (index, value) in someLargeCollection.enumerated() {
149149
// Some intense computation with value
150150

@@ -223,3 +223,45 @@ This greatly reduces the bandwidth of actions being sent into the system so that
223223
incurring unnecessary costs for sending actions.
224224

225225
<!--### Memory usage-->
226+
227+
### Compiler performance
228+
229+
In very large SwiftUI applications you may experience degraded compiler performance causing long
230+
compile times, and possibly even compiler failures due to "complex expressions." The
231+
``WithViewStore`` helpers that comes with the library can exacerbate that problem for very complex
232+
views. If you are running into issues using ``WithViewStore`` you can make a small change to your
233+
view to use an `@ObservedObject` directly.
234+
235+
For example, if your view looks like this:
236+
237+
```swift
238+
struct FeatureView: View {
239+
let store: Store<FeatureState, FeatureAction>
240+
241+
var body: some View {
242+
WithViewStore(self.store) { viewStore in
243+
// A large, complex view inside here...
244+
}
245+
}
246+
}
247+
```
248+
249+
...and you start running into compiler troubles, then you can refactor to the following:
250+
251+
```swift
252+
struct FeatureView: View {
253+
let store: Store<FeatureState, FeatureAction>
254+
@ObservedObject var viewStore: ViewStore<FeatureState, FeatureAction>
255+
256+
init(store: Store<FeatureState, FeatureAction>) {
257+
self.store = store
258+
self.viewStore = ViewStore(self.store))
259+
}
260+
261+
var body: some View {
262+
// A large, complex view inside here...
263+
}
264+
}
265+
```
266+
267+
That should greatly improve the compiler's ability to type-check your view.

0 commit comments

Comments
 (0)