Goal : The serialized ApiObject should be same as the json response getted from Mangadex API.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Open

These updates have all been created already. Click a checkbox below to force a retry/rebase of any.

• Update Rust crate serde to v1.0.200

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Hi, I'm the former maintainer of the mangadex-api crate. Would you like to take ownership of it? Having multiple crates with similar names will only cause confusion imo.

As always, some languages are missing.
I don't know how many languages missing but it seems like Mangadex added a bunch recently.

The Plan:

1- List all Mangadex supported languages:

Should be easy:

• Just go to the mangadex.org,
• click to user icon at the top right
• go to chapter languages
• list them all

2- Implement them :

Mangadex uses the ISO 639-1 standard.
All "currently" supported languages is here : mangadex-api-types::language::Language

When using chapters or add_chapter, such as the below

let mut chapters_res = client
    .search()
    .chapter()
    .add_chapter(String::from("1"))
    .manga_id(&manga_id)
    .limit(limit)
    .build()?
    .send()
    .await?;

Sending it yields an error like so

Error: an error occurred with the MangaDex API request: MangaDexErrorResponse { errors: [MangaDexError { id: 9c346772-7b14-5982-b4b6-7b5888522762, status: 400, title: Some("validation_exception"), detail: Some("Error validating : The property chapters is not defined and the definition does not allow additional properties"), context: None }] }

Upon serializing it, I see this output

{"limit":10,"offset":null,"ids":[],"title":null,"groups":[],"uploader":[],"manga":"4e7a4a0f-8391-4069-839b-de2352297dab","volume":[],"chapters":["1"],"translatedLanguage":["en"],"originalLanguage":[],"excludedOriginalLanguage":[],"contentRating":[],"excludedGroups":[],"excludedUploaders":[],"includeFutureUpdates":null,"createdAtSince":null,"updatedAtSince":null,"publishAtSince":null,"includeEmptyPages":null,"includeExternalUrl":null,"includeFuturePublishAt":null,"order":null,"includes":[]}

Notice chapters. From the mangadex api I see a parameter named chapter but not chapters

Indeed, using a query like this results in the same error
https://api.mangadex.org/chapter?limit=10&manga=4e7a4a0f-8391-4069-839b-de2352297dab&chapters[0]=1&translatedLanguage[0]=en
Whereas this one works
https://api.mangadex.org/chapter?limit=10&manga=4e7a4a0f-8391-4069-839b-de2352297dab&chapter[0]=1&translatedLanguage[0]=en

Example: https://api.mangadex.org/chapter?translatedLanguage[]=la

RequestError(
    reqwest::Error {
        kind: Decode,
        source: Error("unknown variant `la`, expected one of `ar`, `bn`, `bg`, `my`, `ca`, `zh-ro`, `zh`, `zh-hk`, `cs`, `da`, `nl`, `en`, `tl`, `fi`, `fr`, `de`, `el`, `he`, `hi`, `hu`, `id`, `it`, `ja`, `ja-ro`, `ko`, `ko-ro`, `lt`, `ms`, `mn`, `ne`, `kr`, `no`, `fa`, `pl`, `pt-br`, `pt`, `rm`, `ro`, `ru`, `sr`, `es`, `es-la`, `sv`, `th`, `tr`, `uk`, `vi`, `NULL`", line: 0, column: 0),
    },
)

i need to know what feature you wanted to add in the crate.

I have a bunch of stuff 😅 ...
There are probably more I can list but this is already a lot.

• Compile times are painfully slow. As a library, minimizing the compile times should be a priority. Removing external dependencies in favor of building things manually in the project would probably be a good starting place.
  • anyhow and thiserror can be replaced with an error type that is manually implemented rather than derived. See burntsushi's comment https://libreddit.spike.codes/r/rust/comments/gj8inf/rust_structuring_and_handling_errors_in_2020/fqlmknt/?context=3 for some guidelines.
  • derive-builder can easily be done manually and would be good to remove.
• More structs and modules should be made public. This is currently making it impossible for some to compile their programs simply because they can't define the type in their functions.

  error[E0603]: module `manga_aggregate` is private
    --> src/events/components/manga_reader.rs:48:132
     |
  48 | ...ponentInteraction, manga: mangadex_api::v5::schema::manga_aggregate::MangaAggregate) {
     |                                                        ^^^^^^^^^^^^^^^ private module
     |
  note: the module `manga_aggregate` is defined here
    --> /home/jp/.cargo/registry/src/github.com-1ecc6299db9ec823/mangadex-api-1.3.0/src/v5/schema.rs:14:1
     |
  14 | mod manga_aggregate;
     | ^^^^^^^^^^^^^^^^^^^^
  

• The API could be made more ergonomic. The builder pattern felt clunky whenever I tried to use my own library.

  let manga = client
      .manga()
      .aggregate()
      .manga_id(&manga_id)
      .translated_language(languages)
      .build()
      .unwrap()
      .send()
      .await;

Owner Edit: This syntax doesn't work since v3
So the following example should be:

    let manga = client
        .manga()
        .id(your_manga_id)
        .aggregate()
        .get()
        .translated_language(languages)
        .send()
        .await
        .unwrap();

• #112
  Owner Edit : It won't work since the old login system is deprecated
• I'm not sure that breaking up the project into workspaces (mangadex-api-types, mangadex-api-schema) was worth the trouble. It might be good to put them back into a single workspace but I can't say which is better honestly.
• The v5 module is probably unnecessary. I made it because of the potential of future major API versions since at the time I made it, there was a v2 and v5 of the MangaDex API.
• Having WASM compatibility would be nice.
• It would be good to see more String fields converted to an enum type where appropriate. Here is one example:

  mangadex-api/mangadex-api-schema/src/v5/check_token_response.rs

  Line 7 in a4da7a1

  pub roles: Vec<String>, // TODO: Deserialize the strings into `UserRole` enum.

• I'm not maintaining this crate for the foreseeable future so I don't need to be included in the list of authors

Notes about some of the custom deserialization I added:

• language_array_or_skip_null exists because there are some manga that have null in the availableTranslatedLanguages field. (Example manga: https://api.mangadex.org/manga/a96676e5-8ae2-425e-b549-7f15dd34a6d8)
• localizedstring_array_or_map used to be necessary for the .data.attributes.description field of https://api.mangadex.org/manga/fe38c4c2-8cea-4f91-9e80-b368172bdd5c but it looks like that has been fixed.
• volume_aggregate_array_or_map fixes an issue with some manga aggregate results where the .volumes.0.chapters field would be an array instead of an object. For example, https://api.mangadex.org/manga/d773c8be-8e82-4ff1-a4e9-46171395319b/aggregate. This one has "none" as a key within .volumes: https://api.mangadex.org/manga/14e157c3-7856-4f86-a2d2-8faa86660744/aggregate

Originally posted by @gondolyr in #1 (comment)

Just ealier, an OpenAPI spec changes pull request have been opened on the MangaDex API Docs repository

Edit:
It's now deployed so this update will come very soon

To summarize, there is some notable changes:

1- a new endpoint have been added: POST /upload/check-approval-required

Check if a given manga / locale for a User needs moderation approval
Body Schema :

• manga: Uuid (the mangaID)
• locale: Language

Possible response schema:

• 200 : ok

{
   "result": "ok",
   "requiresApproval": true | false
}

• 404: the manga is not found

{
    "result": "ok"
}

2- Removed all /account endpoint:

Since MangaDex Authentification migrated to OAuth 2.0, these endpoint will be removed in the next version.
but DELETE /user/{id} and POST /user/delete/{code} is still there so... I don't know what to tell about this.

3- Added namicomi on the AuthorLinks structs.

Todo list:

• #191
• #188
• #190
• #189

• Add a function called find_relationship in ApiObject like :

pub fn find_relationships(type: RelationshipType) : Vec<RelationShip>

Rate limits can change depending on the number of load balancers that are active. The API call responses includes header meta data related to these rate limits.

In the short term I would suggest adding these headers to the mangadex_api_schema::ApiData struct to allow user code to utilise this meta data.

https://api.mangadex.org/docs/rate-limits/

NEED ATTENTION

If you don't know, Mangadex API Team (that doesn't include me) realease a new breaking change in their follows and custom list system.
Reference here
As for that, i'm now preparing for having a new breakin-change realease this weekend or next week.
Owner Edit: The v3 developpement took 5 months though 😅.
As a preparation, i will tell about what we will change :

1- The new follow/custom list system

I don't know about the details of it but i will reference this in a new issue

2- The RateLimit metadata

Ref #26

3- A new syntax

Example :
Let's say we have an endpoint like this:
GET /manga/{id}
then you should have an invoke syntax like this:

// Note: the `client` is the `mangadex-api::v5::Client` here 
client
    .manga()
    .id(/*your manga id here*/)
    .get()
    .send()
    .await?;

or

GET /chapter
Path Parameters
=============
- chapter : uuid[]
- manga : uuid
- includes : IncludesReferenceExpansion[]

should be :

client.chapter().get().chapter(/*your chapter id list*/).manga(/*your manga id*/).includes(/*your include reference enum list*/).send().await?;

Notice that there is no .build()? in this syntax.

I want to make it like that because it's overhelming to maintain the API with all of those weird function.

4- A dedicated tauri-plugin

ref : #10

Thanks for understanding.

• statistics/group is the statistics of groups
• statistics/chapter is the statistics of chapter

the types is already done in 9-correctly-implement-serialize-in-types so it should be done quickly after that.

This ApiClient endpoint has been added in Mangadex API 5.10.0
There is no official announcement in the Mangadex Discord.
But we should implement it (even if i don`t know what it is)

Note : This ApiClient endpoint requires authentification.

Tasks :

Implements :

• #75

• #78

• #81

• #83

• #84

• DELETE /client/{id} : Delete ApiClient

• GET /client/{id}/secret : Get Secret for Client by ID

• POST /client/{id}/secret : Regenerate Client Secret

Since all /account endpoints is deleted, it's should be fine if remove all /accounts related types