The following two paragraphs in "Splitting High and Low Priority State" in Concurrent UI Patterns creates confusion

When you design React components, it is usually best to find the “minimal representation” of state. For example, instead of keeping firstName, lastName, and fullName in state, it’s usually better keep only firstName and lastName, and then calculate fullName during rendering. This lets us avoid mistakes where we update one state but forget the other state.

However, in Concurrent Mode there are cases where you might want to “duplicate” some data in different state variables.

Isn't this how we build React apps anyways -- we store query value in a one state and data in another state? I am asking this because the description at the beginning of this section does not provide relevant information for the rest of the section, which mainly talks about moving setResource to startTransition to make it "low priority". In contrary, it creates a confusion that putting input value and API data in the same state was a normal occurrence. Even in the provided example, we are not really duplicating data -- we are just using each data in a different way (one in a normal way and another one inside startTransition).

If the idea of duplication is that resource and state coexist as a duplicate data, I think that also contradicts all the previous sections on this page because we have been storing "concurrent resource" in the state for "profile change" example etc.

I suggest that we remove these bits and replace it with something like:

In the past, when designing React components, we would handle input state and data state within the same application flow using React's state management. However, existing flow cannot be applied when data is being handled using concurrent mode APIs. Consider this tiny translation app:

在 React 文档中找到“Splitting High and Low Priority State”部分，并阅读其周围的 Concurrent UI Patterns 内容。将令人困惑的介绍性段落替换为与 input state、data state 和 startTransition 示例相符的措辞；当该部分的解释与示例及前面的章节保持一致时，即表示完成。