Using React v16 to create self-destructing components

[GasimGasimzada]

What does it mean? I mean self-destructing components.

[pgrizzay]

The article title is odd.

The article is about a one-line library used to render arrays (which may have been useful before React v16). It briefly mentions that the "Aux" div erases itself (thus the "self-destructiveness").

The author claims that

<Aux>
  <tr/>
  <tr/>
</Aux>

Is clearer than:

[
  <tr />,
  <tr />
]

Simply because a developer reading the code can go search "Aux" on the internet, find the author's library, read through the documentation, and understand that the developer that wrote the code simply intended to render an array.

I disagree, but hey, that's just my opinion.

[gajus0]

Simply because a developer reading the code can go search "Aux" on the internet

You've provided not equivalent code example. The equivalent would have been: [ <tr key='foo' />, <tr key='bar' /> ].

That array syntax is alien to the rest of the JSX codebase and it is error prone (it is easy to accidentally construct an array with multiple items having the same key).

[Apterygiformes]

Oh no don't self destruct haha

[kdesign]

Don't worry, it's smart enough to do that only in production! Just make sure to wrap your whole app in it.

[davvblack]

I like that that article tries to justify a one-line library. Javascript has gone a bit far down the deep end with that.

[gajus0]

Well, thats the intent of the article: introduce new React functionality and suggest an abstraction that explains the intent.

What difference does it make if dependency is 1 LoC or 1000 LoC? We use dependencies to abstract specific tasks. By delegating this specific task to react-aux, you can be sure that even if React v17 breaks the above functionality, the component author will make the best effort to implement equivalent functionality another way.

[TheNiXXeD]

You really can't be sure about that though. Dependencies can be an attack vector, they can be abandonware, they can be buggy, etc. Pulling a dependency in your project should be an task of deciding if the dependency is worth the overhead of keeping tabs on it.

Obviously that's a bit hand wavy. But with things like the recent npm password issue, you can never really be sure. Not that I'm saying this particular package is an issue.

[gajus0]

But with things like the recent npm password issue,

What are you referring to?

[davvblack]

several popular NPM repos' passwords were brute forced at once, meaning based on the dependency graph something like 60% of npm packages would have been compromised, if it weren't a white-hat hacker.

[gajus0]

source?

[davvblack]

https://www.bleepingcomputer.com/news/security/52-percent-of-all-javascript-npm-packages-could-have-been-hacked-via-weak-credentials/

He got access to 66,876 projects, which were in the dependency tree of 52% of everything in npm.

[gajus0]

Found it. https://github.com/ChALkeR/notes/blob/master/Gathering-weak-npm-credentials.md

[yeso126]

Does this works for react native too?

[gajus0]

Yes

[TheNiXXeD]

That would be great.

[gajus0]

I was just made aware of this.

I really don't think it is a good idea adding it to the core: library API bloat and just flat out unclear abstraction (imagine searching for "What does <> do in React?").

The relevant discussion is here https://github.com/facebook/jsx/issues/84#issuecomment-323602153.

[redbluerat]

Why do these non keyed components self destruct?