Anon died on the "clang format bad" hill
Mine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
Syndicated from the fediverse. Read and engage on the original instance.
View original on programming.devMine is that the useState hook is an actual plague on the entire React ecosystem. Regardless of your opinions of React, if you wanna use something then use it right.
31 replies
SharePoint, Teams, OneDrive, Entra ID and M/O365 aren't "stupid". Your problems and complaints are the result of user error (although, to your credit, Microsoft in no way makes their intended use obvious or intuitive).
Don't take that as an endorsement of them or Microsoft. On a consumer level, you should actively avoid them all. I'm referring to people who have to use them at work and complain about intended behavior being "stupid" or "pointless". If you learn enough about how it works, you realize it either makes sense or is simply a limit of "the cloud".
Idk man I've never heard someone talking shit about slack. I think teams might actually be bad software.
Personally, I find
useEffectto be the real evil.I feel like useState and useEffect are 2 sides of the same coin
might you even say "two perspectives of the same object"?
Personally, I find React to be the real evil.
The default clang-format configuration is absolutely horrendous, but for our company we had an in house clang-format configuration that actually made the code look quite good. The problem is you still have to control code spacing/some alignments yourself.
Using LLMs are not the same as using intellisense or compilers and there are a myriad number of reasons not to use it that could fill an entire book and I will look down on any company or freelance developer that uses it.
Yes I'll fight Linus over this and yes I'll be right.
Isn't this the most common layman's opinion?
No idea how much of a hot take it is but i find
virtualto be a plague upon a codebase.There are a few very rare use cases for it, but imo most cases where developers use virtual they can use templates instead to achieve the same result.
I once witnessed a literal shouting match in the office over
virtual.Your comment makes zero sense in C++.
Why does it make zero sense in C++?
edit: simplified example of what i mean
vs
Linters are terrible.
Style/formatting linters, anyway, particularly when it comes to whitespace. The goal of formatting code with whitespace is to optimize for human readability. A linter based on a set of rules is not human and thus cannot judge human readability. There is really no formatting rule you can write that will not someday have exceptions on a large-enough codebase.
Contributors should be responsible for submitting readable code, and ensuring that is what reviews are for.
I'll go a step further: formatting for human-readability is the job of the reader, not the writer. Hardcoded line breaks, spacing, etc. are never going to be a good solution because the idea is wrong from the start. This is a display issue, not a logic issue. It needs to be solved at the display end.
Use a syntax-aware editor that formats code the way you like it. Save it any goddamn way that is syntactically valid. Anyone else who opens it will see it any way the like in their own syntax-aware editor.
"But my editor doesn't do logical formatting!" Yes, because the entire world has been insane for several decades, and shitty editors are normalized. If the world had realized this 30 years ago, there wouldn't be a code editor in existence today that didn't do this properly. Demand better and better will be normalized.
Tabs are better than spaces
Tab chars are better than spaces AND the correct tab width is 2 spaces
Imagine a programming language not compiling because of spaces.
Ooh... good one, but any good IDE and/or source control will convert tabs to spaces anyway.
Any good IDE and source control should convert spaces to tabs. QED
Care to elaborate on this? Not saying you're wrong necessarily, that's just a pretty bold claim and I'm curious why.
React works by maintaining a virtual representation of the DOM. When you dispatch state changes into the virtual DOM react can determine which components depend on the change and which side
useEffects run.My gripe is that YouTube tutorials teach that the useState is the equivalent of a variable. This encourages average developers to problem solve solutions that end up using React's Virtual DOM for business logic. The YouTube tutorials have react devs planting 100s of useStates - some of which don't directly induce a visible-on-screen rerender - and then ⅒ as many useEffects to bind these states together. This means that for the Virtual DOM to come to the conclusion as to what html elements need to be changed and how it has already mutated 20-50-100s of times and the CTO tells me the react app is slow and they're mad.
If 2 states have the opportunity to mutate each other back and forth then the truth is that you have 2 perspectives of the same state. And React gives you solutions for that - proper solutions - the
useReducerhook is for defining these complex state mutations and the Context API for communicating that state to any component.And this has me quintuple pissed off because these same tutorial grade react devs install REDUX as compulsively as a pack-a-day smoker (that's #3). They use Redux to file variables in JavaScript memory (that's #4) like it's a global variable and rarely if ever use it for the complex state mutations they need instead I've seen react devs write components pull state out of redux into a component just so it can mount useEffect and process the state and dispatch the result back into redux. Let's not even bring up how the react-redux binding library literally uses the React Context API (that's #5).
Getters and setters are ridiculous
I don't like working with them any more than you do, but they're necessary to enforce read/write-level security. Without them, there'd be no differentiation between reading a variable and writing variable from an external class, which kinda defeats the point.
From a development standpoint, they're an extra hurdle to clear. From a security standpoint, they're a necessary evil.
YES
That's why people invented properties / auto generated getter/setter - in at least 95% of cases they are just busywork.
Oh my god. I'm not the only one who thinks this!
I am still not convinced vim does much of anything for your productivity.
Shun the non-believer! Shun!
Yeah! Emacs has always been the superior editor!
OP making this post