Add https://twbook.cc/ to Novel543Parser

[nitramkh]

Implementation for #2526.

• https://twbook.cc/ is a clone of https://novel543.com/ and thus just hooks into Novel543Parser.

• I added extractSubject to get the genre. It is the same across both sites so I saw no reason not to.

• I JSDOC-ified it while I was there because why not.

As always, if there are any issue or wanted changed, I'm happy to fix ;)

Pull request checklist

1. ✅ Do all existing unit tests pass?
2. ✅ Have all warnings and errors reported by eslint been fixed?
3. ❌ Have you added new behaviour?
   1. ⬜ Can you turn it off?
   2. ⬜ Is it off by default?
4. ✅ Are you in the contributors and credits?
5. ✅ Are you committing to the ExperimentalTabMode branch?
6. ✅ Have you ensured you committed all relevant changes?
7. ✅ Have you rebased your commits?
8. ✅ Did you fetch from upstream before rebasing?

[dteviot]

@nitramkh

I JSDOC-ified it while I was there because why not.

Please don't do that for functions that are just overrides of functions in the base parser.
Only add comments for new functions, where what it does might not be obvious from the name.
e.g. Why does moreChapterTextUrl() exist? (This one could use a comment.)
FYI. https://stackoverflow.blog/2021/12/23/best-practices-for-writing-code-comments/

[nitramkh]

@dteviot

Please don't do that for functions that are just overrides of functions in the base parser.

Fair enough, I'll remove them, and later I can go through and remove them from the other parsers where I've put them; as I assume the same applies there? I just like adding them to get typescript hinting working right as I'm a bit of a dumbass and make little mistakes constantly. Also does this apply to JSDOC @ type annotation for example in the code too?

Regardless, shouldn't be too onerous ;)

[dteviot]

@nitramkh

I'll remove them, and later I can go through and remove them from the other parsers where I've put them; as I assume the same applies there?

I'm OK if you choose not to fix up the older stuff. It's a minor thing.

I just like adding them to get typescript hinting working right as

I'd also like to use typescript. Unfortunately, using it complicates getting WebToEpub approved, due to code being transpiled. Which make the inspection/audit longer and more complcated.

[nitramkh]

@dteviot

I'd also like to use typescript. Unfortunately, using it complicates getting WebToEpub approved, due to code being transpiled. Which make the inspection/audit longer and more complcated.

Sure, but in this case I meant specifically using the JSDOC type annotations to get Typescript type-checking in JavaScript. The support is pretty good at this point, I've been using this the entire time. I have a private branch where I've been exploring the codebase and trying to learn it where I've just been adding type notations as I went; and its quite helpful.

Like for example #2591, which I only noticed because Typescript was screaming due to the missing return.

EDIT: For convenience I figure I can drop the spec link here Typescript JSDOC reference. If it wasn't for this support, I wouldn't have been adding the type annotations either as they are verbose and ugly af, but it's quite helpful.

Also, I wasn't planning on ever making a PR for this as I know I am a comment-aholic and thus that it's unlikely anyone else would want my comment stew. But if you want a demo of what I mean here is the branch I've been playing around in when trying to learn about the codebase, nitramkh:personal/jsdocifying. As a beginner it was much less "scary" using ex. HttpClient having the types, and not having to blindly imitate existing usages and pray or keep the entire thing in memory (which I am completely incabable of anyway ;)).

[dteviot]

@nitramkh

Thanks for your efforts.