Thank you for the update! 🎉

Due to our current reduced availability, the initial review may take up to 10-15 business days

This is my first time contributing to an extension, I apologize if this is the right way to publish it.

Also, this change is quite significant, I rewrote most of the API to use MALs authenticated API using my own clientId.
if @luknl wants to create his own oauth app on their website that is fine by me.

Will be fixing some of the issues from CI, however I'm unable to run linting since @typescript-eslint/eslint-plugin fails to update. Will be trying to solve it on my own for now but if anyone knows the solution I'd love to get a hint lol

Hi @KibbeWater and thanks for your contribution, you did a big job there!
Had a quick look, few concerns:

• Using your clientId doesn't seem that scalable no? Don't they have a restriction and block you seing many different IPs are trying to connect to it?
• It's also fully exposed in the oauth file, is that ok?
  Thanks!

Few other things:

Could you add an icon here like the other actions? Also, this needs to be conditional, if it's already in the watchlist. In which case it should show and do the action of "Remove from watchlist".

• Change the description "Easily search and open animes on Myanimelist." to reflect your changes, in package.json and CHANGELOG.md
• Also change the CHANGELOG.md with your changes
• uniform the image here on the list view of the "search animes" action and the "manage watchlist" one
  
  
• It would also be good to differentiate between the animes you're currently watching VS planning to watch. Maybe an icon next to the image, or like a text like MAL does (CW vs PTW)
• you need to replace line 45 in file /src/api/api.ts, to be rating: z.string().optional().default(""). Otherwise there is an error with entries that don't have rating (because in PTW, I guess you didn't have the error cause the first returned animes in your case must be CW and not PTW?)

• you need to replace line 45 in file /src/api/api.ts, to be rating: z.string().optional().default(""). Otherwise there is an error with entries that don't have rating (because in PTW, I guess you didn't have the error cause the first returned animes in your case must be CW and not PTW?)

afaik there should be no errors caused by this (unless you got any?). All anime's returned thus far have had a PG rating in my testing, but honestly hard to tell since return data is so terribly documented through their APIs.

• Using your clientId doesn't seem that scalable no? Don't they have a restriction and block you seing many different IPs are trying to connect to it?

I have tried looking up mentions of rate-limiting through their API, however seems to be none. From my testing it will temporarily block you if you excessively query the API at unreasonable amounts (like what you'd see during testing or development), but should be fine for normal use. Even then I believe it should only be at the users IP level and not throttle all queries for that application as PKCE OAuth is made to work in environments where you can't trust the client

• It's also fully exposed in the oauth file, is that ok?

Yes, OAuth PKCE is made for environments like standalone apps where you can't trust the client

Ok thanks for all your changes.
The "Manage Watchlist" is not working on my side anymore after pulling. Also the search sometimes load infinitely. Could this be API limit?

Also potential further improvements I see possible are:

• Change between list/grid view from quick action rather than via the extension settings.

The "Manage Watchlist" is not working on my side anymore after pulling. Also the search sometimes load infinitely. Could this be API limit?

I think so, or some sort of throttling from CloudFlare. I often get hiccups like that after I have been calling the API a lot, maybe the caching I put in place isn't working? Will have to dig a bit deeper

• Change between list/grid view from quick action rather than via the extension settings.

I went ahead and added something on the line of this, similar to the details view it has to override the preference values cause we can't directly set it. Maybe we could have some sort of local storage solution so that we can persist the state even after closing out of the command. As it is now, it's a bit jarring when you switch view, go out and come back into the old view again, but I don't either wanna remove the options from extension settings since I still want it to prompt users for preference on first-time use

I'll probably see if I can feature request so that we get some sort of API for actually setting these preference values through code somehow

Was probably a very large oversight on my end, since my watchlist isn't particularly big, it was able to load just fine even with the excessive API calls. Since we require extra data for each anime in a watchlist to properly display it, we had to query each anime individually. Wasn't a problem for me but found that one of the functions didn't cache properly and made it have to re-query every time you viewed the list

The rate-limiting should be mostly resolved, but will put in feature requests on their forums to allow for more bulk querying so that we don't have to resort to spamming their API with a bunch of requests every time we need up-to-date information about a users watchlist

Ok another batch of changes, nice, thanks again for your contribution!

About this error, here is what I have, that might help solving the issue:

Generated by cloudfront (CloudFront) HTTP3 Server
Request ID: 0SyeQ24fnoQK0Xi9eKoa2v_IctcpnJZyApKUTQxODmeFslkM4ClLOA==
14:24:37 get episodes watched error: <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<TITLE>ERROR: The request could not be satisfied</TITLE>
<H1>504 Gateway Timeout ERROR</H1>
<H2>The request could not be satisfied.</H2>
We can't connect to the server for this app or website at this time. There might be too much traffic or a configuration error. Try again later, or contact the app or website owner.
If you provide content to customers through CloudFront, you can find steps to troubleshoot and help prevent this error by reviewing the CloudFront documentation.

When I first pulled, the manage watchlist was working, so maybe it started with the implementation of the caching system.

Haven't had much time to work on the PR the past few days.

How big approximately are your lists? Will probably add some debug views to monitor the number of API calls or something, may prove useful for debugging.

Could maybe reduce API calls by using the Jikan API for some calls using batching if they support it, could theoretically get it down from O(n*2) calls to O(n+1)

The PUT requests for the item progress would still be required however

looks good, you can merge whenever. Thank you for the help guys o7

Published to the Raycast Store:
https://raycast.com/luknl/myanimelist-search

🎉 🎉 🎉

Such a great contribution deserves a reward, but unfortunately we couldn't find your Raycast account based on your GitHub username (@KibbeWater).
Please link your GitHub account to your Raycast account to receive your credits and soon be able to exchange them for some swag.