Consider how to avoid the need for an unwrap of error properties
#12
Labels
enhancement
New feature or improved functionality.
Comments
lawrence-forooghian
added a commit
that referenced
this issue
Oct 10, 2024
Lifecycle statuses have an error if and only if they have certain cases, so encode this constraint in the type system to avoid unnecessary unwraps. Part of #12.
lawrence-forooghian
added a commit
that referenced
this issue
Oct 10, 2024
Lifecycle statuses have an error if and only if they have certain cases, so encode this constraint in the type system to avoid unnecessary unwraps. Part of #12.
lawrence-forooghian
added a commit
that referenced
this issue
Oct 15, 2024
Lifecycle statuses have an error if and only if they have certain cases, so encode this constraint in the type system to avoid unnecessary unwraps. Part of #12.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
The
RoomStatusandConnectionStatustypes introduced in #9 are currently just copied from the JS type. They have acurrentstate property and an optionalerrorproperty. I believe thaterroris guaranteed to be non-nil for certain values ofcurrent, so it should be possible for us to design an API that doesn't require an unwrap oferrorin those cases (i.e. make the error an associated value of the state enum). To do this, we first of all need to understand in which states the error is:(Ditto for the corresponding
*StateChangetypes.)┆Issue is synchronized with this Jira Story by Unito
The text was updated successfully, but these errors were encountered: