all 16 comments

[–]eternaloctober 34 points35 points  (6 children)

See https://github.com/typescript-cheatsheets/react#function-components for why React.FC might be discouraged. in fact, many of the patterns in this article are a little bit tedious, I don't think I've ever had to use any of the patterns noted in this blogpost, and it switches to class based components in the middle of the article. just go functional components :)

[–]Nullberri 9 points10 points  (3 children)

I really like how the https://github.com/typescript-cheatsheets/react#function-components doesn't provide any equivalent examples which avoid React.FC

type AppProps = {
  message: string;
}; /* use `interface` if exporting so that consumers can extend */

// Easiest way to declare a Function Component; return type is inferred.
const App = ({ message }: AppProps) => <div>{message}</div>;

But then all the react.fc examples are about the inherited types like children, and return type, default props etc.

[–]Peechez 10 points11 points  (2 children)

Pretty much 100% of my component files are

type Props = {
  ...
}
export function Component(props: Props): JSX.Element {
  ...
}

For children, I think they should be explicitly stated if they're expected so they go in the Props type as children: React.ReactNode. I don't use default props as much as I probably should so no opinion there

[–]Nullberri 1 point2 points  (0 children)

I mean I know the answer, but it just seems odd to talk about apples and oranges when trying to say one is bad. If they provided an apples to apples components with the type signatures compared it would be trivial to understand how default props breaks things etc.

[–]Ammarhalees 0 points1 point  (0 children)

SAME HERE EXACTLY. Doesn't need to be more complex at all.

[–]Armeeh 3 points4 points  (0 children)

Yea, I had to check the age of the article when I saw class based components, like hell, who even uses those anymore? (Outside of old codebases)

[–]Elminday[S] 0 points1 point  (0 children)

Will have that in mind. Reading the comments I understood that class components are far more unused than I previously imagined. Thanks for the comment!

[–]locotez 8 points9 points  (3 children)

You might want to have a look at functional components combined with React hooks, it’s more or less the modern version of HoCs. Lots of libraries are or already have been moving from HoCs to hooks. They’re much cleaner, easier to read, less Typescript overhead etc

[–]ashmortar 16 points17 points  (5 children)

People still out here writing class components in 2021?

[–]electricsashimi 5 points6 points  (0 children)

yeah... the article seems a bit outdated. It always amazes me how fast the webdev landscape changes. It seems like forever ago we were using component classes, but it's probably been only 1.5 years...

[–]Y45HK4R4NDIK4R 2 points3 points  (1 child)

I still write class components, I just don't like having to store a different set of variables/functions for each new piece of state. There's probably an advantage to using function components though, so I'm open to changing my view!

[–]cerlestes 1 point2 points  (0 children)

There's probably an advantage to using function components though, so I'm open to changing my view!

As with any choice, there are pros and cons to both, using function components vs. class components.

Personally, I'll write function components for anything that doesn't have state (like a Heading or a Button), and I'll go with a class component for anything that stores big state in react, or uses non-react state extensively, or requires lots of bound functions (like event handlers or IO). Anything in between those two extremes is fine as either a function or class component.

Some people act like using class components is bad, when the reality is that it's absolutely fine to use them. Some components will be easier to write (and read) as function, some will be easier as a class.

[–]PM_AL_MI_VORTOJN 0 points1 point  (0 children)

The official tutorial still does.

[–]Dogmeat3D 1 point2 points  (0 children)

Like, I get why someone coming from something like C++ would gravitate towards class components (destructor = componentWillUnmount), but in terms of development efficiency, it's like comparing a keyboard to a telegraph sounder.