Skip to content
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

Can't easily append to a chat_ui() that is dynamically rendered #4

Open
cpsievert opened this issue Oct 10, 2024 · 4 comments · May be fixed by #5
Open

Can't easily append to a chat_ui() that is dynamically rendered #4

cpsievert opened this issue Oct 10, 2024 · 4 comments · May be fixed by #5

Comments

@cpsievert
Copy link
Collaborator

cpsievert commented Oct 10, 2024

For example, one might expect this to work, but it doesn't

library(shiny)
library(bslib)

ui <- page_fluid(
  uiOutput("x")
)

server <- function(input, output, session) {

  chat_append("chat", "Hello, how can I help you?")

  output$x <- renderUI({
    chat_ui("chat")
  })

}

shinyApp(ui, server)
@cpsievert cpsievert linked a pull request Oct 10, 2024 that will close this issue
@jcheng5
Copy link
Collaborator

jcheng5 commented Oct 14, 2024

Something feels weird to me about fixing this scenario by delaying all the chat_append actions until after flush. What if chat_ui took an argument for the initial set of messages, would that fix any reasonable scenario?

@cpsievert
Copy link
Collaborator Author

It would definitely help, and probably worth adding regardless of before/after flush. Just curious, are you mainly concerned about the potential for "unresponsive" chats? And/or something else?

@gadenbuie
Copy link

TIL I learned that the following works (as in the slider value is 15 after app load) and I would definitely say that it also "feels weird" that it does.

server <- function(input, output, session) {

  updateSliderInput(session, "slider", value = 15)

  output$x <- renderUI({
    sliderInput("slider", "Slider", min = 0, max = 20, value = 0)
  })

}

@jcheng5
Copy link
Collaborator

jcheng5 commented Nov 26, 2024

@gadenbuie Feels like a total coincidence that this works; after each flush, the client happens to process all the successful outputs, then all the failed outputs, then all the input updates. I definitely intended all the updateXXXInput commands in a tick to all take effect at once, but I don't think @wch and I ever thought deliberately about whether it ought to happen before or after outputs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants