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 😄
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.