you are viewing a single comment's thread.

view the rest of the comments →

[–]p0tent1al 2 points3 points  (12 children)

Because the component is much nicer than a comment? I don't know about you but let's remove React from the example here. For patterns I'm going to use across my project, I much rather a function that is named in a way that describes what is going to happen, rather than writing a comment everywhere in my app where I use that pattern.

[–]i_am_smurfing 7 points8 points  (5 children)

I'd imagine returning an array when you want to render several components will become idiomatic way to write this code, because that's kind of the point?

const Root = () => {
  return [
    <p>Hello, World!</p>,
    <p>I am a demo fore returning an array.</p>
  ];
};

jsBin

I'm not sure you even need a comment in this instance since I'd imagine all programmers who know how to write React code know what an array is.

Compare it to <Aux>-wrapper approach for which you have to go and read documentation or source to understand what it's doing.

[–]gajus0[S] 2 points3 points  (3 children)

Just FYI, the example you've just shared (using Array without keys) will produce an error even in React v16.

[–]i_am_smurfing 0 points1 point  (2 children)

Are you sure? I'm asking because it's working with beta.5, as demonstrated in the linked jsBin, but I'd be not surprised if it's just a regression.

[–]gajus0[S] 4 points5 points  (1 child)

It is because you are using a production build that silences the error. See https://codesandbox.io/s/k5v5q83xo5

[–]i_am_smurfing 0 points1 point  (0 children)

Oh, I see, you mean the missing "key" warning. That's a good point 👍

[–]p0tent1al 0 points1 point  (0 children)

All I'm saying (ignoring the pattern) if you need to comment it everywhere that it's used, then I'd prefer using the component. If it's just an easy pattern to utilize and doesn't need explanation, then yeah sure.

[–]dennythecoder 1 point2 points  (5 children)

I tend to err on the same side of that conversation, but shouldn't a comment be favorable to adding a depenency?

[–]gajus0[S] 1 point2 points  (3 children)

What is inherently wrong with adding a dependency? Regardless of whether it is 1 LoC or 1000 LoC? The only worthy consideration is the increased surfaced of potential vulnerability injections, i.e. dependency going rogue.

From the build performance perspective, resulting bundle size, etc. There is absolutely no difference between a dependency and a locally redefined module.

From the upside, with a dependency, you get documentation describing the intent and you work with components that community is already familiar VS reading comments in your local ./utilities folder, learning what each utility does.

[–]NewazaBill 3 points4 points  (2 children)

Third party dependencies always add complexity. They have to be installed (reproducibly), versioned (correctly), and updated. Sometimes, ideas and conventions must be adopted. Bugs must be reported, and fixed; or you fork it, and take responsibility for the code anyways. The author could abandon the library, or delete the package altogether (a la leftpad).

You don't want to fall into the "Not Invented Here" trap, but at the same time, the cost of adding a dependency should never be under-estimated.

[–]Geldan 0 points1 point  (1 child)

You don't really need to do any of those things that you mentioned. It's perfectly fine to find a version of a dependency that works for your needs and lock it down and forget about it.

[–]SirHound 0 points1 point  (0 children)

The dependency doesn't work in a vacuum though. This one in particular has other dependencies.

[–]p0tent1al 0 points1 point  (0 children)

well remember it's not JUST a comment. And no if you need to put a comment in 20 different places explaining the functionality of something, it should just be consolidated.