TransformControls still requires every attribute
-
threeversion: 0.138.0 -
@react-three/fiberversion: 7.0.26 -
@react-three/dreiversion: 8.11.0 -
nodeversion: v16.14.0 -
npm(oryarn) version: 3.2.0
Problem description:
TransformControls still requires every "required" attribute. I believe the pick isn't properly working on TS.
This is being seen on both IntelliJ and VStudio, and has been traced to the ForwardRefExoticComponents in TransformControls.d.ts.
Relevant code:
<TransformControls mode={'translate'}>
<mesh position={[0, 0, 0]}>
<boxGeometry args={[0.1, 0.11, 0.1]} />
<meshStandardMaterial
attach="material"
color="white"
roughness={0.3}
metalness={1.0}
/>{' '}
</mesh>
</TransformControls>
Please let me know if you require any further information.
i can't reproduce: https://codesandbox.io/s/spring-bush-0x3ts9?file=/src/App.tsx you need to install @types/three otherwise nothing whatsoever in three has types. three itself has cast out all types recently.
ps you dont need attach="material" and {' '} is technically not allowed, it should warn
@types/three is installed, and still results in this behavior.
Something about the pick isn't playing nice but as it is happening on two different IDE's I'm not exactly sure why?
So I was digging to see if I could find more information on this, and found a GitHub issue that directed me towards the Type: React.JSXElementConstructor instead of the React.ForwardRefExoticComponent.
What's interesting is this is an open bug in IntelliJ and VStudio. Strangely though, in my testing swapping ForwardRefExoticComponent for JSXElementConstructor did solve the issue. The component functions normally and my IDE stops complaining about missing attributes.
Since in this case drei is not returning an exotic component of objects, but instead a proper React component this could be used instead. It seems React.ForwardRefExoticComponent is a subclass of JSXElementConstructor so it should still be valid and solves the IDE's not handling ForwardRefExoticComponent properly.
Since neither IntelliJ NOR MSFT seem to be interested in actually solving this problem despite open issues, I feel the best place to implement this is in this package.
I'd make a PR but I'm not sure if this is actually a proper fix for this issue? Feedback would be appreciated.
Seems like this is still not fixed? @ajnozari, I would love additional detail on how you solved it. I'm not quite sure how I'd achieve what you described with the details you provided