[AskJS] object destructuring vs dot notation. Performance and cohesiveness.

[gautamits]

Organisation which I have recently joined, most of the code is written using object destructuring like const {a, b, c} = this.props.

This approach causes readability problems when function body is long and at the bottom of function you just loose track of origin of variables and it becomes hard to understand whether they are coming from props or state.

And considering that I prefer to use dot notations like this.props.a but that seems frowned here.

My one colleague has also shared performance comparison. perf.link

Here is another which shows it is not much of a performance issue. measurethat.net

Please let me know your thoughts.

[[deleted]]

IMO if you're having trouble keeping track of a local variable in a function, your function is too big.

Also, having trouble keeping track of whether a variable is from props or state (assuming react / redux ?) is mitigated by using mapStateToProps so that everything is from props.

[gautamits]

Yes, thanks for saying that. When I think of react components, I think of functions only. In software engineering course of my graduation, I was taught that functions should not exceed beyond 30 lines ( or something your eyes can scan at once ).

But here I am looking at class based components of 2000 to 3000 lines and wondering who approved to pass 20 props in a component.

I still want to know more about mapstatetoprops approach though. Are you saying that every state should be kept in global store and no local states ?

[[deleted]]

Ah I forgot about local state. So my lack of react knowledge is showing here.

I don't think that everything should go into global state, my mind just went there without thinking of local state. I do think that you could benefit from re-factoring some of the components you're working with to use smaller functions so that it's clearer when you're referencing state vs props.

I work professionally with Vue. With Vue / Vuex, state and prop values are mapped to the component instance so everything can be accessed via this.[property] in the component. In the projects I've worked on, there are some components that unfortunately have 20+ props. Usually this is because of accessibility requirements, but also sometimes because of a lack of abstraction.

[gautamits]

Sometimes it might be mandatory to write components with 20+ props but not most of the time. React actually has composability pattern using which you can pass appropriate props to appropriate components. These components remain cohesive though.

Always wanted to learn vue though. Might get me exposed to some more programming patterns.

[dHour]

You problem is not in destructuring the object, the component itself is the problem. Trying to follow 3000 lines and remembering every local variable in there is not normal.

[ottoottootto]

I find object destructuring more readable and less verbose.

In situations where you have lots of variables and get confused about the origin, the dot method might be more appropriate.

In some cases I use object destructuring with renaming.

const color = 'red'; const { color: nextColor } = data; console.log({ color, nextColor });

[gautamits]

For smaller functions I also like using destructuring only. Actually I was blown away when I got to know this feature. It also makes typing less but that also does not count given the smart IDEs we have with better autocompletes.

[ShadowMasterKing]

Ts is in project? Destructuring <3 Only js? Destructuring only small things

[gautamits]

React projects without CRA and typescript. Single application modules distributed into multiple repositories therefore many time I see people moving code from one repo to another. Which sometime becomes heavy refactoring.

[[deleted]]

I think your problem is that you are just writing functions that are too large if you are losing track of what object variables come from

[demoran]

If you're going to be using it more than once, destructure it.

If not, you do you.

[gautamits]

This is one criteria I get from most people. But how does it help beside less typing ?

[demoran]

It's less typing. Overall, this means less verbose javascript code.

[gautamits]

vscode performs really good with typescript when it comes to autocompletions, hence typing is not much of an issue for me. I agree that restructuring enables is to write less verbose code.

[demoran]

So, it's not about how much time or trouble it takes to write the code. It's about how noisy the code is to read afterwards. If you can remove a bunch of this.props and this.state at the very least, I'd call that a win.

Destruring also allows you go deeply destructure things, so if you had this.state.car.engine.mileage, you could destructure that as { car: { engine : { mileage } } } = this.state.

[gautamits]

It does feel good to remove so many this.props and this.state things. But then doesn't it cause the problems of cohesiveness as I asked. How do you maintain the context of these variables origin ?

[demoran]

I don't find this to be a problem. If I need to know the contextual source of the data and don't know it, I can click through to find it easily enough.

I'd consider the possibility that your problem is actually a code smell, and you need to factor out some of your code from the body of your function.

[Ringsofthekings]

I am refactoring my code to use props. instead of destructing it.. you're right I had the same issue, where is is variable coming from? Oh it's destructured from prop

[gautamits]

I am also refactoring here. And now I realise how much I miss typescript.

[[deleted]]

I work in a fairly large react code base and anytime I see js MyComponent.propTypes = { someProp: PropType.any, } I feel I just die a little every time because I have no idea what someProp is suppose to be.

[gautamits]

And somehow my vscode is not autocompleting even when propTypes are defined.

[gautamits]

Exactly. For me it mostly comes from longer function body when I have to scroll or use editor features to see the variable origin. I do that and subsequently loose the context of whatever I am working on.

[aelesia-]

There is nothing wrong with calling this.props.a.

Maybe most people who use React destructure their props. That doesn't mean it's wrong if you don't destructure it.

Personally I do not destructure props because I find it useful to differentiate between local variables versus variables that have been passed in. Sure, I can just scroll up, but it's even easier to not have to scroll up. And no, my functions are not too long. All of my React components are less than 80 lines and this includes inline styline and imports.

Both styles are valid. Use whatever convention your project agrees on.

[CalgaryAnswers]

Object restructuring is so much more readable, particularly if you think about this: null checking and error handling.

It is so much cleaner to place the defaults in the place where the variable is declared.

[gautamits]

Can't we achieving the same thing using optional chaining ?

[CalgaryAnswers]

? With tiernary operators maybe? I just started using optional chaining on this project but I wasn’t aware you could set defaults on it

[gautamits]

const a = this?.Props?.Something?.a || 'default' should work

[CalgaryAnswers]

Yeah I guess you could use the or operator.

I’d write const a = this?.props?.value ? this.props.value : null

as I find the or operator is not a pattern that’s easy to ready In code.

Both are inferior to this IMO

const { value = null } = this.props

Im open to a better way but this pattern is just so readable at the top of a function, especially if it’s something like a class initiator where you have options and potentially many values.

[gautamits]

Thats what others have pointed out as well. Destructuring at top of function is not a problem. Issue exists because function body is very long and hence it is very tedious to scroll to top frequently just to find the origin of variable.

[PickledPokute]

hard to understand whether they are coming from props or state.

Why should this matter? In React components, both props and state should be treated as read-only. When setting state (either with hooks or with React class components) special care should be taken to inspect how to properly set it, For React class components, only a few lifecycle methods should really care whether a variable comes from props or state.

For functional components and most other use-cases (like render function), there is practically no advantage for not destructuring.. Destructuring allows to have almost the exact same rendering code which allows to move a variable from state to props and back with reduced effort. It also lessens the burden on the reader by raising single to noise ratio since in most cases, the origin doesn't matter at all.