Comments (6)
That makes perfect sense. It will be implemented in the next version, which should be ready this week.
from rambdax.
You really know your Typescript
. I cannot say that I am proficient there. I use it how I use Webpack
- make it work, use its advantages and move on.
I am waiting the variadic types issue to be resolved and this will make compose
and pipe
easier to use with Typescript
.
I appreciate your nice words for the library. I will implement the suggested solution(Typescript 2.8+) until the end of the week. I will close the issue, when the version including the above changes are implemented.
from rambdax.
You are quite right. flatten
can be improved and your suggestion is spot on. I will commit the change, but you will be able to use it when new version is ready.
from rambdax.
Version 0.12.6
holds all your suggestions.
I am closing the issue, but feel free to reopen it if necessary.
from rambdax.
I really appreciate you taking the time to answer my issue and update the types file, but could I bother you to do it again? 😅
debounce<T>(fn: Function, ms: number): T
has an advantage over the previous definition, but it has a disadvantage over
debounce<T>(fn: T, ms: number): T
In the first example, if you want type safety, you have to define T
or else it assumes that T === {}
instead of a function. (Demonstration here)
The way it was could be considered better that the current definition in that at least it would know (without adding type information) that the result was a function.
The second definition I wrote (above w/ fn: T
) has an advantage over the old and current definitions in that no additional type information need be provided for type safety. The function passed in is assumed to be passed right on through as the return value.
I realized later though that my solution has a disadvantage of its own. If the function passed into the debounce has a return value other than void
, then the debounced version of that function will think the return value will be the same when it's actually supposed to be void
.
Assuming that the return value becomes void (or undefined) when a function becomes debounced (or throttled), then the function passed in would need to have the return value type information updated to void
.
Since Typescript 2.8 you can do something like this (taken from here):
type ArgumentTypes<T> = T extends (... args: infer U ) => infer R ? U: never;
type ReplaceReturnType<T, TNewReturn> = (...a: ArgumentTypes<T>) => TNewReturn;
interface X {
debounce<T>(fn: T, ms: number): ReplaceReturnType<T, void>;
throttle<T>(fn: T, ms: number): ReplaceReturnType<T, void>;
}
Demonstration of how it works here.
If you can afford to support Typescript 2.8+, then I think that last solution is best, otherwise, the one with (fn: T, n: number): T
assuming that the functions passed in will typically not have return values since the whole point of a debounced or throttled function is to produce side effects.
Just my opinion.
Thanks for providing a cool library :)
from rambdax.
Also, it would be awesome if the definition for flatten
was updated too.
Right now it's flatten<T>(x: T[] | T[][]): T[]
but T[][]
is an example of T[]
.
The consequence is that as long as T[]
is the return type and also the type of x
, typescript can't know that the result is flattened. It assumes that if x = [[1], 1]
then the return type is Array<number|number[]>
.
I think this would be better:
interface X {
flatten<T>(x: Array<T[]|T>): T[];
}
Demonstration here. (flatten3
being the best option).
from rambdax.
Related Issues (20)
- Async version of R.find HOT 3
- removeIndex has backward arguments HOT 3
- rejectIndexed is missing HOT 2
- Broken examples HOT 8
- Dealing with readonly types returned from immutable array operations HOT 2
- Error in /index.d.ts and /immutable.d.ts HOT 1
- mapArray filterArray curried error HOT 3
- `dropRepeatsWith` takes an equality predicate but documents suggests it takes projector HOT 3
- Function throttle returned undefined HOT 3
- Utility Request: R.toUpcase (ie: Capitalize) HOT 2
- debounce and repl example are broken HOT 1
- Tests? HOT 2
- R.count not working as expected HOT 3
- uniqBy is different from ramda HOT 5
- Missing R.unnest HOT 3
- isFunction not removed from docs HOT 3
- Add differenceWith HOT 2
- Using R.prop with array utility methods returns unknown[] after version 9 HOT 5
- R.partial types and implementation are in conflict HOT 2
- Improve mapToObject types HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from rambdax.