When should we use WithViewStore vs an @ObservedObject viewStore?

[mycroftcanner]

The documentation says there is an issue with GeometryReader but it doesn't mention what are the performance implications and if there are special considerations for each situation.

I keep discovering new little things...

In isowords, I see :

    self.viewStore = ViewStore(self.store, removeDuplicates: ==)

When does it make sense to use removeDuplicates?

Has anyone benchmarked using WithViewStore vs @ObservedObject ?

[stephencelis]

That removeDuplicates: == can probably go! The initializer that doesn't take that parameter is constrained to Equatable and calls == under the hood:

swift-composable-architecture/Sources/ComposableArchitecture/SwiftUI/WithViewStore.swift

Lines 125 to 140 in 1437951

	extension WithViewStore where State: Equatable, Content: View {
	/// Initializes a structure that transforms a store into an observable view store in order to
	/// compute views from equatable store state.
	///
	/// - Parameters:
	/// - store: A store of equatable state.
	/// - content: A function that can generate content from a view store.
	public init(
	_ store: Store<State, Action>,
	file: StaticString = #fileID,
	line: UInt = #line,
	@ViewBuilder content: @escaping (ViewStore<State, Action>) -> Content
	) {
	self.init(store, removeDuplicates: ==, file: file, line: line, content: content)
	}
	}

When does it make sense to use removeDuplicates?

Whenever you want to perform a custom equatable check, or whenever you're dealing with types that aren't equatable (like tuples).

Has anyone benchmarked using WithViewStore vs @ObservedObject ?

WithViewStore is a view that holds onto an @ObservedObject under the hood. The main difference is that WithViewStore performs an equatable check (via that removeDuplicates parameter) to prevent recomputing the body when state hasn't changed). This means more calls to ==, and fewer calls to body. If == is expensive, WithViewStore may incur a performance penalty. If body is expensive, WithViewStore may be more performant by default. You can also pass removeDuplicates: { _, _ in false } to WithViewStore to opt out of the equatable check, at which point it should be equivalent, functionally and performance-wise.