4 ms·
I started using this pattern years ago and haven't looked back. React components are defined using a single properties param and it feels natural to extend the
by disillusionist 1y ago
I started using this pattern years ago and haven't looked back. React components are defined using a single properties param and it feels natural to extend the practice to other methods and helper functions that I write.
One nice unexpected side effect is that I end up with more consistency in variable naming when using a param object in order to benefit from object definition shortcuts.
ie I will usually write something like
const firstName = getFirstName(); doTheThing({ firstName });
rather than
const fName = getFirstName(); doTheThing({ firstName: fName });
- carlos-menezes 1y agoLikewise. Even if the input object only has a single property, I'll still use this pattern.
- disillusionist 1y agobecause i'm likely going to refactor this function "tomorrow" with additional properties. :)
- avandekleut 1y agoAnother common pattern is to put the "primary" argument first, and the rest in an "options" object argument.
- carlos-menezes 1y agoIt works fine when your function takes a single primary argument—like `getLastWord(word: string, options?: TGetLastWordOptions): string | undefined`. The function name makes the purpose clear, and with just one main argument, it’s easy to follow. Sure, you're still "guessing" what the first parameter is but it’s not a heavy mental lift. You could argue that as long as you're consistent, using positional arguments in binary functions is fine–the pattern is clear and predictable. But in the example from the OP, there isn’t really a primary argument. You're dealing with multiple values that carry equal weight, which makes positional arguments harder to reason about at a glance.
- hyperhello 1y agoWhat bothers me a lot is that return values can't have a name. Suppose I have a function string combineName(string first, string last); Okay, I assume the result is the full name, but I don't really know that like I would if the return had a name in the header. (The function can be getFullName, yes, but that's so simple it doesn't matter).
- geakstr 1y agoSome languages allow to define type alias, name of this type can be self-explanatory: type FullName = string; function combineName(first: string, last: string): FullName; Also documentation comment for function is what specifically solves this - describes what function does and returns.
- hyperhello 1y agoNeither really addresses the issue. Making a type for a single kind of string seems like an abuse of types just to shoehorn the documentation in. Documentation can be used directly of course, but that moots all of this -- just document? Yeah, but naming the variable is super quick compared to either.
- oneoverten 1y agoVariable names is just documentation. Having types that can assert some condition on the underlying value is not even comparable to "having a named return variable". (just document? just name variables?) You don't care about what the name of the returned value is, you care about what *it is*.
- avandekleut 1y agoTypescript nukes primitive aliases like this sadly. Intellisense will just infer it as "string".
- disillusionist 1y agoyou can do this rather easily by returning an object rather than a primitive. if you're using a language like TypeScript, destructuring the resulting returned object is rather trivial and (in my opinion) delightful to read. eg function combineNames({ first, last }) { const fullName = `${first} ${last}`; return { fullName }; } const { fullName } = combineNames({first: 'John', last: 'Doe' });