feat: Add `set_chat_client()`

[schloerke]

**Updated to set_chat_client() given comment below

---

Method to add your (currently only) {ellmer} chat model the UI.

Ex API:

shinychat::set_chat_model(id, model, ..., bookmark = TRUE)

Assuming your {shinychat} ID is "chat"...

Goals:

• Error if model is not an {ellmer} chat model.
  • Provide error message on submitting GH issue for extension?
• Given bookmark = TRUE,
  • Require bookmarking to be enabled: stopifnot(shiny::getShinyOption("bookmarkStore", "none") != "none")
    • Provide example in docs on how to exclude some input in the example app.

      # Escape bookmarking all inputs
      shiny::setBookmarkExclude("big_input_name")

  • Save minimal chat information: role, contents
    • shiny::onBookmark() callback
    • content should be the markdown of each turn's contexts.
      • Using markdown escapes us from different content types and is more than just text. ellmer::contents_markdown() will allow us to escape the s7 serialization difficulty (related Consider serialization RConsortium/S7#225).
  • Restore minimal chat information: role, contents
    • shiny::onRestore() callback
  • Updates the url on user input / server output change
• Opens the door for future integration with the model

Bonus goals:

• Update the URL on markdown stream update
• Send multiple chat messages at once, not one at a time.
  • Avoids multiple shinychat::chat_append("chat", stream) calls.
  • Single scroll to bottom call. This currently is broken when many updates happen within the initial transition.

Possible approaches:

• Use shiny::getQueryString() and shiny::updateQueryString()/httpuv::encodeURIComponent() to quickly insert chat information within the query string.
  • This would not require bookmarking to be enabled.
  • Feels hacky (but a great approach for py-shiny until full bookmarking is enabled!)

---

Rejected ideas

We had working code to restore the UI dynamically, but the user story is much simpler to add a single call in the server.

• Restoring the UI would also require reaching inside shiny for shiny:::getCurrentRestoreContext()$values.
• Restoring the UI would also require both a UI and a server flag (of some kind). With shinychat::set_chat(ID, model), we can restore values quickly and in a single location.

ui <- page_fillable(
	shinychat::chat_ui("chat", height = "100%", bookmark = TRUE)
)

server <- function(input, output) {
    model <- ellmer::...()

    shinychat::set_chat_bookmark("chat", model, TRUE)
    # or 
    shinychat::set_chat_model("chat", model, bookmark = TRUE)
}

The complexity didn't outweigh the very minor blip of chat messages. This can be significantly reduced if "send multiple chat messages" is added.

[schloerke]

Writing up posit-dev/chatlas notes here as the ideas are of the same intent:

Theoretical interface:

• chat.set_model(chat_model: chatlas.Chat, /, *, bookmark: bool = True)
• The model will need to implement two methods:
  • .as_json() -> list[{contents: str, role: "user" | "assistant"}] to save the simple role and contents of each turn
  • .from_json(info: list[{contents: str, role: "user" | "assistant"}]).

[gadenbuie]

Just a drive-by comment about naming to say that I'm worried that the word model in set_chat_model() will cause confusion. Personally, I think client might be a better term since the object it references encompasses both the provider's interface and a specific model.

[schloerke]

Adopted set_chat_client()!

[schloerke]

Updated to chat_enable_bookmarking(id, client)