Advanced Search > Filter : option to client side display reading/completed/dropped/etc. titles differently from other titles

[MrMichael]

PROBLEM: Sometimes with the advanced search results it takes me a few seconds to realize that I am already reading or have dropped a title because of the frequently changing cover art and even occasional change of the title from JP to EN.

SOLUTION: It would make it easier for me as a user to parse through something like this if, client side, I could gray out mangas I have already read/completed/dropped and just slap an "Opacity: 0.1" on the div.manga-card of the titles which I would choose to display differently from the "Advanced Search" > "Filter" interface. A possible superior alternative might be some little pictograms in the corner which would represent my status with the title but that sounds more work intensive since it modifies layout.

EXAMPLE 1:

https://imgur.com/a/iVQWzlW

Attached is an example where "The New Gate" manga would be a part of one of the undesirable selectable categories(mainly Dropped / Completed / Reading / On Pause) The same total number of titles per page remains and the layout is not changed in any way and no extra server requests are made if every result on the whole page is read/dropped/etc. but it is FAR easier for a user to not get stuck on a series he already dropped and not realize until he goes to the titles page and sees its status.

EXAMPLE 2: If you want to see other similar implementations of this solution on bigger platforms you can check it out on "nhentai" if you are over 18 (which I will not link here) by excluding certain languages in your profile and then returning to the home page to see titles belonging to those languages grayed out client side.

Thank you for the great work you've done on this site and have a great day !

 

[HelperHand]

It has been asked in the past

 

[MrMichael]

It has been asked in the past

I don't know whether it's been asked in the past or not however the suggestion you are linking is different from this one.

What is being discussed there involves changing how the search happens on the database server and makes more work for the servers every day.

What I am asking involves only work in the user's browser since it does not change what results the query returns.

Maybe there's something I'm missing but from what I can see in that post they sound different to me.

edit: I've read the answer more and I do see a part near the end where they reject client filtering on the basis of overfetching however what I am asking is for the titles to be grayed out which means the search results still return the same 32 titles per page and no additional fetching is made until the user clicks on the next page button at the bottom of the page.

 

[Roler]

What I am asking involves only work in the user's browser since it does not change what results the query returns.

The query returns only public data, not what's in your library.
The site would have to check if every title on the page is followed and its status, resulting in 64 (or more, depending on your settings) additional requests.

The tag pages do use this method (you can see it by hovering over the "Trending this year" titles), although only for 10 titles (making 20 additional requests).

Honestly, it might seem fine to just check only if the title is followed or has a status, making 32 requests, but if you have set 100 titles per page, then it would make 100 requests.

Or do you mean graying out the titles completely by hand, which, doesn't sound practical at all...

 

[MrMichael]

The query returns only public data, not what's in your library.
The site would have to check if every title on the page is followed and its status, resulting in 64 (or more, depending on your settings) additional requests.

The tag pages do use this method (you can see it by hovering over the "Trending this year" titles), although only for 10 titles (making 20 additional requests).

Honestly, it might seem fine to just check only if the title is followed or has a status, making 32 requests, but if you have set 100 titles per page, then it would make 100 requests.

Or do you mean graying out the titles completely by hand, which, doesn't sound practical at all...

The reason I said it doesn't change what the query returns is because the query does not change. There are no additional 32 requests or whatever.

I'm sure the developers understand the specifics of how this works and could do it in a more efficient way but in the most basic sense you get:

1. a choice the user made in the advanced search filter (ex: Gray out: Dropped and Completed)
2. a list of that users dropped and completed mangas that you persist in the client for a short while so you don't request it every time you click next page (I forget the API link for it but it's a json you can already get)
3. a script which will be run in the browser that goes through the same 32 results that you would get if you searched this moment (cause the query does not change in any way) and adds a "greyed-out" class to the "manga-card" div if it matches any of the ones on the list from point #2.
4. a line of css (which again runs only in the browser, not on the server) that just says that whatever manga-card has the class "greyed-out" gets "opacity: 0.1 " which makes it look greyed out, like in the picture in the first example.

This way the all the iteration through the lists in order to pick what becomes greyed out happens on your computer instead of on the server and is absolutely negligible even if you have a list of 1000 dropped mangas cause you're the only one using your computer.

 

[Roler]

The reason I said it doesn't change what the query returns is because the query does not change. There are no additional 32 requests or whatever.

Yes, the search query doesn't change because it only contains public info which can't help in any way with this. I was talking about requests to other endpoints to get the needed information.

2. a list of that users dropped and completed mangas that you persist in the client for a short while so you don't request it every time you click next page (I forget the API link for it but it's a json you can already get)

Hmm, I thought the batch status endpoint needs iteration but it seems to return the whole list... I wonder why they check every manga on tag pages then (maybe more expensive on the API?).

Though, maybe that's why (looking at the sandbox API) that endpoint is going to be removed when CustomLists come out

Haven't checked if there will be an equivalent/workaround endpoint...

 

[MrMichael]

Yes, the search query doesn't change because it only contains public info which can't help in any way with this. I was talking about requests to other endpoints to get the needed information.


Hmm, I thought the batch status endpoint needs iteration but it seems to return the whole list... I wonder why they check every manga on tag pages then (maybe more expensive on the API?).

Though, maybe that's why (looking at the sandbox API) that endpoint is going to be removed when CustomLists come out

Haven't checked if there will be a workaround...

I don't really know about their upcoming changes, only time I touched the API was like 3 years ago where I wanted to store my "reading" list locally in case mangadex went down but I've switched to tracking in MU instead of the json since. I also don't know much about those "tag pages" or how they do stuff.

I also have 0 experience with the database they use ... Elastic...something. I'm making assumptions on how making a request for that list on #2 is a reasonably efficient thing to do and doesn't need much iterating and that assumption could be wrong.

The way I'm assuming things work it should be efficient but I'm open to being completely wrong, the goal of my initial statement was just to say that this suggestion does not have the flaws on the basis of which the different linked suggestion was rejected (overfetching). If I'm wrong feel free to reject the suggestion, it's just a suggestion, I do not own mangadex.

 

[RogueKitsune]

I also have 0 experience with the database they use ... Elastic...something. I'm making assumptions on how making a request for that list on #2 is a reasonably efficient thing to do and doesn't need much iterating and that assumption could be wrong.

The way I'm assuming things work it should be efficient but I'm open to being completely wrong, the goal of my initial statement was just to say that this suggestion does not have the flaws on the basis of which the different linked suggestion was rejected (overfetching). If I'm wrong feel free to reject the suggestion, it's just a suggestion, I do not own mangadex.

Previous thread about this was already linked, but here it is again Option to exclude mangas from my library in advanced search [Rejected] (technical reasons, dev reply)

Give it a read, particularly the posts from Tristan9. Should answer most if not all your questions on why its not done.
The tldr; is "its complicated and MD doesn't have money to throw at the problem"

 

[Roler]

Previous thread about this was already linked, but here it is again Option to exclude mangas from my library in advanced search [Rejected] (technical reasons, dev reply)

Give it a read, particularly the posts from Tristan9. Should answer most if not all your questions on why its not done.
The tldr; is "its complicated and MD doesn't have money to throw at the problem"

What they're asking is currently easily achievable: https://forums.mangadex.org/threads...nical-reasons-dev-reply.1076334/post-16643370

And here is a simple bookmarklet that does something similar (shows the status): https://gist.github.com/rRoler/a41d...db10d#file-mangadex-display_in_library-min-js

But once CustomLists come out this won't work anymore.

 

[RogueKitsune]

I would have to go read through it again to be sure, but I am pretty sure client side filtering was brought up there as well, and all the downsides it has with things the way the are currently. Which is why I linked it...

But yes there are ways to do it today via userscripts and the like.

But once CustomLists come out this won't work anymore.

Will still probably be possible via userscripts just more work

 

[Roler]

I would have to go read through it again to be sure, but I am pretty sure client side filtering was brought up there as well, and all the downsides it has with things the way the are currently. Which is why I linked it...

Yes, but this is about an indicator (which currently doesn't really have downsides), and what Tristan mentioned (in the comment I previously linked) that'll likely be implemented.

But yes there are ways to do it today via userscripts and the like.

Will still probably be possible via userscripts just more work

Yeah, now with CustomLists, it will require more fetching since it will no longer be everything in just one request.
You'll either have to make a request for every manga in the search result or fully fetch all custom lists of a user (since this can become several times larger and contain a lot of unnecessary information, the former may be better, but it could still make 100 requests per search).

Anyway, what I'm trying to say is that with CustomLists this suggestion is less likely to be implemented than it was before.

 

[Velken]

Add bell icon when browsing titles for when you already have them on your feed.
Useful for tracking which manga you already are following when browsing new ones, specially if you follow a bunch that have very long periods between updates.
Example: