Physics body is undefined

Bugs
1

Hey there,

I noticed a typing inconsistency for TransformNode.physicsBody: its type is Nullable<PhysicsBody> but it can also be undefined like in this PG

That’s definitely not a huge issue, but it was probably not intended and can create issues when comparing the physics body to null explicitely (transform.physicsBody !== null).

2 Likes
2

cc @Cedric

1 Like
3

I usually treat it as a boolean. Is there a downside to this?

if (transformNode.physicsBody) ...
4

Is replacing Nullable<PhysicsBody> by Nullable<PhysicsBody> | undefined in physicsEngineComponent.ts a good solution?

I usually do the same as @HiGreg .

5

Not really a downside, but I tend to be careful with those things because JS has some funny behaviors like if("") { // won't execute } and if(0) { // won't execute }.

That’s why there is stuff like this eslint rule:

That works for me, but the best solution imo would be to initialize physicsBody to null in the constructor so that the API type does not change (that would still count as a breaking change ^^)

1 Like
6

Most favourite bug of mine I keep making because of this truthiness shit:

enum Some {A, B, C}

function check(key : string) {
    const val = Some[key];
    // Ensure that val exists
    if(val) {
        //...
    }
    //...
}
1 Like
7

It very much depends on the type! I avoid doing the truthiness test on strings, arrays, or numbers, for example. It works great on objects!

8

Ahh, I was gonna say why Typescript did not complain. It needs to be explicitly enabled via strictPropertyInitialization

1 Like
9

That works as well ^^ but I don’t trust myself to get it right 100% of the time so I prefer to only put booleans in conditions

2 Likes