Typo in type definition on ServerReactionMessage: messsage_id

[yairiff]

Just small thing, on types.d.ts:

export type ServerReactionMessage = {
type: "reaction";
reaction: {
emoji: string;
messsage_id: string;
};
};

on line 465 it says messsages with 3 s..
I used intellisense and obviously it took me quite some time to figure out why i get undefined id
sorry for not being able to make PR myself for that minor thing, I need to learn how to do so sometime...

[Secreto31126]

Nice catch! Don't worry, I can make the PR.

Thanks!

[Secreto31126]

Hi!

Sorry I'm talking to you through a closed issue, but you had been among the people who had been using the library the last few weeks and I would love the input from someone who had been working with it.

What's your opinion on the v4 update? Do you think it's a step forward or backwards? Is the new post return value an improvement or a hustle to use? What else do you think could be improved?

Lots of questions :)

I'm asking because since the breaking update I noticed the npm downloads had tanked a lot, and even myself have mixed feelings about the new system. I haven't used the library from the user end for a few months, so I get the feeling I got out of touch with it.

Let me know what you think!

Thanks, and sorry to bother.

[yairiff]

Hi! First, you don't have to apologize, your package helps me a lot, and I appreciate your time and effort. I would be happy to contribute. TBH, I did not notice yet for the breaking change about the post signature, for 2 reasons: 1. Since I'm using Azure Functions and I wrote a custom middleware using the very successful WhatsAppAPIMiddleware class, and I see that middleware is not affected (do you think my middleware will help some folks there?) 2. Also, in the last 2 weeks mainly focus on my project's client side, only updated the dev server to v4 while actual Meta's webhooks goes to the production server, still on v3. I don't see why this could be a backwards step; it definitely may help users who want to quickly accomplish simple tasks. Or, for event handler approach users like me, it’s the same, but not worse by any means. I can imagine endless possible directions for this package to go, but things should be prioritized. I specifically have edge cases like template management, statistics, and even WABA registration process, but I don't expect these to be within the scope of that package. For general users who probably manage their WABAs in Meta's portal, I thought about some common needs that can be handy to have: 1. Regarding broadcastMessage, which works well with the last batching and timing update: I thought about bulk personal messages, which is very useful tool in a lot of scenarios. Since we have to use templates for broadcasts in 99% of the cases anyway (due to 24-hours WhatsApp policy), there can be a signature of broadcastMessage that instead of simple message, takes a function that gets id as phoneId as an argument and return parameterized template message for each phoneId. Maybe, since generally the phoneId value won't be that helpful for creating the content (requires additional search in the user's data), consider even further customization: a. Take array of generic type T instead of phoneIds. b. Take function for extraction of the phoneId from T. c. Take additional function for composing the content from T, as same as described before. That would enable straightforward usage with custom user data. 2. Errors tracking – I think that onError can be quite useful. I know errors can be returned directly from the send request, and also can be supplied in later status updates. Maybe it would be nice to have a centralized place for handling all the errors. 3. Status tracking - I don't know exactly how, but it's hard to track statuses. Sometimes Meta sends them not in the right order, and the message is 'delivered' and only then 'sent'. WhatsApp payload scheme allow for aggregated messages (they can and should return batched updates using the messages, statuses, and errors array. I didn't face any update of that kind from them, maybe it reserved for very high throughputs. Anyway, I thought about a kind of a buffer that holds the updates and release them on custom intervals. I don't know if that the most elegant and correct solution for the problem. These are just some ideas… UPDATE: I see that your implementation does only check only for messages[0], statuses[0]. I will load test that, to see if there can be more than one. Meta's docs are as unclear as always... As for npm, I've noticed that the package does not appear in even in typical google search such as "whatsapp api npm" and really don't know why. This package should be more relevant for that search than any of the suggestions there (non-maintained, unofficial api, specific client with ui)… I didn't notice a major drop at the weekly downloads graph there, but probably you have access to more stats… I would be very happy to help as much as I can… Thanks for sharing your thoughts with me.

[Secreto31126]

Oh wow, I absolutely wasn't expecting such a detailed and complete reply, really appreciate it!

I love your ideas, the broadcast message with a function is awesome, and the error emitter sounds like a really usefull feature. The only one I'm not sure it would work is the status tracking, mostly because it would break on serverless enviroments, but I will try to think a way around for it.

I'm really happy to see that you like the middlewares, and the fact you were able to create your own sounds crazy to me. I absolutely wasn't expecting it to be a popular utility, mostly because there aren't a lot of them available. If you can/want, I would gladly include your implementation with the integrated ones (with the corresponding attribution, of course).

And about the npm statistics, yesterday it showed only 300 weekly downloads (an 85% decrease), and today it says 0. I thought it was due to v4 having issues or people didn't like it, but now I believe it must be a bug on npm side.

It's really weird, but at least I know it's not because v4 wasn't good. The SEO never was on my side, I did my best to increase the docs visibility, but unfortunately it's hard to compete against the well stablished and many years old packages.

I will try to implement your ideas along this week, and if you decide to try v4 in your proyect I would love to hear your thoughts.

Thanks for the help!

PS: I decided to refresh the website just after sending the reply, and seems like the statistics are back to normal 😄