Add methods for shaping response events

[alexisabril]

Helper method(s) could be defined to assist in the shaping of a Copilot Chat response or the streaming of the response. Response shapes are a common issue, with inconsistencies from developers around:

• specifying types
• how to break apart chunks
• proper formatting of chunks
• proper termination of response
• what types of chunks can be grouped in a singular response

[gr2m]

I started some dreamcoding. It doesn't answer the questions of how yet, but it helps me understand if this is the direction we want to go. I'd love to hear your thoughts:
https://github.com/copilot-extensions/preview-sdk.js/blob/main/dreamcode.md

In terms of shaping responses, I'm thinking to have set of methods matching our types, like text (for default), confirmation, etc (haven't looked further yet 😅 ).

The low-level methods could work two fold. For one, we have methods for each type that creates respond objects, e.g.

const confirmationObject = confirmation({
  title: "Would you like to hear a joke?",
  message: "I have a joke about construction, but I'm still working on it.",
  id: "joke",
  // optional
  meta: {
    other: "data",
  },
});

Where confirmationObject would look like this

{
  "event": "copilot_confirmation",
  "data": {
      "type": "action",
      "title": "Would you like to hear a joke?",
      "message": "I have a joke about construction, but I'm still working on it.",
      "confirmation": {
          "id": "joke",
          "other": "data"
      }
  }
}

and then a separate method which takes these objects that we support and turn them into an SSE-compatible line

const line = toServerSideEventLine(confirmationObject)

where line would then look like this (note the two \n\n at the end 😅 )

event: copilot_confirmation
data: {
	"type": "action",
	"title": "Would you like to hear a joke?",
	"message": "I have a joke about construction, but I'm still working on it.",
	"confirmation": {
		"id": "joke",
		"other": "data",
	}
}

The line could then be directly passed into a standard node response object

response.write(line)

This is really just me thinking out loud, usually I'd think more before bothering folks with notifications. But given the short timeline there is no time for such niceties 🙇

[gr2m]

Had a chat with @alexisabril and he suggested to add a .toString() method to the objects returned by response building block methods such as confirmation. So instead of

const confirmationObject = confirmation({
  title: "Would you like to hear a joke?",
  message: "I have a joke about construction, but I'm still working on it.",
  id: "joke",
});
const line = toServerSideEventLine(confirmationObject)
response.write(toServerSideEventLine)

we could do

const confirmationObject = confirmation({
  title: "Would you like to hear a joke?",
  message: "I have a joke about construction, but I'm still working on it.",
  id: "joke",
});
response.write(confirmationObject) // calls `confirmationObject.toString()`

I like it!!

[gr2m]

I added the list of methods I want to build as sub issues. The list as of now is

• createAckEvent()
• createTextEvent()
• createDoneEvent()
• createConfirmationEvent()
• createReferencesEvent()
• createErrorEvent()

I thought createAck() or just ack() is to ambivalent, especially for createError(). Appending Event makes it more clear. Appending ResponseEvent() might make it even more clear, and I don't mind long method names as long as they serve clarity.

Any thoughts?

[alexisabril]

This is something I struggle with myself and I could lean either way. Do we have any precedence in Octokit today for these types of methods? Thoughts that occur to me:

• If this is new and standalone, I'm in favor of the above
• If this is nested, such as ...copilot.events.createAckEvent(), then we could potentially remove Event from the name if the parent shares the name
• I'm a fan of the scheme createAckEvent in general vs a Parent.createX signals to me some type of other interaction, such as proto-chain wiring or maintaining state.

The above are my raw thoughts, but tldr; I'm leaning towards the proposed API unless this would introduce inconsistency with an existing Octokit API.

[github-actions]

🎉 This issue has been resolved in version 2.1.0 🎉

The release is available on:

• npm package (@latest dist-tag)
• GitHub release

Your semantic-release bot 📦🚀