# Refactoring mystery, or is it? **URL:** \ **Category:** web dev\ **Created:** [August 14, 2018, 2:31am UTC](https://forum.kirupa.com/t/refactoring-mystery-or-is-it/638606 "2018-08-14T02:31:05Z")\ **Posts on this page:** 5\ **Page:** 1
**Author:** ![JohnHansenArtist](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/johnhansenartist/32/8958_2.png) [@JohnHansenArtist](https://forum.kirupa.com/u/JohnHansenArtist)\ **Post date:** [August 14, 2018, 2:31am UTC](https://forum.kirupa.com/t/refactoring-mystery-or-is-it/638606/1 "2018-08-14T02:31:05Z")
I am working in a Gatsby Reactjs project and I’ve recently come across something that has me confused. I solved the issue but I don’t understand why it works the way it does. Maybe someone can help me understand. In a code block inside a class component I may have 3 or more value pairs in state. Now if I refer to just one key within the state as: ``` this.state.something ``` but the linter wants me to refactor that one reference of state, one cannot simply just write: ``` const something = this.state; ``` If one does it brings all keys value pairs with their state into that variable assignment. Often that might not be a problem but when you specifically need just the one referenced state value, and you are being forced to refactor your code, I found the line has to be written: ``` const { something } = { ...this.state }; ``` It works, though I don’t understand why? Thank you for any help 🤔 ---
**Author:** ![senocular](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/senocular/32/7217_2.png) [@senocular](https://forum.kirupa.com/u/senocular)\ **Post date:** [August 14, 2018, 1:10pm UTC](https://forum.kirupa.com/t/refactoring-mystery-or-is-it/638606/2 "2018-08-14T13:10:14Z")
I’m not certain exactly what the linter is tripping on, but generally direct references to state variables are only discouraged if you’re assigning, not if you’re simply referencing to capture a value. So ```auto const something = this.state.something; ``` should be fine, whereas ```auto this.state.something = something; ``` would not be. That being said, this would also be ok ```auto const something = this.state.something; something = somethingElse; ``` because even though `something` came from the state, the assignment here is to the variable, not a property of the state or some state-defined reference. Using object spread (`{...}`) helps protect against this - to a degree - because it copies properties from one object to another. This expression ```auto { ...this.state } ``` creates a new object with copies of all the properties in `this.state`. This means any assignments to this object would not affect the original state because it would be modifying the object created in that expression instead. ```auto const stateCopy = { ...this.state }; stateCopy.something = somethingElse; // does not affect this.state ``` However, if you’re using destructuring to capture a single value from this expression like so ```auto const { something } = { ...this.state }; ``` then this is effectively no different than saying ```auto const something = this.state.something; ``` Both assign the local variable `something` to the same value - the value in `this.state.something`. The fact that the `something` property was copied into an intermediary object with a spread expression in the first variation does not change what that value is or how it behaves as a local variable. Depending on the value of `something`, all of this may be inconsequential. Any primitive value in `something` would be considered safe since you wouldn’t be able to assign any property internal to that value. This would not be the case if `something` were an object value. If you were able to say ```auto something.anotherProperty = anotherValue; ``` Then you run the risk of modifying the state without going through `setState()` which is a no-no. Object spread does not protect you against this either because it does not do a deep copy. It only copies direct properties of one object to another. It does not copy properties of properties meaning `anotherProperty` would be a reference to the same `anotherProperty` in `this.state` even if object spread was used to create `something` as seen in the earlier code sample. ---
**Author:** ![JohnHansenArtist](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/johnhansenartist/32/8958_2.png) [@JohnHansenArtist](https://forum.kirupa.com/u/JohnHansenArtist)\ **Post date:** [August 14, 2018, 1:39pm UTC](https://forum.kirupa.com/t/refactoring-mystery-or-is-it/638606/3 "2018-08-14T13:39:01Z")
``` [eslint] Must use destructuring state assignment (react/destructuring- assignment) ``` Thank you @senocular Your explanation is thorough and very helpful. Thank you! My .eslintrc was a bit of a nightmare to set up. I like to destructure my code but I wish the react/recommended did not error on a simple ``` const something = this.state.something; ``` Thanks again! 😀 ---
**Author:** ![senocular](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/senocular/32/7217_2.png) [@senocular](https://forum.kirupa.com/u/senocular)\ **Post date:** [August 14, 2018, 1:46pm UTC](https://forum.kirupa.com/t/refactoring-mystery-or-is-it/638606/4 "2018-08-14T13:46:32Z")
Its an interesting eslint rule. https://github.com/yannickcr/eslint-plugin-react/blob/master/docs/rules/destructuring-assignment.md I think its purpose is mainly to enforce a style guide for your code, not to necessarily help prevent errors. Both `always` and `never` each warn when using the alternate style, suggesting either is acceptable technically, just a matter of preference for the author. ---
**Author:** ![JohnHansenArtist](https://yyz1.discourse-cdn.com/flex011/user_avatar/forum.kirupa.com/johnhansenartist/32/8958_2.png) [@JohnHansenArtist](https://forum.kirupa.com/u/JohnHansenArtist)\ **Post date:** [August 14, 2018, 2:45pm UTC](https://forum.kirupa.com/t/refactoring-mystery-or-is-it/638606/5 "2018-08-14T14:45:16Z")
I did read this eslint-plugin-react rule and I was hesitant to assign ‘never’. Now I have and I’m happier 😃 Thanks!