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:

Repérez la section « Splitting High and Low Priority State » dans la documentation de React et lisez le contenu environnant de Concurrent UI Patterns. Remplacez les paragraphes d’introduction confus par une formulation cohérente avec l’exemple de input state, data state et startTransition ; le travail est terminé lorsque l’explication de la section est cohérente avec l’exemple et les sections précédentes.