feat(util): add component builders #1752
Conversation
github-actions
bot
added
c-util
| pub fn components(mut self, components: &mut Vec<Component>) -> Self { | ||
| self.0.components.append(components); |
There was a problem hiding this comment.
If we are taking ownership of the items in the Vec anyway, we could reborrow it for a cleaner signature:
| pub fn components(mut self, components: &mut Vec<Component>) -> Self { | |
| self.0.components.append(components); | |
| pub fn components(mut self, components: Vec<Component>) -> Self { | |
| let mut components = components; | |
| self.0.components.append(&mut components); |
I think this can be applied throughout the PR if it's the case
| //! # Ok(()) } | ||
| //! ``` | ||
|
|
||
| use std::convert::TryFrom; |
There was a problem hiding this comment.
i think this is in the prelude now? it's in a couple other files too
| /// Convert a components builder into a `Vec<Components>`, validating its contents. | ||
| /// | ||
| /// This is equivalent to calling [`Components::validate`], then |
There was a problem hiding this comment.
This link doesn't resolve, and shouldn't it say Vec<Component> here instead?
| /// If there is an action row available the button will be added to it | ||
| /// else a new action row will be created. |
There was a problem hiding this comment.
I think this might end up being confusing for users. We should better document how this builder should be used, and whether or not it's better to use just an ActionRow builder.
If a user is responding to an interaction with a Modal, they should use ComponentsBuilder, and add multiple TextInput components. These don't belong in an action row.
If a user is responding to an interaction with a message that includes components, and they want one action row with multiple buttons or they want one action row with a select menu, they should use the ActionRowBuilder.
If a user is responding to an interaction with a message that includes multiple action rows each with buttons, they should use ComponentsBuilder. Additionally, I think the automatic fallover behavior that is currently implemented would be confusing and could cause invalid behavior down the line, and we should prefer explicit behavior. Users should be required to add buttons or select menus directly to the place they expect them to end up.
There was a problem hiding this comment.
Should the first action row be created by the builder or by the user too?
| @@ -0,0 +1,15 @@ | |||
| //! Component builder thing | |||
There was a problem hiding this comment.
this looks like a temporary doc
| /// Returns an error of type [`SelectOptionValueLength`] error type if | ||
| /// a provided select option value is too long. |
There was a problem hiding this comment.
| /// Returns an error of type [`SelectOptionValueLength`] error type if | |
| /// a provided select option value is too long. | |
| /// Returns an error of type [`SelectOptionValueLength`] if a provided select | |
| /// option value is too long. |
|
Any progress on this? |
|
Yes, I just need to update the docs. I've had much to do the last few days I will push an update soon. |
|
Triage: deferring updating + merging to likely 0.17 |
No description provided.