feat(system): updates generic typings for xydrag #5105
Conversation
|
| // eslint-disable-next-line @typescript-eslint/no-explicit-any | ||
| export function XYDrag<OnNodeDrag extends (e: any, nodes: any, node: any) => void | undefined>({ |
There was a problem hiding this comment.
I was definitely keen on removing references to any here. Hopefully the adjustments I made won't be breaking for consumers. To mitigate that, we lean on default type assignments for the generics.
There was a problem hiding this comment.
The system package is not documented and I assume that no one besides us is using it currently, so this should be fine. For a React Flow user this should not have any effect.
There was a problem hiding this comment.
Yeah, I think this would be helpful to others who want to build on the underlying system to build Flow wrappers for other libraries. Would be good for system to have a good generic foundation 🙂
| nodes: NodeBase[]; | ||
| nodeLookup: Map<string, InternalNodeBase>; | ||
| edges: EdgeBase[]; | ||
| type OnNodeDrag<NodeType extends NodeBase = NodeBase> = (e: MouseEvent | TouchEvent, node: NodeType, nodes: NodeType[]) => void | undefined; |
There was a problem hiding this comment.
This is what I converted the original OnDrag type generic to that was originally defined using any.
There was a problem hiding this comment.
Interesting. It seems there is a mismatch with the current OnNodeDrag type that is defined in the react package. There the event is just a MouseEvent. That could be a bug in the library 🤔
| nodes: NodeBase[]; | ||
| nodeLookup: Map<string, InternalNodeBase>; | ||
| edges: EdgeBase[]; | ||
| type OnNodeDrag<NodeType extends NodeBase = NodeBase> = (e: MouseEvent | TouchEvent, node: NodeType, nodes: NodeType[]) => void | undefined; |
There was a problem hiding this comment.
Interesting. It seems there is a mismatch with the current OnNodeDrag type that is defined in the react package. There the event is just a MouseEvent. That could be a bug in the library 🤔
4258e1b to
a4bf2ed
Compare
a4bf2ed to
04c71ee
Compare
| onSelectionDragStart?: OnSelectionDrag<NodeType>; | ||
| onSelectionDrag?: OnSelectionDrag<NodeType>; | ||
| onSelectionDragStop?: OnSelectionDrag<NodeType>; | ||
| updateNodePositions: UpdateNodePositions<InternalNodeBase<NodeType>>; |
There was a problem hiding this comment.
Hopefully this wont be a problem as UpdateNodePositions accepts a generic type based on InternalNodeBase and this time we're passing the NodeType info through along with it.
| export function XYDrag<NodeType extends NodeBase = NodeBase, EdgeType extends EdgeBase = EdgeBase>({ | ||
| onNodeMouseDown, | ||
| getStoreItems, | ||
| onDragStart, | ||
| onDrag, | ||
| onDragStop, | ||
| }: XYDragParams<OnNodeDrag>): XYDragInstance { | ||
| }: XYDragParams<NodeType, EdgeType>): XYDragInstance { |
There was a problem hiding this comment.
Now we're passing both NodeType + EdgeType to XYDragParams which will type the underlying store getter as well.
Summary
Similar to #5102 -- this PR updates the existing generic typing for XYDrag as I saw there were gaps in it. This one could perhaps be more sensitive than the other change as it was more additive in nature compared to this one. I'm uncertain about the sensitivity of the change, but just wanted to make sure that the
NodeType/EdgeTypegenerics get passed throughout the system's type definitions.Feel free to poke holes in this PR or reject it all together. Hoping it can be helpful 🙂