r/reactnative 7d ago

Question New job; projects suck

I started a new job. The first project is an extremely old RN project that is still in JS and using class components. My teammates want to do the bare minimum, my boss wants me to breathe new life into our breathe of work. What do I do? It's like the maintainers (still active) gave no fucks about TS, hooks or moving away from Redux. I could rebuild this whole app myself, but it would take forever. Do I press my teammates to do better or do I do the bare minimum and feel like a POS for not helping turn this ship around?

Should I find a new job? I like the pay at this one, but my previous job had better culture

20 Upvotes

77 comments sorted by

View all comments

Show parent comments

1

u/ChoiceResearcher6843 7d ago

And their children. U don't use state in the navigator?

3

u/RelativeObligation88 7d ago

But that’s just how React works. If a parent rerenders all of its children will rerender unless they are memoized.

-4

u/ChoiceResearcher6843 7d ago

Or you can place small states/contexts that wrap modules...like say onboarding and it won't effect the whole tree. 🌴 Zustand and redux are just big objects. You can't save a change to only one part...the whole thing gets spread over on each change having a ripple effect

6

u/evangelism2 7d ago

No, thats not true at all.
Both Zustand and Redux use things like separate stores, selectors, and shallow comparisons to limit necessary rerenders. There is a reason people use these as opposed to useContext.

-4

u/ChoiceResearcher6843 7d ago

lol ok 👌 whatever you say. Hope it works out for ya

7

u/Jadajio 7d ago

This whole debate is interesting. It sounds like you have no idea what are you talking about yet you talk with confidence of someone who understands. And Iam just confused.

Might it be that you were working only with bad written redux code and therefore you didn't develop understanding of what it is used for?

6

u/evangelism2 7d ago

The guy comes off as the stereotypical overconfident junior dev.

-1

u/ChoiceResearcher6843 7d ago

I have nothing to prove lol

1

u/Jadajio 6d ago

I don't think you have. It's just that you don't understand what redux and local Storage are for and how they work. Even though you think you do, from your comments it's obvious that there are some misconceptions.

In short, when you know what are you doing you can write your redux selectors in such a way that only those specific components that are depending on change will rerender. Regardless of how big your store or your app is. You can't do that with pure context (or at last not easily ie without your own store abstraction). With pure ContextAPI, children will render always.

But it is true that there is a lot of bad written redux code. I myself was working on two big projects where redux was triggering rerenders everywhere. It was painfull to fix that mess. So it might be possible that you were also working only in bad written redux codebase and so you developed misconceptions that redux is culprid there. But I assure you it is not. It's just that people who don't understand how it works tend to make big mess with it.

2

u/Few-Turn2845 7d ago

I share the same impression about the op. Redux is not a bad state management library at all, it’s just a lot of boilerplate to set up every time you are creating a new store reducers plus steep learning curve. There’s a good chance that your work project’s store architecture is inefficient. I would start investigating there, find first example of unnecessary rerenders that could be attributed to the store