Why the fuck do consultants / noob types LOVE using fucking props in react components. This app is complex, just make a fucking redux slice and use that. I'm not passing 23904 props to a component to get it to render. God

This would probably be me since I’ve said Redux more times than actually working with it

@phat-lasagna booooooo

@fullstackclown hire me then - I’ll show you who’s the boss baby

@fullstackclown seriously I need another job I beg you

I believe the opposite. React components with props-only are like pure functions and way easier to unit test and compose. They can also provide nested layers of semantics (onclick in parent becomes onactivate in child etc). Redux is like a glorified global object.

Using sth like a connect HOC you can still easily inject Redux state as props

@webketje Connect is best of both worlds. For some reason the guidelines suggest useselector but that makes your components know about the store and can’t be reused as well.

@webketje That's an interesting take, don't think I've heard that before. Curious: do you pass X number of discrete props, or do you at least create a single object with X number of properties and pass that as a prop? The latter seems like a pretty good compromise to me... doesn't balloon the prop count, but keeps your components "pure", as you say (though assuming TypeScript, creating an interface for that object would be a must). I've always strongly preferred this pattern in plain JavaScript as well... if there's more than like 2-3 arguments to a function, I prefer passing an object instead (frankly, I tend to do it as long as there's more than one because I think it makes the code more explicit and "self-documenting" and probably less error-prone).

My team has been using Jotai atoms to hold data state on a page. Any component that is not generic or reused grabs the part of the page state that it should render.

It is actually quite a nice change from a lot of the props, context, mobx, and redux patterns. Data changes component rerenders. Data shape changes typescript makes what to change obvious.

@webketje tell me how long you have been using react

redux sucks and i will die on this hill

@Burgundxyz have fun dying

@fzammetti I agree on "single-obj-arg functions", but in the context of React or Vue there's more at stake because performance is directly related to prop changes. Flat props are faster to diff and read more easily in JSX. Uncareful { ...spread } ops and object recreation on each render have a negative impact on performance. For a data-model type prop that would be desired though. If the number of props grows too big, you can group them into presets (primary, secondary etc) or translate them into multiple more "specialized" props in child components

@fullstackclown From a distance, since v0.x. Professionally, from 2017 (React 14+ I think) to today

@webketje Makes sense. I don't generally do the single object approach in React anyway because I limit the number of props there are anyway, so there's never many to worry about either way. But, you make a good point, I'll keep it in mind should I ever have a thought of going the other way. Thanks!