slackapi / slackapi/java-slack-sdk
Question: Is it possible to add ViewState to blockSuggestion events?
Nobody has claimed this yet.
- Dominant language
- Java
- Stars
- 602
- Forks
- 232
- Avg merge
- 4d 9h
- Merged PRs (30d)
- 7
Description
In a modal view we have two ExternalSelectElements that provide suggestion support for user entering customer and project values. We would love to use the input of the first select element, if a selection was performed, as filter for the second one without having to store the entered value in a short-living cache or backing datastore. The API could simply return the value of the selected elements within the ViewState object similar to how blockAcktion(...) or viewSubmission(...) receive it.
The modal basically looks like this:
View view = View.builder()
.type("modal")
.callbackId("some_callback_id")
.title(ViewTitle.builder()
.type("plain_text")
.text("Some title")
.build())
.submit(ViewSubmit.builder()
.type("plain_text")
.text("Submit")
.build())
.close(ViewClose.builder()
.type("plain_text")
.text("Cancel")
.build())
.blocks(List.of(
SectionBlock.builder()
.blockId("customerFilterBlock")
.text(MarkdownTextObject.builder()
.text("Customer")
.build())
.accessory(customerFilter())
.build(),
SectionBlock.builder()
.blockId("projectFilterBlock")
.text(MarkdownTextObject.builder()
.text("Project")
.build())
.accessory(projectFilter())
.build()
))
.privateMetadata(metadata)
.build();
private ExternalSelectElement customerFilter() {
final ExternalSelectElement.ExternalSelectElementBuilder builder =
ExternalSelectElement.builder()
.actionId("customerFilter")
.placeholder(PlainTextObject.builder()
.text("Customer")
.build());
return builder.build();
}
private ExternalSelectElement projectFilter() {
final ExternalSelectElement.ExternalSelectElementBuilder builder =
ExternalSelectElement.builder()
.actionId("projectFilter")
.placeholder(PlainTextObject.builder()
.text("Project")
.build());
return builder.build();
}
Suggestions are provided via
app.blockSuggestion("customerFilter", (req, ctx) -> {
...
return ctx.ack(r -> r.options(suggestions.stream()
.map(Option.builder()
.text(...)
.value(...)
.build()
)
.toList());
});
while
app.blockAction("customerFilter", (req, ctx) -> {
final BlockSuggestionPayload payload = req.getPayload();
final View view = payload.getView();
final Map<String, Map<String, ViewState.Value>> values = view.getState().getValues();
final ViewState.Value customerOption = values.get("customerFilterBlock").get("customerFilter");
final String customerUuid = customerOption.getSelectedOption().getValue();
...
return ctx.ack();
});
can be used to learn the actual selected value (before the modal is submitted). Trying that within a blockSuggestion(...) fails as here the ViewState is basically empty (ViewState(values={})).
While we could push that value to some backing cache or datastore, i.e. Redis, so we can access it while making a suggestion for the second one by including the selection of the first input field as filter, I wonder if there are ways to actually get the ViewState also within blockSuggestion(...) and not only blockAction(...) and viewSubmission(...) somehow so we could use the value entered/selected in the first input as filter for the second suggestion? This would avoid having to push those values to a short-living cache or backing datastore.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by tracing blockSuggestion handling and the ViewState behavior in BlockSuggestionPayload, then compare it with blockAction and viewSubmission payloads. Determine whether selected values can be exposed for suggestions; done means the supported behavior or limitation is established with corresponding tests or documentation.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- java
- Domain
- api
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 30/100