-
Notifications
You must be signed in to change notification settings - Fork 1.3k
Added in non-function filtering and test case #292
Conversation
Hi, Thank you. |
@istarkov in a functional flow, not all inputs to a composition are always known. It's the same reason it gives back an identity function for a no argument case |
Can't get, why? |
@istarkov simple example of what I'm talking about
|
also, with the current implementation, if one argument was passed and it wasn't a function, the composer would return it back thinking it was a valid function. The users code would then break later down the stack, leading to some confusing errors |
I'm not agree with this. The reasons are: Type declaration of BTW in your case you can simply write in your code if you want compose(...[
isDev ? someEnhancer : null,
isDev ? anotherEnhancer : null
].filter(isFunction)
) It will not add any additional overhead to your code. It's really good that you create a PR, |
@istarkov i'm not understanding at all how this will break type declaration. It does nothing to effect that. If you want it to throw an error, rather than filtering, I can change it to that so it matches Ramda. But as it stands, compose does not error when given non functions. It just passes down the broken composition. |
Flowtype/typescript checks compose declaration and will give you an error about that Having that modern static type checkers can solve this, IMO it's not a good idea to typecheck every user input at runtime even in dev mode. |
@istarkov IMHO relying on typechecking is a bad idea. These tools are helpful but not everyone who uses recompose uses Flow or Typescript. Furthermore, it's entirely possible that the arguments passed to this method could be created dynamically at runtime. When that happens, typechecking wont be able to save you there. |
@toddw you suggest to add type checks to every enhancer and to every exposed function from the library? And even javascript is not strongly typed language do we need to write all that checks in every function of our code? Why just I will not close this as no runtime type checks is just my code writing preferences can't say for others. |
Thread about reduxjs/redux#2145 for some reasons guys from redux accepted this. |
You're lucky man :) I wish I could say the same, that's why I find Flow so useful I'm just suggesting that there is value to filtering for functions vs relying on static typing addons. I was going to mention redux but you beat to the punch! :) |
Having that my proposal to remove filtering from compose at redux is accepted reduxjs/redux#2167 (comment) |
current implementation breaks if >1 arguments are given, but none are functions. There is already a test case for one argument, this just enhances that