-
-
Notifications
You must be signed in to change notification settings - Fork 833
Make more of the codebase conform to strict types #10857
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good to me, just one q about error type guards
@@ -580,13 +580,13 @@ export default class ContentMessages { | |||
} catch (error) { | |||
// 413: File was too big or upset the server in some way: | |||
// clear the media size limit so we fetch it again next time we try to upload | |||
if (error?.httpStatus === 413) { | |||
if (error instanceof HTTPError && error.httpStatus === 413) { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe I just love typeguards too much, but I feel that a handful of isHTTPError()
/isMatrixError()
typeguards could be helpful due to how much they'd get used. What do you think?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree for interfaces, but i prefer the built-in instanceof
personally where possible, a typeguard leaves ambiguity on the table in the case of inheritence. If I pass a MatrixError
to isHTTPError
will it return true or false? I'd need to consult the docs, whereas I know instanceof
will because MatrixError extends HTTPError
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ah that's an interesting point. I think I generally use the typeguards for simpler cases and hadn't considered inheritance.
For element-hq/element-web#25088
Split into meaningful commits to aid review
This change is marked as an internal change (Task), so will not be included in the changelog.