I'm just full of little ideas today. One I'm trying out, returning NaN in math functions. It's JavaScript's Maybe type for numbers. Then, you need to `handleNaN` down the chain. Might even be interesting and treat this like a `Task` and force you to call fork() before you get the value 🤔 - ThreadSky

kyleshevl.in • 94 days ago

I'm just full of little ideas today. One I'm trying out, returning NaN in math functions. It's JavaScript's Maybe type for numbers.

Then, you need to `handleNaN` down the chain.

Might even be interesting and treat this like a `Task` and force you to call fork() before you get the value 🤔

Comments

acdvs.dev•94 days ago

This is a nice idea, but if you ask someone for the mean of an empty set of numbers, they'd just say "there's no mean because there's no numbers". So I think returning a value that explicitly says "there's no mean" (i.e., undefined) would be better.

kyleshevl.in•94 days ago

Here’s the thing about handleNaN, you can return undefined if you want to.

You don’t want to have to check if you have a number or not every time you hand a value to the next function. It changes your whole API. Having a maybe means avoiding all these checks, handling at the end.

acdvs.dev•94 days ago

I see your point, but I really think this is just extra complexity on top of a simple logical "or" fallback. Saying `const foo = getMean([]) || 'fallback value'` is simpler and just as configurable.

kyleshevl.in•94 days ago

You don’t understand how often I need to handle NaN in the same way. I can make functions that always supply zero, or provide an error message. That’s why using a function at the end is useful.

baweaver.bsky.social•94 days ago

Feels like a very Monoid shaped problem for reasonable defaults.

baweaver.bsky.social•94 days ago

Excepting that most Haskell implementations return 0 for an empty list, rather than an Either / Result / Maybe type to signify the presence of failure or absence of a value.

kyleshevl.in•94 days ago

In my use cases, there’s more value in knowing something went wrong, but passing 0 as a fallback works in plenty of instances.

baweaver.bsky.social•94 days ago

Absolutely. It's contextual, there could be multiple "correct" solutions depending on the usecase

codemix.com•93 days ago

NaN is infectious and TS cannot catch it. It's better to throw, otherwise you end up with NaN all over the place and figuring out where it came from is a pain

kyleshevl.in•93 days ago

Maybe in your use cases, but there are plenty of times I’m ok with NaN. My app has a lot of optional stat tracking, and I can use handleNaN to show ‘Not available’ when the db has no data. Throwing makes no sense in my case.

calirvine.com•94 days ago

The only bummer is that your final value is now number | string and you have to check that. Not the end of the world.

kyleshevl.in•94 days ago

But where I’m handling it, that might be exactly what I want. With a generic, I can handle however I need.

calirvine.com•94 days ago

Ya, for sure. It’s a bit of ceremony, but I still like the Promise.allSettled interface, then you can narrow on status. Or even a [error, value] tuple. All depends on the scenario of course.

Comments

Posting Rules

Reply