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

The "resolved" data field is not currently accessible #8

Open
acollierr17 opened this issue Jan 30, 2022 · 9 comments
Open

The "resolved" data field is not currently accessible #8

acollierr17 opened this issue Jan 30, 2022 · 9 comments

Comments

@acollierr17
Copy link

acollierr17 commented Jan 30, 2022

I've been working on utilizing this package in a new project of mine. However, I've hit a bit of a road bump trying to access the resolved data of an interactive response via a "Message Command." In this case, I'm trying to get data of the message such as the content.

Are there any plans for implementing this functionality? If so, any sort of timeframe? If any assistance is needed in regards to contributing, feel free to let me know and I'll take my best shot at it (as I've been going through the source code and docs a bit more since I found this package a few hours ago).
https://github.com/0x2b00b1e5/rusty-interaction/blob/6cefdf725d8028f981d186e6fc845560ac625a69/src/types/application.rs#L257-L259

@showengineer
Copy link
Owner

showengineer commented Jan 30, 2022

Hey, thanks for using this library.

Right now I haven't really been able to implement the resolved field yet. It's probably really simple but right now I have very little time to fix it as my main priority for this library is going to get rid of actix-web and use hyper as the http backbone (as this should improve performance and remove a lot of unused dependencies), and college asks a lot of time from me aswell. The fact that I am the sole developer and maintainer doesn't really help too. If you can, feel free to implement and PR it!

IIRC, the ResolvedData structure is a pretty simple data structure which should be easy to implement, as most of the parsing is done by serde.

If you don't have the time to implement it, I should be able to make it happen within 30 days or so, although I can't be completely sure.

@showengineer
Copy link
Owner

showengineer commented Jan 30, 2022

If you can't wait (which is fine of course). All the data you want can also be found in the Context.interaction field, which you should just be able to access.

@acollierr17
Copy link
Author

Moving to a hyper (or hyper-based package) seems like a good move! I was originally looking into using hyper before coming across this! I'll see if I can help as I'm genuinely interested in expanding my knowledge here!

For the ResolvedData, I haven't seen information such as the associated message with the interaction. Are there any extra steps I need to take?

@showengineer
Copy link
Owner

showengineer commented Jan 30, 2022

All I could find is the message object in Interaction. I would figure its put there.

So I guess trying adding a message field to Interaction would be a good start. I am not sure if a Message structure exists yet and I am also unsure if this message field is also added without having the upcoming read-messages intent. It doesn't really matter for the implementation itself (since the message field must be Option<Message> anyways), but it's good to have that documented.

@acollierr17
Copy link
Author

I was more so referring to the response found here. I see when I do <Context>.interaction.data, it gives me some information. however, it excludes resolved data such as the message(s) associated with the response.

That should clarify where I'm trying to come from.

@showengineer
Copy link
Owner

Ah I see now. ResolvedData shouldn't be hard to implement since it's just another data structure. I think Discord has documented it. Just make sure when implementing you use Option<Type>.

@acollierr17
Copy link
Author

Got it. Thanks for the assistance and insight. I'll mess about with this and see what I come up with!

@acollierr17
Copy link
Author

Hey, so I've been working on a PR with some of these new structs to add. I have a question about serde (as I'm fairly new to Rust). When do I use these macros and when do I not use them?

#[serde_as(as = "Option<DisplayFromStr>")]
#[serde(default)]

@showengineer
Copy link
Owner

showengineer commented Feb 1, 2022

So sometimes you have to tell serde how to 'read' the data and what it should output. So in the case of Snowflake, which is a type alias for u64, DisplayFromStr will serialize the data with Display, and deserialize it with FromStr. The reason [ #[serde(default)] comes afterwards is because of the Option<>, which is explained here

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

No branches or pull requests

2 participants