That's quite the burn rate!

right?? feeling pretty good about it ☺️

(where it's appropriate, which is basically everywhere outside of classes)

it gets rid of a ton of potentially weird behavior around this (if it's not attached to an object via a prototype then why are you using this, UGH) and using arguments (magic!) and trying to use functions as constructors (just use class syntax and use traditional function syntax within classes) or trying to access a function's prototype

it basically makes functions a lot simpler, removing magic and making it super difficult to use in ways you probably don't want people using things in the first place

so it would move from the former to the latter:

export function isNonEmptyString(value: any): boolean {
    return typeof value == 'string' && value.length > 0;
}

export const isNonEmptyString = (value: any): boolean => {
    return typeof value == 'string' && value.length > 0;
}

I thought I remembered that arrow function names wouldn’t show up in stacktraces, and that was a reason to use traditional functions where that’s important, but that doesn’t seem to be the case (at least not anymore or not in this situation in the screenshot, which is from a browser console).

Seems like it might be good idea to use arrow functions more. I don’t really run into the issues you mentioned / do those things, but for the sake of enforcing better code quality for an open source project, it might not be a bad idea to enforce arrow function use in certain situations, if that’s possible.

JavaScript is weird. But we are not exposed to these problems anywhere in the codebase, are we? We use classes proper and all that.

Thinking a bit about this, I'm starting to think it might be a good idea to make the switch. It would codify and enforce what we are already doing. The only reason I hesitate a bit is that I think it is a bit harder to parse arrow functions than regular ones, but that's probably just a matter of practicing.

it's definitely a syntax to get used to! we don't need to move to it all at once or anything but it's something we can start using now as we add code

I’m also happy to move over. The Clojure part of my brain is rebelling a bit since it feels like using (def isNonEmptyString (fn [value] (…)))but JS is weird anyway 🙂

That’s likely essentially what defn is doing anyway though, right? (Saying this without looking at its source).

I’d prioritize it way below the null checking though unless it’s a mostly automated switch. I think functions haven’t given us any trouble yet.

@U9A1RLFNV I think some tooling has trouble with (def (fn …)) since it’s not immediately obvious that it’s a function + if you don’t name your (fn ..) you get the stacktrace problem you mentioned.

Ah yes. I was speaking more from a “what’s actually happening when you use defn” point of view. But yeah you’re right that doing that yourself is not a good idea.

yeah, I'm still doing the strict null stuff first

I'm down to 289 errors: https://github.com/BetterThanTomorrow/calva/pull/1581

but I've been hitting the low-hanging fruit where I can keep the same behavior

and then I'll probably push for dependency upgrades after all of this. we're on a pretty old typescript