Correct the description of when you can access and mutate state prope…

[ice-cream-coder]

…rties to align with what's in Apple's official documentation.

This is what it says in Apples documentation for @frozen @propertyWrapper struct State<Value>

You should only access a state property from inside the view’s body, or from methods called by it. For this reason, declare your state properties as private, to prevent clients of your view from accessing them. It is safe to mutate state properties from any thread.

I tried to rephrase the wording in Apples documentation as not to plagiarize, but I since Apple's documentation is already very concise, I feel like I just added fluff to something that was already clear. I'm open to suggestions regarding rephrasing.

This edit should clarify two points:

1. Accessing a state property is actually more strict than using the main thread. It should only be accessed from the call to the view's body.
2. Modifying state is actually completely permissive and can be accessed from any thread.

[AlexFine]

Overall this is a good change – it's important content that's missing. Thanks for the PR. In order to maintain grammatical consistency with the rest of the docs, consider modifying the above to:

• Only access a state property from inside the view’s body, or from methods called by it.
• Apple recommends users to declare state properties as private, to prevent clients of your view from accessing them.
• All modifications to a state variable must happen on the main thread. Modifying a state variable on a background thread may lead to undefined behavior.

I'm honestly unsure what Apple means by "it is safe to mutate state properties from any thread." @vmanot any ideas?

[ice-cream-coder]

I think they mean that you can mutate a state property from any thread; e.g. any background thread, main thread, serial thread, concurrent thread. Do you have any evidence that that isn't correct. In my own project I modify the state from a network callback without switching back to the main thread and haven't come across any issues.

[AlexFine]

Yeah I suppose I got confused, because I've gotten errors around "modifying State during view update", as discussed here.

[AlexFine]

Not sure what the difference is tbh. Is "modifying State during view update" not doing things on a background thread? What's the difference?

[ice-cream-coder]

Modifying state would happen if you assign a state variable during the body call. I've only done this on accident trying to write UIViewRepresentable code, but here would be an minimum code example of what you can't do:

struct MyView: View {
  @State private var state = 0
  var body: some View {
     text
  }
  var text: some View {
    state = 2 // <--------- This is an example of modifying state during a view update and leads to undefined behavior.
    return Text("\(state)")
  }

I had the same confusion and just figured out that you can modify state on other threads a few days ago when I was looking at the Apple documentation. That's why I jump on updating this.

[ice-cream-coder]

@AlexFine I took your suggestion for bullet point one, and with some modifications bullet point two. I can't take your suggestion for bullet point three because to my best understanding it's not correct. I think the point is that you can modify State properties anywhere at anytime and under the hood SwiftUI will make sure that when body is called, the value is set correctly, but if you access a state property outside of body, then the result is undefined.

[AlexFine]

Approving this PR to be merged in. We should add another line on State that relates to the concerns mentioned here: https://stackoverflow.com/questions/57340970/modifying-state-during-view-update-this-will-cause-undefined-behavior-error

But overall this PR is good & the content should be added.