Comment by orwin | Hacker News Reader

Comment by orwin | Hacker News Reader

Parent Full thread

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 fact how i do my stuff, but once i have a functioning prototype and basic mocks, i then spend a long time in my models.xxx file because modeling data is like 30% of the job.

I have an example of bad data modelling: your object (that is a data representation) have fields that in certain case will be empty and you know it. Some people will ignore them. In 90% of the cases, this is a mistake that will lead to mistake down the lane. If you can use discriminated unions and don't because "it's faster" (it takes literally 2 minutes to do), you are probably writing bad code. It's not about idiomatic or not following conventions (those help) or not typing your data, it's about bad modeling choices.

> 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 management has been moved to the server. There are still some cases for installing a global state management library in the FE, but usually useState / useEffect and custom hooks is enough for most React projects.

The problem is you came up with a heuristic in your mind that "global state management is pro, useState is amateur" but that isn't true.

Lets use a real example: If I worked on your team and pushed a <LoginForm /> component that captured email/pass with useState, you would tell me to move the username and password to a global state management library? Why? Dogma? It would be the wrong call.

We don't use Redux and use useReducer.

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.

Didn't say MFA, said state of username / password (useState is fine for that).

Also said "use hooks", not "don't use hooks" and never said don't re-use functions.

Would hate to be on that team, I bet those PRs are brutal.

Exactly what I meant to say, as soon as you have to add complexity, just adding useState over and over breaks, and that's what I call bad code.

It's fine if it's just a get in a component out of the way, we do not use a reducer to print our 'about' page, but typically the login is where a lot of logic has to happen.

I think I misunderstood your comment, you talked about a global manager and I thought you talked about our library.

And since we pair/mob program often enough (10 hours a week roughly, per affinity or when someone ask for help), our PR meetings are more a way to show off to the whole team a new idea or present library upgrades, but it's true that we are quite brutal, especially when i compare with my previous job where I worked with Indians and north Americans, I think it is cultural though.

Reply on news.ycombinator.com