You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I see that ts-for-gir is being used to generate types for Typescript but I have noticed some discrepancies in types for various different Astal services. Some notable culprits are:
AstalNetwork.Wifi - can be null but isn't typed accordingly. Which leads to startup errors if bindings are relying on a null value or if a property of a null Wifi (imagine no wifi adapter exists) is getting accessed.
AstalBluetooth.Adapter - same as above
AstalNetwork.Wired - same as above
Culprit example:
bind(networkService.wifi, 'iconName')
This will fail and prevent the component from rendering if networkService.wifi is null. However, the type definition doesn't indicate that this can be null in the absence of a wifi adapter.
The text was updated successfully, but these errors were encountered:
yeah. They are marked as nullable in vala, and the generated vapi files are correct. They are not marked as nullable in the gir file, I had a quick look and couldn't find any evidence that properties can even be marked as nullable in gir files at all. The return type of getter functions is correct though.So eg networkService.get_wifi() has return type Wifi | null
Object type properties might be inherently nullable (not sure though, would need to read through all the gobject introspection stuff to find out), then the this has to be fixed in ts-for-gir.
I see that ts-for-gir is being used to generate types for Typescript but I have noticed some discrepancies in types for various different Astal services. Some notable culprits are:
null
but isn't typed accordingly. Which leads to startup errors if bindings are relying on a null value or if a property of a null Wifi (imagine no wifi adapter exists) is getting accessed.Culprit example:
This will fail and prevent the component from rendering if networkService.wifi is null. However, the type definition doesn't indicate that this can be null in the absence of a wifi adapter.
The text was updated successfully, but these errors were encountered: