architecture question

[gotson]

Hello,

i would like to ask some questions about the general architecture and direction of this project. This was briefly discussed in #639.

managed-HTML vs callbacks/events

So far what i can see from this project and how to interact with the reader, is that there is a mix of:

• HTML elements that are being manipulated directly by the reader, which i will subsequently refer to as managed-HTML
• some callbacks or event listeners that are called, so that some work can be done outside the reader, implemented by the user of the library

It seems to me however that the first point, the managed-HTML elements, is more prominent, and that the callbacks/events are second class citizen (as discussed in #639).

The HTML part is also quite invading IMHO, as mentioned in #641. To give another example, some of the managed-HTML elements are found using class selectors, like here. This should really be using IDs instead of classes.

❓ What i hinted at in #639 is whether you would be open to clearly decouple the reader from the expected HTML elements, and provide the same functionality in both the managed HTML, and the callbacks/events ? I would be happy to send some PRs about it.

I use the reader in a VueJS/Vuetify application, which handles its own visual elements. As such, managed-HTML doesn't fit the style of my application. And since the visual elements are generated by the Vuetify framework, they also do not conform to what the reader expects in terms of managed-HTML.

That is why i am looking at relying more on callbacks.

Callbacks vs event listeners

I don't quite understand why callbacks and event listeners seem to be doing the same job?

For example ReaderConfig.api.resourceAtEnd seems to be doing the same thing as reader.addEventListener("resource.end", ...);.

❓ That may be historical, but would you be able to clarify why this is duplicated ?

❓ And subsequently, if new behaviours were to be added, should those new behaviours be added as API callback, or as event listeners ? or both ?

My personal take is that API is more explicit, as it is expressed by TypeScript types, while event listeners are not defined anywhere, and thus rely on documentation.

[aferditamuriqi]

Callback vs event listeners are not a duplicate really, callbacks have been used from the start and will continue to be used, in the latest versions i started adding additional listeners for implementations that are more comfortable using listeners, listeners are not fully yet implemented for every callback, as it was a start in that direction. and both will stay and be updated as the library evolves.

just to make sure you have an understanding, the r2d2bc library serves not only one use case. every implementer has the options to use and configure what they want, and are not forced to use it all. and this will stay like that.

the only html or css that might be still left over from an original legacy code from over 5 years ago might be the info and the error. but other than that the library can be used fully with your own html and css. as been done in many implementations.

i would suggest, you join the slack workspace and ask questions. and i am sure there will be an answer to what you might think is not working or to restricting. just because you see the sample in a certain way that doesn't mean you have to use it or do it the exact same way. :)

[gotson]

Callback vs event listeners are not a duplicate really, callbacks have been used from the start and will continue to be used, in the latest versions i started adding additional listeners for implementations that are more comfortable using listeners, listeners are not fully yet implemented for every callback, as it was a start in that direction. and both will stay and be updated as the library evolves.

Thanks for the insights.

just to make sure you have an understanding, the r2d2bc library serves not only one use case. every implementer has the options to use and configure what they want, and are not forced to use it all. and this will stay like that.

This is what i understood, but it is not always clear how to achieve this.

i would suggest, you join the slack workspace

The link on the README is inactive:

[aferditamuriqi]

@gotson also it would be great you introduce yourself, so i can address you properly, and know a bit more about you and your project, i've asked in earlier issues you reported, if you can share an example implementation of your vue project, but maybe you missed that question.

[gotson]

I am the developer of Komga, a self-hosted media center for Comics/Mangas/Bds, and soon epubs. I am also the initiator behind The Anansi Project, which lead us to become closer to Hadrien Gardeur and the OPDS2 / WebPub initiatives.