-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Fix interactive dialogs not showing #8427
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.
Non-blocking comments/questions. Thanks @larkox!
@@ -55,7 +55,7 @@ type Props = { | |||
maxLength?: number; | |||
optional: boolean; | |||
onChange: (value: string) => void; | |||
value: string; | |||
value: string | undefined; |
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.
nit: any reason why it's not
value: string | undefined; | |
value?: string; |
to match the ones above?
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.
First one I did, I forgot to update 😅
@@ -59,7 +74,7 @@ function DialogElement({ | |||
return; | |||
} | |||
onChange(name, newValue); | |||
}, [onChange, type, subtype]); | |||
}, [type, subtype, onChange, name]); |
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.
for the parseInt
above, does newValue as string
work if newValue
is a string[]
?
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.
The idea is that string[]
is only getting into this function if we were to accept multiselect selectors (we accept that for Apps but not for Interactive Dialogs). But then the type
and subtype
won't be text
and number
.
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 only have questions.
I would have loved to see a test to cover the changes, specifically the "fix" that would cause the dialog element to appear because the value is no longer blank?
@@ -22,6 +22,21 @@ function selectKeyboardType(type: InteractiveDialogElementType, subtype?: Intera | |||
return selectKB(subtype); | |||
} | |||
|
|||
function getStringValue(value: string | number | boolean | string[] | undefined): string | undefined { |
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.
Any value (heh, pun intended) in converting false
to string and gets "false"?
I was thinking of option "true" / "false", but I have a feeling this gets converted somewhere already.
if (typeof value === 'number' || typeof value === 'boolean') {
return value.toString();
}
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 if I understand correctly, the initValues function would have converted that.
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.
function getStringValue(value: string | number | boolean | string[] | undefined): string | undefined { | |
function getStringValue(value?: string | number | boolean | string[]): string | undefined { |
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.
True/false values should only be used on Boolean settings, and those will use the getBooleanValue
. If a boolean value gets into this point, probably is because something is "wrong", and undefined
is the safe approach.
But I don't have a strong opinion on this. Nevertheless, it "should never happen".
Regarding the change to getStringValue
, I would argue the argument is not optional. You must provide an argument, just that that argument can be undefined. 0/5 on that too, so if you have a strong opinion, happy to change it.
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 was thinking of consistency. Since if people can pass undefined, it's almost like not
passing anything. But it is silly to see getStringValue()
. I rather see people send getStringValue(undefined)
instead of getStringValue()
.
Long to short: don't change. :P
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.
- Confirmed Demo Plugin contains dialogue with several fields and field type some of witch were affected by the issue
- Confirmed all fields are now showing including those affected by this issue
- All dialogues I tested can be open and submitted (or canceled)
- As a precaution, I used an ngrok tunnel to see the payload in the submission all fields including those affected are submitting data accurately
- Regression testes using fields and dialogues of various types
- Testing done on both Android and iOS
No issues found
LGTM!
/cherry-pick release-2.23 |
Cherry pick is scheduled. |
* Fix interactive dialogs not showing * Use conditionals (cherry picked from commit d75cbcd)
/cherry-pick release-2.24 |
Cherry pick is scheduled. |
* Fix interactive dialogs not showing * Use conditionals (cherry picked from commit d75cbcd)
* Fix interactive dialogs not showing * Use conditionals (cherry picked from commit d75cbcd) Co-authored-by: Daniel Espino García <[email protected]>
* Fix interactive dialogs not showing * Use conditionals (cherry picked from commit d75cbcd) Co-authored-by: Daniel Espino García <[email protected]>
Summary
We were forcing having a value for the dialog elements. This PR removes that limitation, and fixes the types around it.
Ticket Link
Fix: https://mattermost.atlassian.net/browse/MM-62299
Release Note