Simplify code to do away with macros, and use simple functions.

[dessalines]

I'd like to make some code simplifications here, but want your permission before I do so. A few things:

• There's a lot of pointless macros. Rust analyzer can't even properly check this due to the metaprogramming async function macros in use.
• Each form and response is defined three times for some reason. You should only need to define them once.
• Because you're using macros, you're not able to use simple rustdocs on the async functions.

[SleeplessOne1917]

I've simplified the code significantly in the branch preparing for v1.x. See: https://github.com/LemmyNet/lemmy-client-rs/tree/v1-alpha.

Regarding your points out of order:

Each form and response is defined three times for some reason. You should only need to define them once.

I've removed redundant macros. Now, each function is only defined once. There are now only 2 macros, both pretty simple:

impl_marker_trait, which has the following definition:

macro_rules! impl_marker_trait {
    ($trait_name:ty, [$( $impler:ty ),+$(,)?]) => {
        $(
            impl $trait_name for $impler {}
        )*
    };
}

The marker traits allow me to have on generic implementation for making requests, so having a way to easily add/change which forms/responses implement those traits without needing to have several lines of impl Trait for Struct {} is helpful, expecially since the macro is reusable for both forms and responses.

impl_client, which has the following definition:

macro_rules! impl_client {
    ($(($name:ident, $method:expr, $path:expr, $form:ty, $response:ty, $doc:expr)),+$(,)?) => {
        impl LemmyClient {
            $(
                #[doc = $doc]
                pub async fn $name<Request>(&self, request: Request) -> LemmyResult<$response>
                where
                    Request: Into<LemmyRequest<$form>>,
                {
                    self.client.make_request($method, $path, request.into(), &self.headers).await
                }
            )*
        }
    };

    ($(($name:ident, $path:expr, $doc:expr)),+$(,)?) => {
        impl LemmyClient {
            $(
                #[doc = $doc]
                pub async fn $name<Request>(&self, request: Request) -> LemmyResult<UploadImageResponse>
                where
                    Request: Into<LemmyRequest<&'static [u8]>>,
                {
                    self.client.make_file_request($path, request.into(), &self.headers).await
                }
            )*
        }
    };
}

I'm trying to further simplify this so that the exported LemmyClient struct doesn't have mathods that delegate calls to the private client field and have the macro put it in directly. Edit: I went and made this change. I also added doc comments to both of the macros defined and used internally in this crate.

Because you're using macros, you're not able to use simple rustdocs on the async functions.
It actually is possible using the #[doc] macro. You can see this done in the code example above where #[doc = $doc] is used. $doc is passed as a static str slice where the macro is called. For example:

impl_client![
// ...
(
        create_community,
        Method::POST,
        "community",
        CreateCommunity,
        CommunityResponse,
        // This argument becomes the comment that show up on docs.rs
        r#"Creates a new community.

HTTP POST /community"#
    ),
// ...
];

There's a lot of pointless macros. Rust analyzer can't even properly check this due to the metaprogramming async function macros in use.

Besides the number of macros being cut down now, I think the benefit of removing boilerplate (and consequently making the methods on the client easier to look through visually) makes it easier to add/alter the methods. The two macros defined in the v1-alpha branch are simple enough to keep looking good without rustfmt, especially since they won't have much reason to change in the future once these changes are released.

Incidentally, the only areas where I've been bothered by lack of rustfmt support are in the cfg_if branches in lemmy_client_internal.rs. I'm currently only using it since it's easier than adding a #[cfg] attribute on top of everything (although now that I think about it, I could just put the normal and browser implementations into their own cfg gated modules, making rustfmt happy and allowing my to remove cfg_if as a dependency) Edit: I also removed the dependency on cfg_if. As expected, the parts that used to be in its branches play a lot nicer with rustfmt now.

[SleeplessOne1917]

I've also just learned that reqwest actually supports browser APIs when targeting WASM. This removes the need to have different implementations of the client, which simplifies things considerably.

[dessalines]

Adding these functions to your LemmyClient impl would be no more verbose than the macro, and a lot easier to read and debug. I'd be happy to do it:

/// Creates site during initial setup.
///
/// HTTP POST /site
async fn create_site(&self, data: CreateSite) -> LemmyResult<SiteResponse> {
  self
    .client
    .make_request(Method::POST, "site", data.into())
    .await
}

I've also just learned that reqwest actually supports browser APIs when targeting WASM. This removes the need to have different implementations of the client, which simplifies things considerably.

Nice. Hopefully they have docs for that now, because I've had to use gloonet on a few other projects and its incredibly annoying.

[SleeplessOne1917]

Feel free to do it if you want. I currently have this arm for requests that take JSON:

#[doc = $doc]
pub async fn $name<'jwt, Request>(&self, request: Request) -> LemmyResult<$response>
where
    Request: Into<LemmyRequest<'jwt, $form>>,
{
    self.make_request($method, $path, request.into()).await
}

and this arm that take methods that take files:

#[doc = $doc]
pub async fn $name<'jwt, Request>(&self, request: Request) -> LemmyResult<UploadImageResponse>
where
    Request: Into<LemmyRequest<'jwt, &'static [u8]>>,
{
    self.make_file_request($path, request.into()).await
}

While I still disagree that using the macros would be just as verbose, think this usecase (repetitive code with minimal differences) is well-suited to macros, and think it's helpful to have the body of the function laid out in one place so that if I make a change I don't need to update every endpoint function, keeping things easy to maintain for the other maintainers/contributors is more important and I'm sure the "single source of truth" concern of mine could be easily addressed by just using grep and sed.

If you do decide to go through with it, I ask that you make the PR target the v1-alpha branch.

[dessalines]

I thought about it a bit more, and I think its worth doing, so I'll start it soon as a PR to your branch. Metaprogramming (especially function generation), can create so many unforeseen problems, especially that it makes your code and any errors from the functions untraceable. We could've done this a lot in the lemmy backend code, but intentionally avoided it due to all the problems it could cause. Traceability should always be preferred over code conciseness.

Also another benefit of this is that it would be possible to organize / group all the endpoints in separate organized files.