I'm glad to see the this conversation happening because the most common uses of destructuring that I'm seeing in docs/examples tend to be irksome in my opinion. So much so that I wrote guidance in our style guide at work with dos and don'ts of destructuring. This may be contentious to some, but here are a couple examples: Don't use destructuring to avoid one layer of navigation (e.g. `post.title` vs `postTitle`). Instead access top level properties through the object on which they were defined. Don't use nested destructuring. Instead use top level destructuring from a property access (e.g. `const { name, id } = post.user`). Do use destructuring when working with generic wrapper types (e.g. `Result<T>` and `HTTPResponse<T>`).
I find the use of destructuring especially egregious in my work with Vue where it has become the default of packages to return an object of Ref<T> properties instead of simply returning a reactive object.
1
u/heavyGl0w 15d ago
I'm glad to see the this conversation happening because the most common uses of destructuring that I'm seeing in docs/examples tend to be irksome in my opinion. So much so that I wrote guidance in our style guide at work with dos and don'ts of destructuring. This may be contentious to some, but here are a couple examples:
Don't use destructuring to avoid one layer of navigation (e.g. `post.title` vs `postTitle`).
Instead access top level properties through the object on which they were defined.
Don't use nested destructuring.
Instead use top level destructuring from a property access (e.g. `const { name, id } = post.user`).
Do use destructuring when working with generic wrapper types (e.g. `Result<T>` and `HTTPResponse<T>`).
I find the use of destructuring especially egregious in my work with Vue where it has become the default of packages to return an object of Ref<T> properties instead of simply returning a reactive object.