I, a React developer for ~8 years, don’t really remember what useEffect does without the second param. I never needed it, so I forgot. I almost feel it should be a required prop, and I doubt that that knowledge alone would fail or pass an interview.

One of the things about React is that local codebase conventions really influence what parts of the API are high-touch for you.

I too have been coding in React for that long (precisely that long, oddly enough ;D) and I used `useEffect()` in pretty much everything I was doing.

There are reasons for this that are local to the project I was on for most of that time.

And yeah, I'm pretty sure my embarrassing confusion cost me the interview in question.

Coding is a lot like playing a musical instrument, or singing. Without daily practice, you get musty. You can scrape off the must in a matter of days or weeks, but in the meantime, you can be expected to bomb any audition.

This is why it's so good to have something on the go on GitHub. It's not about the star-count, it's about keeping your hand in.

The fact that it’s unintuitive and different is why hooks are a joke. Class components just make sense.

I never had a problem with the explicit lifecycle methods in class components, and the concept of a functional component effectively being the render method in isolation. To me there’s only one clear advantage to hooks and that’s sheer reduction in raw lines of code. Having said that, it’s a pretty huge advantage for something like redux.

TBH I disagree, I prefer strict functional programming, mostly for composability. Class components feel like translating everything into latin numerals and then back out again.

Hooks help me avoid that pain. But is the API perfect? Nope.

There are also frameworks like solidjs which have similar syntax to React but avoid the complexity of hooks with a simpler API and no hook rules. Classes are not the only solution

Lately I've been investigating Svelte. It looks really good, but I think I'm going to stick with React/Nextjs simply because of the ecosystem and switching cost.

Again, this isn't 'American Idol for frameworks'; I'm not picking React because I think it's the best, or even better. I'm picking React because of the habitat, and because that habitat is now, in a sense, my hometown.

Yeah of course, you always have to do what is best for your company/clients and React is always a great choice (can't beat the ecosystem)

It's the same reason why I non-ironically recommend Wordpress to a lot of people that have super limited budgets and want the moon.

I do enjoy trying all the different new approaches to UI development though, especially as I'm not a frontend developer so most of the time I write frontend code I'm building either internal tools or personal projects, so I get to experiment a lot.