Experienced Devs, what's something that frustrates you about working with React that's not a simple "you'll know how to do it better once you've enough experience"?

  1. Function components shouldn't need forwardRef... It just makes type definitions especially with generics and accessibility more complicated than it should be. Maybe one day they'll make that change with a new Major version.

  2. I've used react for six years now and never needed forwardRef, and I don't even fully understand what it does 😅

  3. ForwardRef + union types + the babel css prop for emotion was such a pain for the latest release of our in house component library.

  4. Forms always feel like way more work then they should be. But that's not strictly a react thing. Even with react hook form.

  5. There are really no good form libraries right now. People talk up react hook forms, but unless you're doing ultra basic text entry fields it's pretty garbage.

  6. I tend to just find myself falling back to formik (useFormik) and yup for validation, I know it, it’s pretty good, can build with it quickly, you know how it is

  7. state management in large applications. and getting a team onboard. i’m not happy with the „put everything in redux“ idea.

  8. The counterpoint to this is since the ideal React application is always a pure function of state to UI it makes some kind of sense to make the state that the application renders as explicit as possible, especially given that hooks do exactly the same thing but it's just hidden away from the user.

  9. Recently started moving one of our projects from Context API to Zustand, and a colleague of mine used it as well in a more complex project, I have got to say, I am very happy with it and how easy it is to work with

  10. I find myself in the opposite camp when dealing with apps/dashboards. Colocation often means duplication of data (especially with Graphql) and duplication leads to either stale views or maintenance headaches (invalidating caches) when two colocated components have the same data in the same view.

  11. I've never been a fan of the way that you need to handle I/O hooks with Storybook. Either you create a wrapper component to inject props into a child, or you mock api calls with MSW, or you do injection via context. It sometimes feels like neither of these are stellar options.

  12. This seems like it'd be a problem regardless of the framework (vue, angular, etc). I feel like the wrapper component makes the most sense as you essentially decouple the logic and the view of a component

  13. I hate this also would wish if it would be possible to get controls for hooks used in the component. Right now we are just calling the hooks in the wrapper component and just pass them as props to the pure component.

  14. Separating concerns properly. It's too simple to keep frontend business logic in components and it's hard to move it out properly. Hooks indeed help here, but they don't necessarily solve the issues completely, especially when it comes to "effects" (something that's reactive to change in data).

  15. That we need to take so much care and precision with hooks/state to improve performance. The lib should be performant out of the box. I just wanna focus on building shit and not having to worry if I need to memo or not memo this or that.

  16. in most cases you do not need to use memo and in some cases it can ruin your performance. memo is actually quite a unique use case so I wouldn't worry too much about this.

  17. React is already incredibly performant once compiled for most use cases, it can slow down heavily in development though due to excessive rerenders, profiling, and so on.

  18. Try using react-testing-library for testing. You will not care for implementation details as you will be testing based on user's point of view, e.g. on text he sees, accessabitlity details, etc...

  19. For me it’s too many options. One day, it’s formik. No wait, react hook form! Use CRA, no Next.js! Redux! Oh no redux is old now. Angular is as simple as install it and your app is fully functional with routing, state, etc. I spend more time deciding on things to use than just making things. I really like so much about react but lately it’s been really tiresome keeping up.

  20. You have a lot of choices with React because its community is constantly innovating and indepentently coming up with new and clever ways to do things. With Angular the community sits back and lets the Angular team do the job, but its clearly not enough to keep up. Angular's Material library is garbage compared to React's MUI, handling API calls is a nightmare compared to react-query, reactive forms are completely untyped and work like magic compared to something like react-hook-form, Typescript support is also garbage considering it's known as THE Typescript framework.

  21. Lack of strict rules, something like Elm is better, you only have one way to do things, and if you use typescript, if it is not strict, there will be a lot of any in your codebase

  22. popular third party frameworks that are not that great but Pidgeon hole you into using them, i.e., material ui. Also, deep webpack config settings / bundling things is always a pain.

  23. data fetching during SSR, debugging performance problems that aren't evident by the react profiler, SSR memory leaks with redux, optimizing for mobile Google lighthouse scores

  24. Hooks. Don't get me wrong, they're way nicer to use than class components, but they're still a mental paradigm shift from how most programming languages work.

  25. We had class components. They had lifecycle methods that made sense, the methods didn't get redefined all the time and I never questioned whether they needed to be memoized or not, but the code was weird and bloated as soon as you added redux and hocs and it became a tangled mess.

  26. Having event handler functions as part of the fn component is mixing a lot of logic into component and tricky to test for both component and handles. To my pov this is huge anti pattern and it bothers me that everyone just close eyes on that

  27. however you are working with react today you can throw out the window next year when there will be a completely new way to do everything.

  28. Styling. In Vue, you just put your CSS inside your component's