Closed controversial closed 4 months ago
I sort of agree. I think the improved return type is great and we should keep that.
For the input MotionValue
I'm sort of ambivalent. I agree that the example in the linked PR shouldn't be accepted but I do feel like as we support spring animations on values like "100px"
or whatever that intuitively this should be accepted too:
const px = useMotionValue("100px")
useSpring(px)
Realistically we're gonna need to keep the input sanitised because it is quite potentially used within Framer user code. For now I'd prefer to leave the input types as-is too. But if this could be amended to improve only the return type then I can merge and publish.
Thanks for the feedback @mattgperry - I pushed another commit to address this case!
useSpring
now accepts any MotionValue<unknown>
as input, and type-safely transforms that input to a number, to return a MotionValue<number>
Sorry it took me a little while to get to this
Thanks for the updates, I'll merge and publish now!
The current types for
useSpring
useMotionValue<any>
, even though in practiceuseSpring
only handles numeric MotionValues.Since
useSpring
only accepts numeric inputs and only returns a numeric MotionValue, it should be typed withMotionValue<number>
in order to be as specific as possible, and encourage as much type safety as possible.It’s common for developers to enable linter rules that protect against unsafe uses of
any
values in TypeScript, since those values are prone to break type safety guarantees. The current types foruseSpring
create such “unsafe” types even though in practice, the value is always a number. See the following example:Closes #2495