progress dots continue forever if we don't use chat_append()

[cboettig]

If I don't use chat_append(), the progress dots do not go away, even though the task has returned and triggered appropriate actions.

Additionally (or alternately), it might be nice to have a non-appending version of chat_append(), providing a response but not a full record of past responses. (In shiny, this makes it behave like all other inputs -- buttons, toggles, text boxes etc don't show the history of every click).

I know we can accomplish these things already using the base shiny reactions instead, but the UI is so nice here and it feels more consistent to be able to do both. Thanks for an awesome package.

[gadenbuie]

If I don't use chat_append(), the progress dots do not go away, even though the task has returned and triggered appropriate actions.

Can you explain a little more what happens (or what you want to happen) in your app when the user submits a chat message?

[cboettig]

Thanks @gadenbuie -- I should have included a reprex. For instance, the example from the docs, just comment out the chat_append() call and run the app:

# interactive()
library(shiny)
library(bslib)
library(shinychat)

ui <- page_fillable(
  chat_ui("chat", fill = TRUE)
)

server <- function(input, output, session) {
  observeEvent(input$chat_user_input, {
    # In a real app, this would call out to a chat model or API,
    # perhaps using the 'ellmer' package.
    response <- paste0(
      "You said:\n\n",
      "<blockquote>",
      htmltools::htmlEscape(input$chat_user_input),
      "</blockquote>"
    )
    # chat_append("chat", response)
  })
}

shinyApp(ui, server)

We still observe input$chat_user_input, and of course could dispatch to ellmer or anything else, and have our app update accordingly. But unless we include that call to chat_append(), those three thinking dots that trigger when we put the input in will never go away.

[cboettig]

i.e. of course chat_ui() needs to be able to get some signal from the app to stop showing it's 'thinking dots'. It looks like it currently waits to hear from chat_append() so it can print it's dialogue. But in cases where we don't want to be showing any chat_append(), we have no way of telling the ui "response done, remove the dots".

I would love to see a non-appending version of chat_append() which would also permit a NULL response. Currently, we can call chat_append("chat", NULL) and it doesn't error, but it doesn't do anything either, we just get dots forever as if we never called chat_append(). Maybe chat_return() or something like that? Does that make sense?

[gadenbuie]

Instead of chat_append("chat", NULL), try chat_append("chat", ""). It doesn't remove the dots, but it does enable submitting new user messages.

Does that make sense?

This makes sense at a technical level -- as in it's clear from the reprex how this doesn't work. But I'm not sure I understand how you're wanting to use the chat UI if there isn't also a chat response. If you could go into more detail into the desired use case that would help.

[cboettig]

@gadenbuie In my use case the app responds by updating charts, maps, tables and other things typically found in a shiny app, mostly by leveraging the tool use abilities of ellmer and LLMs.

For instance, in my current goal I want to let the user put in a species or other taxonomic group and show where it occurs on the map. The "typical" approach for this requires the user knows the precise scientific names (which aren't even consistent between databases). Doing pre-filled drop-downs doesn't scale well when we have ~ 3 million different names. I have an LLM call in ellmer that can 'guess' the taxonomy of the group ("hummingbirds", or "pika"), but then also has access to an R function that can call out to the parquet file of names via duckdb and verify the nomenclature matches.

There are many variations on this theme. In some cases it probably would be good for the bot to be able to ask clarifying questions etc, but my overall design goal here is that the app just feels like it has a small but intelligent "text box input" that can take actions on the app. I really don't want it to feel like a (text only) chat window where the usual rich visuals of a shiny app are all squeezed out to make space for a chat history.

Here's a minimalist sketch of this (using census data instead of species, and just using a vanilla textInput box instead of shinychat -- which as you see doesn't look nearly as good!): https://huggingface.co/spaces/boettiger-lab/geo-llm-r

[gadenbuie]

Sounds like this is a great match for our planned new input_submit() input: rstudio/bslib#1204

[gadenbuie]

@cboettig That's a really neat dashboard! I think input_submit_textarea() would work well in your use case. Since that's not ready, here's a little module you could use that's very close to what you have now:

mod_input_submit_ui <- function(id) {
  ns <- shiny::NS(id)
  
  div(
    class = "hstack align-items-start gap-2",
    textAreaInput(
      ns("input"),
      label = NULL,
      value = "Which four counties in California have the highest average social vulnerability?",
      width = "100%",
      rows = 1
    ) |> tagAppendAttributes(class = "m-0"),
    input_task_button(
      ns("submit"), 
      label = NULL,
      icon = icon("paper-plane"),
      label_busy = NULL,
      class = "btn-primary btn-sm m-0 h-100",
      style = "width: 3em; max-height: 3em"
    )
  )
}

mod_input_submit_server <- function(id) {
  moduleServer(id, function(input, output, session) {
    eventReactive(input$submit, input$input)
  })
}

You can see the module in action here on shinylive.

I think one way you could enable follow-up questions could be to include a button that opens a model or sidebar or some component that holds a chat_ui(). If you use chat_mod_ui() and chat_server_ui(), the conversation history with the first message from the simple text input can be shown immediately and it would let the user continue the conversation.

[cboettig]

@gadenbuie thanks for this, really helpful! (Definitely a more elegant use of textAreaInput, really like that!)

I'll explore more with this chat_mod_ui and chat_server_ui. I'd like the chatbot to be able to handle follow-up discussion and provide text-answers when necessary, while mostly

[gadenbuie]

You're welcome! The other fun change is using bslib::input_task_button() instead of a regular actionButton(), which gives you a nice spinner effect and prevents people from sending the same message repeatedly while waiting for the update.

Let me know if you have any questions or run into any issues if you try out the chat module!