Get all available keys in DialogResponseView

[HSGamer]

This PR adds a new method in DialogResponseView to get all available keys.

I don't know if there is any real-world usage with this, but in my case, I need a way to convert a response view to a simple String-Object map without reflection.

[Machine-Maker]

Can you use the adventure-nbt library? (Or any nbt library) and parse the BinaryTagHolder? I think that is the solution here for your specific usecase.

[HSGamer]

Can you use the adventure-nbt library? (Or any nbt library) and parse the BinaryTagHolder? I think that is the solution here for your specific usecase.

I don't like to shade another library just to do this. Since there is already CompoundTag in DialogResponseView, why not a method to get all the keys from the compound?

[Machine-Maker]

Because there is no guarantee that the value at that key can be parsed with any of the 3 get methods. I don't really want to expose keys that don't work with those methods. There is already no guarantee that the values that can be obtained via the 3 methods actually came from a dialog input.

[HSGamer]

Because there is no guarantee that the value at that key can be parsed with any of the 3 get methods. I don't really want to expose keys that don't work with those methods. There is already no guarantee that the values that can be obtained via the 3 methods actually came from a dialog input.

Since all getters in the View are Nullable, we don't really care about the guarantee. Even if we parse the inputs, we only care about the values that can be retrieved from the response.
At the moment, the values of the response are either from dialog inputs or the additions from Custom Action.
The fact that CompoundTag is used does imply that these values are expected. Unless there is an otherwise, the only case that the value cannot be retrieved from the 3 getters is that the additional values in Custom Action is not one of the 3 types.
The fact that we need a key in those getters means that we need to know the key of the dialog inputs before getting the input values. So I don't think there is a risk.

[HSGamer]

Interestingly, the response view already parses the payload to a compound tag, but we would need another NBT library to do the same without using reflections.

[HSGamer]

I already used reflections to get the underlying compound of the response view so this is not a big deal for me.
This is just about ease of use. I just need a way to get the available input keys in the view, without using reflections or another NBT library to parse the whole payload just to get the keys.

[lynxplay]

I agree with machine here, one major point of this interface was that it does not promise being authoritative in regards to its content. It is a minimal bare bone abstraction over what could be a dialog response for people to use.

Any method promising to know what actual data is contained in it is just misleading imo.
Including adventure-nbt in the API or maybe the server + compileOnly() on plugins might be something that can be discussed to make working with the binary tag holder easier but such a method imo is not something I want in this API.

Thank you anyway for the PR!
If you still believe there to be a need for this, we can iterate on this problem in a feature request instead, maybe there is something there but, as I said, just from the result the keys of the dialog are not something we can know/expose.