Added note for toSorted and toReversed methods (Issue #7134)

[BrianWoolfolk]

Fixes #7134
This PR addresses the previous issue regarding the new JavaScript methods toSort() and toReversed().

The approach here was to mention the existence of these new methods in the table at the beginning of the page Updating Arrays in State (and made the table bigger).

Before: "copy the array first".
Now: "toReversed, toSorted, copy the array first".

Also, in the Making other changes to an array section, there's now a Note block regarding the similitudes with these new methods and the JS spread syntax.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
19-react-dev	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Sep 19, 2024 0:48am
react-dev	✅ Ready (Inspect)	Visit Preview		Sep 19, 2024 0:48am

[github-actions]

Size changes

📦 Next.js Bundle Analysis for react-dev

This analysis was generated by the Next.js Bundle Analysis action. 🤖

This PR introduced no changes to the JavaScript bundle! 🙌

[homayoun-mohammadii]

there's now a Note block regarding the similitudes with these new methods and the JS spread syntax.

[rickhanlonii]

Instead of documenting the old way, and having a note about the new way, can you flip the docs to document the new way with a note on how to do it in older versions?

[rickhanlonii]

To do that, you'd need to come up with another example of something you can’t do with the spread syntax and non-mutating methods, and I'd add a section specific to "Sorting items in an array".

[BrianWoolfolk]

Gotcha, although I can't think of any other examples aside from the sorting/reversing ones. There's also a "toSpliced" method for deletion and/or insertion that I think would be worth mentioning.

The problem I had with this is that I consider best practice to use the spread syntax every time we work with an array (or even objects) to correctly tell React we're modifying the array in some way.

I decided to go with a note on "how to do things now" because technically we can use "toSpliced" to add, remove, replace and insert, but that would mean to modify the entire sections above (the ones that teaches you to use the spread syntax).

I you allow me; I can change the initial sections to demonstrate the use of toSpliced (and the toReversed/toSorted methods too) and create at the end a new section for "spread syntax and it's benefits", explicitly saying that it allows us to change the memory direction of the array so React can see it as a new array entirely.

[BrianWoolfolk]

@rickhanlonii, I was thinking of creating a section for the structuredClone() method inside both docs of "Updating Objects/Arrays in State".

This provides a deep clone of the array/object that could easily replace the need for spread syntax, and even enable us to directly mutate the cloned object (take the original example from React.dev and we could mutate the cloned object just like person.artwork.city = 'New Delhi').

I've worked with structuredClone before, and I think it can be more useful than the spread syntax

[npar0005]

@BrianWoolfolk

I was thinking of creating a section for the structuredClone() method inside both docs of "Updating Objects/Arrays in State".

This provides a deep clone of the array/object that could easily replace the need for spread syntax, and even enable us to directly mutate the cloned object (take the original example from React.dev and we could mutate the cloned object just like person.artwork.city = 'New Delhi').

I've worked with structuredClone before, and I think it can be more useful than the spread syntax

The issue with using structuredClone() is that it clones all nested objects. You wouldn't/shouldn't be creating new object references for nested data if they aren't changing, as that could lead to unnecessary rerenders.
For the example in the docs, using structuredClone() is fine as there's just one nested object that needs to be changed, but if there were more nested objects that weren't changing, then using structuredClone() would be overkill there. So we'd have to carefully spell out to readers when structuredClone() would be appropriate to use vs when to use the spread syntax (for finer control over what object references change for the state update).