Views in ForEach recomputed upon element addition

[bohdany-cricut]

Description

TCA 1.9.2 (also tested on 1.7.3 and main).

When elements are added to an IdentifiedArray that drives ForEach, every View inside the loop gets recomputed. This behavior is present in both iOS 17+ and earlier versions (with WithPerceptionTracking). I have also tried the old method - using WithViewStore, ForEachStore, and State not being @ObservableState, but it doesn't seem to make any difference.

In vanilla SwiftUI, this does not happen in iOS 17+ with the @Observable macro. Only views corresponding to added elements get recomputed. However, it does happen in vanilla SwiftUI on iOS <17 with the ObservableObject protocol and @Published.

Please refer to the videos below::
Vanilla SwiftUI with @Observable macro:
https://github.com/pointfreeco/swift-composable-architecture/assets/118171669/18370627-708f-4991-8a54-aefd3a846a60

TCA:
https://github.com/pointfreeco/swift-composable-architecture/assets/118171669/4e7bf5b9-aa85-4614-b1dd-9403adcfce1c

Sidenote:

I am using TCA in a large application with lists containing dozens of heavy views, and adding elements to the driving array while scrolling causes hangs because each view gets recomputed.

Checklist

• I have determined whether this bug is also reproducible in a vanilla SwiftUI project.
• If possible, I've reproduced the issue using the main branch of this package.
• This issue hasn't been addressed in an existing GitHub issue or discussion.

Expected behavior

Views inside ForEach don't get recomputed, as in vanilla SwiftUI.
Ideally on iOS <17 as well.

Actual behavior

Every view that is placed in a ForEach gets recomputed when elements are added to the corresponding array.

Steps to reproduce

Here is a sample project where this issue reproduces.
https://github.com/bohdany-cricut/TCA_Perception

1. Open Project
2. Uncomment either TCA or SwiftUI version of the view in the TCA_PerceptionApp.swift
3. Run the App
4. Observe View updates

The Composable Architecture version information

1.9.2

Destination operating system

iOS 17.2, iOS 15.0

Xcode version information

Version 15.3 (15E204a)

Swift Compiler version information

swift-driver version: 1.90.11.1 Apple Swift version 5.10 (swiftlang-5.10.0.13 clang-1500.3.9.4)

[mbrandonw]

Hi @bohdany-cricut, thanks for bringing this up! It is true this happens in TCA today, and we have plans to address it, but it's going to take time to get there.

Luckily this only affects IdentifiedArray (since it is not observable itself) and further only affects the rows visible on the screen. So hopefully it isn't that big of a deal.

I'm going to convert this to a discussion since it can't be addressed right away, but do know that we are working towards a world where this will be possible. Please feel free to continue the conversation over there if you want.

[ryu1sazae]

@mbrandonw
Hi, I have a same issue when changing the favorite status of the element of IdentifiedArray. Are there some workarounds to avoid this issue? Thanks.

[mbrandonw]

Hi @ryu1sazae, can you describe the exact issue you are having? Is there a problem with the visible rows re-computing their bodies?

[freak4pc]

Luckily this only affects IdentifiedArray (since it is not observable itself) and further only affects the rows visible on the screen. So hopefully it isn't that big of a deal.

Trying to understand this statement - isn't IdentifiedArray the standard? What we are recommended to use?

Are there actually other options? Can we easily use ForEach with all the automatically generated niceties (IdentifiedAction for example for child-parent communication) without it? ...

[dwirandyh]

hi @mbrandonw may i know about updated information about this issue? maybe there is workaround or fix that we can use?

[freak4pc]

Was there ever any progress made on this ?

I'm wondering if I should drop down to regular arrays even though IdentifiedCollections are very comfortable

[ba01ei]

further only affects the rows visible on the screen

I realized that while in the built executable it only affects rows visible on the screen, in Xcode Preview it does impact all rows including the ones off screen. Could this be a risk (e.g. a subtle change in a future iOS SDK might make this problem's impact larger)?

all-cells-re-rendered-in-preview.mov

[pyrtsa]

Can you see if turning the build setting SWIFT_ENABLE_OPAQUE_TYPE_ERASURE to NO makes a difference? https://augmentedcode.io/2024/10/21/anyview-is-everywhere-in-xcode-16/