Modal Components #7773
Modal Components #7773
Conversation
c7a5710 to
1dddd5b
Compare
c01c961 to
f0add47
Compare
| topics: | ||
| - "User Apps" | ||
| - "HTTP API" | ||
| - "Interactions" |
There was a problem hiding this comment.
Are these topic arbitrary or a known set of tags?
I ask because user-apps doesn't really apply directly, and HTTP API only tangentially.
There was a problem hiding this comment.
Not saying we need to remove them, but I do wonder if we can have a "Components" tag or similar 👀
There was a problem hiding this comment.
Looks like they can just be added or removed and it updates! Added components for this one and the past cv2 changelogs
| ###### Component Interaction Response Structures | ||
|
|
||
| | Component | | ||
| |-----------------------------------------------------------------------------------------------------------------------| | ||
| | [String Select](/docs/components/reference#string-select-string-select-interaction-response-structure) | | ||
| | [Text Input](/docs/components/reference#text-input-text-input-interaction-response-structure) | | ||
| | [User Select](/docs/components/reference#user-select-user-select-interaction-response-structure) | | ||
| | [Role Select](/docs/components/reference#role-select-role-select-interaction-response-structure) | | ||
| | [Mentionable Select](/docs/components/reference#mentionable-select-mentionable-select-interaction-response-structure) | | ||
| | [Channel Select](/docs/components/reference#channel-select-channel-select-interaction-response-structure) | |
There was a problem hiding this comment.
Sooooooooooo unfortunately we are gonna need 2 tables in the short term:
- for message component interaction data structure
- for modal submit data structure
We don't want these docs to imply you might reeive anything other than String Select and TextInput for modals
There was a problem hiding this comment.
We also are gonna need to think about how properly represent the fact that Labels (and any other non-data-components) will be in modal_submit.components and have no data. We still need to indicate that they'll be here.
As an example, a label in modal_submit.components is just { type: 18, id: <#>, component: <component> }
Basically the same as ActionRow now that I think about it.
There was a problem hiding this comment.
Ah. This got moved, so it isn't specific to modals right now.
Technically having something that was specific would be nice in the future, but frankly, I think this is fine.
So the above comments can perhaps be overlooked for now.
Hopefully people won't make assumptions about the data in modal_submit.components based on just this table, but take into consideration what can actually be put into a modal first.
There was a problem hiding this comment.
Continuing the stream of consciousness...
This table actually is modal specific because Message Component Data Structure doesn't actually reference it, and it makes sense why, because Message Component Data Structure is itself actually already the data that you'd find from one of the structures referenced in this table
interaction.data vs interaction.data.components[0] and what not.
As such, we should remove the user/role/channel/mentionable selects from this table as those are for Message Component interactions.
I think in the future we can think improve the docs to
- have a single table that has a connection from
component type->interaction data structure - have the Message Component interaction data structure make use of it
- have both Message Componnet interaction data and Modal Submit interaction data both list out the component data that they may contain.
So the biggest action item here is, i think, to remove the last 4 rows from the table? or strengthen message-component interaction data's reference to the table so that it isn't modal specific?
There was a problem hiding this comment.
Noted this all. For now I removed the last 4 rows!
| | resolved? | [resolved](/docs/interactions/receiving-and-responding#interaction-object-resolved-data-structure) data | data for users, members, channels, and roles in the message's [auto-populated select menus](/docs/components/reference#string-select-select-menu-resolved-object) | | ||
| | resolved? | [resolved](/docs/interactions/receiving-and-responding#interaction-object-resolved-data-structure) data | data for users, members, channels, and roles in the message's [auto-populated select menus](/docs/interactions/receiving-and-responding#interaction-response-object-modal) | |
There was a problem hiding this comment.
Wow uh, i didn't realize we were tying the message object's resolved field back into interactions. In the future we may need to promote 'resolved objects' to its own reference and let multiple entities reference it instead of other entities referencing it from the interaction section.
This does not need to be actioned currently. It is a note.
You asked for them
We building them
We documenting them
Here's Modal Components 👀 👀 🎉
What's New
We're introducing a new top-level Label component for modals that have a
label,description, and can contain a Text Input or a String Select! You heard right, String Selects now work in modals!labelfield on the Text Input is not allowed in favor oflabelon the Label componentrequiredfield is now available on String Selects (defaults to true in modals, ignored in messages)disabledfield on String Selects will trigger an error if used in modals and is not currently allowedTimeline.1.mp4