seems like a regression in latest v1.5.3 with Type checking

[ghiscoding]

It looks like a possible regression in latest v1.5.3 after I upgraded from 1.5.1, in my App it now shows Type error that I didn't have before

If I comment out dragHandle prop then the Type error goes way. But looking at the NodeProps interface, my code seems correct, so I'm not sure why it's complaining now and it's a bit hard to find what's missing with the long TypeScript error. Do I have to change something in my code? It was working find until v1.5.2, anything after is throwing the error shown above

Custom Edge is also complaining of Type errors, it also wasn't before the upgrade

For the Custom Edge, it starts working after I comment out style and markerEnd

oh wait I just got them working after making these 2 optional, to make them the same as the extended EdgeProps interface. I guess I could live with that but is that really intended to be this way? I'm guessing it is, but just want to confirm that is the way to go

[bcakmakoglu]

Interesting...
1.5.3 does have changes that are supposed to properly type slot props as they were untyped before.
I'll see what's going on and fix the issue, thanks for reporting.
For now you can downgrade to 1.5.2 to resolve the issue until I've figured out what went wrong 😄

[bcakmakoglu]

Alright, so after re-checking, the prop types are correct.
As you guessed correctly, the types need to match the actual interfaces, so for nodes dragHandle has to be optional, same as markerEnd and style for edges - that's just the definition in the interfaces as they could be undefined 😄
Other than that I don't see any problem.
Before the change node and edge props were typed as any which isn't accurate as they're not just any but NodeProps or EdgeProps

I hope this helps ^^

[ghiscoding]

ok thanks for looking into this, I can get their exact Type with TypeScript so that's totally acceptable. Thanks for all :)

[bcakmakoglu]

No problem :)

[bcakmakoglu]

I just re-checked again and to be honest, I can change the EdgeProps to have the markers definitely defined, as they will be something like url(#link) in any case, even if you don't specify a marker. If you don't specify one, it will just point to a non-existing marker-url.

The rest of the props seem fine to me still.
Style could be undefined, if you simply don't pass any (there is no default object that's generated).
dragHandle could also be undefined if you don't pass it and a default is not applied here either.

[ghiscoding]

now that I know the cause, I don't mind either or. I would probably go with the thinking you're doing now and remove the optional flag if you know it should be available when the user defined it and keep optional flag on the ones that could end up optional. On another side, if I define style in my interface, it's probably because I did define it on my side since I want to use it, so I would remove the optional flag on that one.