Is a pattern called currying, it allows you to create functions from functions and make everything more reusable:
constupdate=property=>value=>object=>({...object,[property]:value,});constupdateName=update("name");constblankName=updateName("");constnameFoo=updateName("foo");constblanks=[{id:1,name:"Luke"},{id:2,name:"Roman"},].map(blankUser);// Returns the array with `name` on both set to ""blanks.map(nameFoo);// Returns the array with `name` on both set to "foo"
Maybe is not the best example, but basically you can create updateX and reuse it all you want, with different values for different objects ... compared to doing the same with 3 arguments:
We need to write update and pass every argument with every use. Currying is one of those things that when it "clicks", you never go back. A popular library that uses this a lot is Rambda.
Also "You might not need" is a way better naming, because people need classes in Angular, indeed they need mutation in Vue, null in response from database.
I considered that rename a few times, but my point is that you don't need it in your own creations, that's the main reason I have my articles set so that is more for "almost experts" than "beginner". Beginners using other folks tools need to learn all this stuff, way later we learn about the things we don't need to code, but might need to interact with somebody else's code.
Thanks, but still more in depth article would be awesome. By your example I can see that in plain JS carrying is worst thing to happen: if you see somewhere in the code nameFoo, you'll probably assume it's a simple string, while actually it's a function which takes object and returns new object with updated name property. With TypeScript it's still very confusing, okay we can hover and see the type, but I assume it will show a complex barely readable type. And I hardly imagining how it is even possible to write all this types, how much complex generics will be needed for this, how much unions.
In TS function "update" has to take a union of all table names. And what if for one table update should have different implementation?
While in true FP languages there is a function overloading and you can define them separately for different tables, which is removing all downsides and sounds awesome. But JS/TS is not such language so it's a good question if the same approaches really worth to be used here? (I didn't ever worked with FP language)
I assume you are following this carrying approach on real projects and you know how to deal with difficulties on this way, so let me repeat myself, isn't it bright idea for article? There are a lot of articles on the topic ofc, but they only sharing basics and explaining nothing useful about how to deal with it in real world, when to use and when to avoid. Not insisting of course, maybe there are such articles and need to search harder and play with it myself
Sure thing! I'll create an article about currying and mention you on it for pushing the idea if you don't mind ^_^ ... about the TS implementation, that update function could look something like this:
constupdate=// Generic for the property name<PropertyextendsPropertyKey>(property:Property)=>// Generic for the value<Value>(value:Value)=>// We expect the "Source" object to be an object of unknown properties<SourceextendsRecord<PropertyKey,unknown>>(object:Source,// We return that Source combined with the new property and value):Source&{[propertyinProperty]:Value}=>({...object,[property]:value,});
I do love to do TS + FP, so creating an article about this might be interesting for other folks as well 😄
Is a pattern called currying, it allows you to create functions from functions and make everything more reusable:
Maybe is not the best example, but basically you can create
updateXand reuse it all you want, with different values for different objects ... compared to doing the same with 3 arguments:We need to write update and pass every argument with every use. Currying is one of those things that when it "clicks", you never go back. A popular library that uses this a lot is Rambda.
I considered that rename a few times, but my point is that you don't need it in your own creations, that's the main reason I have my articles set so that is more for "almost experts" than "beginner". Beginners using other folks tools need to learn all this stuff, way later we learn about the things we don't need to code, but might need to interact with somebody else's code.
Thanks, but still more in depth article would be awesome. By your example I can see that in plain JS carrying is worst thing to happen: if you see somewhere in the code nameFoo, you'll probably assume it's a simple string, while actually it's a function which takes object and returns new object with updated name property. With TypeScript it's still very confusing, okay we can hover and see the type, but I assume it will show a complex barely readable type. And I hardly imagining how it is even possible to write all this types, how much complex generics will be needed for this, how much unions.
In TS function "update" has to take a union of all table names. And what if for one table update should have different implementation?
While in true FP languages there is a function overloading and you can define them separately for different tables, which is removing all downsides and sounds awesome. But JS/TS is not such language so it's a good question if the same approaches really worth to be used here? (I didn't ever worked with FP language)
I assume you are following this carrying approach on real projects and you know how to deal with difficulties on this way, so let me repeat myself, isn't it bright idea for article? There are a lot of articles on the topic ofc, but they only sharing basics and explaining nothing useful about how to deal with it in real world, when to use and when to avoid. Not insisting of course, maybe there are such articles and need to search harder and play with it myself
Sure thing! I'll create an article about currying and mention you on it for pushing the idea if you don't mind ^_^ ... about the TS implementation, that
updatefunction could look something like this:I do love to do TS + FP, so creating an article about this might be interesting for other folks as well 😄
Awesome! No one yet wrote article in my honor, I'm flattered :)
I wish it could explain "Why" and "When to use" no less than "How to use", so pros and cons.
So far carrying looks like a lego and there is something in it, definitely there is something about it.