ClientMessageRequest has incomplete types, why?

[tecoad]

I have a requirement to save the raw data sent to whatsapp to be recovered later on.

However, i just noticed that the ClientMessageRequest type has incomplete data structure, which means that text, audio, document, image, sticker, video, location, contacts, etc... are all considered a flatened strings, when should be an object.

Any specific reason for this, @Secreto31126 ?

At: https://github.com/Secreto31126/whatsapp-api-js/blob/d67fbeaeab5dc10c1b9da9dc35ba0e4a52a45cfd/src/types.ts#L382C7-L385C8

  | {
          type: "text";
          text?: string;
      }
    | {
          type: "audio";
          audio?: string;
      }
    | {
          type: "document";
          document?: string;
      }
    | {
          type: "image";
          image?: string;
      }
    | {
          type: "sticker";
          sticker?: string;
      }
    | {
          type: "video";
          video?: string;
      }
    | {
          type: "location";
          location?: string;
      }
    | {
          type: "contacts";
          contacts?: string;
      }
    | {
          type: "interactive";
          interactive?: string;
      }
    | {
          type: "template";
          template?: string;
      }
    | {
          type: "reaction";
          reaction?: string;
      }

[Secreto31126]

Hi!

The ClientMessageRequest is the object that will be sent to the API, which expects the body to be a stringified JSON, hence all strings. I'm guessing you are probably looking for ServerMessageTypes for your use case, which are defined just a few lines below on the same file.

The types are a little underdocumented unfortunately, they do get a little confusing specially for scenarios like your. I will keep a mental note to improve them for the next release.

Hope this helps!

[tecoad]

@Secreto31126 Thats not actually the same thing. ServerMessageTypes refers to the raw data which is received by the whatsapp post request. I am refering to the data which is being sent by the client instead, the structures are quite different. For example, audio, document, video... have a link data inside the respective object. You can check them for example here

[Secreto31126]

Sorry for taking some time. I misunderstood you, I thought you needed the received data, my bad.

Unfortunately the library doesn't need those types internally, as it uses the ClientMessage abstract class to handle the typing, and are stringified with the _build method to the API compliant structure.

When I wrote the code to create the messages structures (all the way back to 0.0.1!) the objects were always stringified, and I'm quite certain it was an API requirement. I just went through a few examples in the documentation, and it seems this is no longer the case, or at least they don't mention it.

PS: I got into the rabbit hole that is WayBack Machine just to find out, and it turns out it was never a string in the examples! I'm actually stunned now, as I clearly remember having issues with the API because it didn't recognize the payload except when it was stringified.

The rabbit hole

I will be checking this out as soon as possible, as it would be something interesting to add/fix. Sadly, right now I'm occupied with uni, gotta deploy a Spring MVC and JavaX JSP webapp due by mid October.

I miss TS 🙃

Once again, sorry I will take some time until I can sit down and handle this issue.

Thanks for reporting!