Earlier quoted context omitted.
Poor architecture/design make code unmaintanable, or at least very expensive to maintain. I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works. How you handle your data is also very telling of the code quality. I'm not against the "write shit fast, fix later", it is in fac…
> I would rather have my junior spend 3 more days to understand the FSM we use to handle our front before changing anything than him adding 2 random useState an a random useEffect because it just works. React hooks obsoleted most use of state management tools years ago (there is even a native useReducer now so you don't have to install Redux just for that), especially if they're using SSR (Next.js) where state manage…
A Login page is typically a page that if you don't use a FSM, i will make you redo your work. How do you handle MFA? Errors, including network errors since we work with offshore stations that don't have the most stable connexions? I don't see a single way using a handful of states wouldn't result in poor code. What do you do if a new oidc provider will be used? Or if we migrate to AWS and use cognito, what states should you remove, what should you add? How to you order the rendering?
Nah, if you don't want to reuse our hooks and functions that's fine, but you need a decent architecture, and using a handful of state is not it, especially not for a login page. As long as you have a process to follow in the component, not using a reducer will hurt you and the maintainability (we avoid putting business logic on the front-end to be fair, but sometimes you have no choice). And simple component that just display shit (thus don't need a reducer) aren't often given to juniors are this part of the job is uninteresting and quick to do for non-juniors. We tend to do a lot more backend and ops than front anyway.