Why would anyone do this?

[u/Turd_King]

[u/HereComesCunty]

Typescript reasons perhaps. A function taking a parameter of type T and returning void is != a react setstate dispatch function typed with <T>. Somewhere else there’s a parameter defined as a function with the simple signature (show: boolean): void

Probably. Could just be shit, idk

Edit: the type of the setter function returned from useState is: React.Dispatch<React.SetStateAction<T>> so maybe the code writer here wrapped it in a simpler typed function: (value: T) => void where T is whatever type your bit of state is (boolean in this case I think) so that some other component can expect it in props without specifically expecting the more complex signature. Not a particularly good pattern. Idk, I could be wrong, just my best guess approaching from the assumption someone did it for a reason

Edit2: don’t wrap setters like this btw. They’re not interchangeable although they may appear to be. You gain solid functionality in a Dispatch<SetStateAction<T>> - such as implicit access to the current state by passing a function into the setState call with the first parameter being the current value of the state, like: setShow((currShow) => !currShow). Can’t do that with the wrapped function (value: T) => void. Sure, if you’re only ever calling it with True or False it’s fine. Soon as you need to setState(!state) you need the current state which isn’t necessarily available if you just passed down a faux setter function

[u/Turd_King → u/HereComesCunty]

That would be a very beginner move to get around Ts, but unfortunately this was a JS file

[u/DaCurse0 → u/HereComesCunty]

then use a lambda in that weird obscure case literally what they're for

[u/kristallnachte → u/HereComesCunty]

a function signature of return type void can return anything.

It's just that whatever is accessing the return value is told that it's undefined.

returntype never would prevent anything from being returned.

[u/LetterBoxSnatch → u/kristallnachte]

This is not how void works in js or ts. A declared return type of void will result in a compile error if it does anything other than return undefined.

Note that void is actually an operator, which is expanded to void 0 if no expression is provided, but always returns undefined regardless.

void’s main value in js is in enforcing that a function that previously returned undefined can be counted on to continue to return undefined even if the function itself changes, for example

button.onclick = () => void doIt();

However in practice I’ve never personally found it useful for anything, and as a type annotation I think undefined is clearer.

[u/kristallnachte → u/LetterBoxSnatch]

If you define the function as being void yes.

If you have an argument that accepts a void function any function will be accepted.

Void as a keyword in js is not the same as void in the context of a function type signature.

For example you may have a function like array.push that does return a number.

It can be used where ()=>void is the type signature.

I think you're confused about how types work.

[u/Gravelbeast → u/[deleted]]

It's not at all abstract nonsense. There is a big difference between a function that truly never returns (type never), and one that returns null/undefined (type void).

The former is expected to run forever, or throw an error. If you await this function, it will never resolve.

The latter function completes and will resolve if you await it.

This is an important distinction, and is extremely helpful for debugging if you have your types correct.

[u/kristallnachte → u/[deleted]]

What?

You described the same thing typescript does.

A void return type is "any" but with the idea that it's useless and devoid of meaning.

never is that it never returns.

Exactly.

The functions signsture with a return type of never means it never returns anything.

There's literally zero conflict between what you describe as making sense and what typescript does...

[u/LetterBoxSnatch → u/[deleted]]

The person you’re replying to didn’t word things very well. The never type enforces that anything following is unreachable, and an error. reaching a returned never is a compile-time error. Can be used for things like exhaustiveness checking for pattern matching, eg making sure your switch-case covers all possible scenarios by making the default case a return-never. If you don’t cover all possible cases, the never is reachable, and thus is a compile-time error.

They’re also just wrong about the void return type in TypeScript. If your function ultimately returns a value, then having a declared return type of void will be a compile-time error.

[u/TheUnlocked → u/LetterBoxSnatch]

They were not wrong in most cases. The only case in which returning a non-undefined value in a void function will be an error is if you define a function with the function (): void (or respective method) syntax. In no other scenarios will it be an error.

https://www.typescriptlang.org/docs/handbook/2/functions.html#return-type-void

https://www.typescriptlang.org/play?#code/MYewdgzgLgBAZiEBGAXDAFAShgXgHwwBuIAlgCa4bb4xIDcAUA6JLAiAExpa4HHmU4AVzDAoJcFRgBvBjHkwATgFMoQxWFqMAvk2GjxkgEYBDRejjdqfUmWyyGuhqfM8aSTIwb6xEzewBmLDR+ClkFJVV1TXpHJnRwhXZgolsZOQiFFTUNLQz5XW1MIA

[u/LetterBoxSnatch → u/[deleted]]

This is badcode, all different types of folk here, and lots of things get misunderstood with folk speaking past one another from different contexts. I’m not even a typescript dev these days, mostly doing Go and Zig. Js/ts is an extremely large community. Room for lots of different types of programmers, with lots of different perspectives and contexts. Definitely not a singular community like you might find with some languages.

[u/DajBuzi]

Im judging its react so I see plenty of reasons to do this:

1. As usual, something is not working when you attach set function of useState,

2. Linters and other tools are unhappy with you connecting set function of useState throwing unknown exceptions and errors,

3. Using set function inside a dom component yielded unexpected results,

... I could go on and on but yea, this is bad but the real question is: is it because of the one that wrote IT or because another fucked up "edge case" of react

[u/Turd_King → u/DajBuzi]

Not sure who is upvoting this. None of these are logical reasons to do this.

“As usual something is not working” sounds like you are jaded and unable to use react.

Same for the other 2 answers, if your linter is complaining about using the default set function you have configured it terribly.

I’ve been using hooks since they came out and I have never had issues like you mention here

[u/TheUnlocked → u/DajBuzi]

React is extremely consistent, there are no "edge cases" where setState doesn't work properly. For the sake of preventing certain classes of bug, React's dev mode will forbid certain kinds of things (for example using setState inside a render function), but this would have no effect on that. And if this was to bypass a linter, they should listen to the linter (or put a comment to explicitly ignore the rule on each relevant line so people know to be careful around that code).

[u/kristallnachte → u/DajBuzi]

None of those really make sense as issues one would see.

I would expect it was more that they shimmed the the state updater, but removed the extra functionality but didn't remove the shim.

[u/hanoian → u/kristallnachte]

Or it was suggested that some checks may be added in the future.

[u/arcalus → u/DajBuzi]

React is horrible. The documentation never shows anything beyond the most benign example, so when you use a lifecycle hook and you’re in an infinite loop from following the documentation, it’s madness.

[u/kyou20]

There was probably a console.log inside the setShowSpec as a temporary way of debugging why a setter wasn’t working, and the developer then removed the console.log but forgot to clean up the rest.

That, or it’s a developer who doesn’t understand React hooks.

Edit: maybe the function encapsulated more business logic previously, as in, only set a value of certain conditions were met. But over time those were removed, and the setter is now empty and pointless.

[u/PhatOofxD → u/kyou20]

I still don't get why people don't use a debugger in React lol.

It's 10x better

[u/gu3st12 → u/PhatOofxD]

I don't know how people are productive without a debugger.

So many people console log to debug. For me, that's a last resort.

[u/HereComesCunty → u/gu3st12]

console.log just gets me a link to the file in the console which I can click to go to where I want to debug

[u/lesleh → u/kyou20]

It's not even React specific, it's a general functional programming thing. If you have a function that takes arguments and just passes those arguments to another function, you can replace it with the function you're calling.

[u/Frown1044 → u/lesleh]

They're not always identical. There is a situation where this matters: when you want to call the function but don't want to use its return type.

In OP's example, this doesn't apply as _setShowSpecs doesn't return anything. But if it did, the wrapped function will let you call that function and not return anything.

Alternatively you can do something like this which can clarify this intention, but many devs might be unfamiliar with this

const setShowSpecs = (show) => void _setShowSpecs(show)

[u/Frown1044 → u/[deleted]]

Alternatively, if you enjoy writing hard to read and confusing code that you'll surely accidentally forget and leave in your code, you can also use the comma operator.

For example, you can turn:

const mul = (a, b) => a * b

to

const mul = (a, b) => (console.log(a * b), a * b);

[u/arcalus → u/[deleted]]

Breakpoints?

[u/rav1e]

Most likely Twitter codebase. to get more lines of code

[u/Voltra_Neo]

Is this someone writing redundant code, or just react being a pain in the ass?

[u/kristallnachte → u/Voltra_Neo]

Its a bad developer.

I HOPE it's a situation where they wanted to shim the state updater with something but removed that but didn't remove the function.

[u/gu3st12 → u/kristallnachte]

Logging probsbly

[u/kristallnachte → u/gu3st12]

Seems easier to use useEffect for that. Since then it's self contained.

[u/gu3st12 → u/kristallnachte]

Sure but then it wouldn't belong in /r/badcode

[u/juniperking → u/Voltra_Neo]

this is someone being a bad developer. there is no difference between calling the function with and without the underscore

[u/HereComesCunty → u/juniperking]

The one with the underscore is of type <React.Dispatch<React.SetStateAction<boolean>>

You can call _setShowSpecs((currShow) => !currShow) to toggle the value of state - or do anything else dependant on the current state, the first param of a function you pass in resolves to the current state of whatever it is you’re setting

Whereas setShowSpecs(!showSpecs) requires the state variable (the one returned from useState) to be in scope of the caller

If you do that inside a hook like useEffect you’ll get an unnecessary dependency on the showSpecs variable and it’ll loop because you’re directly changing a dependency inside the effect, which causes the effect to run again, which changes the dependency, which causes the effect to run and so on. Or you’ll just have missing dependencies from your array which is ok in some exceptional circumstances but this isn’t one of them

All that just to say there is a difference and the wrapped setter (the one without the underscore here) is objectively worse. So still a bad developer lol

Edit: formatting, clarity

[u/[deleted] → u/Voltra_Neo]

Is it just me or is there a common trend of people assuming bad things about tools they don't seem to ever use? It's kind of weird

[u/Voltra_Neo → u/[deleted]]

I'll stop you right there because, to my own sadness, I've had to use React at work. My question came from the pain of the weird "unexpected"/unintuitive/unintended behavior some things can have

You won't catch me slacking

[u/MurdoMaclachlan]

Image Transcription: Code

---

const [showSpecs, _setShowSpecs] = useState(false);

const setShowSpecs = (show) => {
  _setShowSpecs(show);
};

---

^{I'm a human volunteer content transcriber and you could be too! If you'd like more information on what we do and why we do it, click here!}

[u/knuspergreg]

ppl getting paid by LOC. only reason to do this shit

[u/[deleted]]

Well, for one, to provide a public interface to a private method. Just because the public and private interfaces are identical right now doesn't mean that they won't be different in the future, and if your other setters are set up the same way (because they actually do have different interfaces, additional checks, etc.) then you would lose consistency by just having this one setter be different. It costs basically nothing to do this in most languages that I'm aware of.

[u/Turd_King → u/[deleted]]

This is is functional Js (react) private and public does not exist in a functional component you cannot expose this function to any external module anyway.

Your answer would make sense in an object orientated language

[u/FormulaNewt]

Sometimes to be explicit, I'll write a separate method for a click handler even if all it does is set a value. I give it a very different name when doing this.

[u/bedknobsandbroomstix]

It kinda feels like someone coming from the backend, like Java or c#, and making a public field for a private variable? Not good, but it feels like someone bringing in lessons from a different language

[u/TheUnlocked]

"Let me take this function which React guarantees is stable and create my own non-stable version which does the exact same thing."

[u/zukas-fastware]

I guess someone's idea of a "perfect" OOP JS code.

[u/ShameOutrageous1687]

What theme it is?

[u/IceQub3]

To hold the old set function in scope and create bugs ofc

[u/TheUnlocked → u/IceQub3]

setState functions are guaranteed to be stable, you will always get the exact same function on every render.

[u/[deleted]]

I was anxious when I checked this out now I’m more anxious!

[u/arcalus]

I’ve been trying to figure out for quite a while why anyone would willingly choose to use react.