Open jtauber opened 7 years ago
Even if the text service component isn't a widget I can see us having a widget for each text service component that just gives info about the text service used for current passage.
I am going to provide a bit more context in more technical detail for anyone outside of myself and @jtauber. This may help aide in coming up with a way to implement this feature.
The Reader
component is serving two purposes at the moment. One is the text service and the other is providing a layout of widgets to support the text service. The work done on the unify-passage branch helped separate the rendering of the passage retrieved from the text service.
I'd like to see the parts which handling interaction with the text service moved out of the Reader
and into something that can conform to a particular interface for that service, but also with hints of a generic interface (the Passage
component is starting to design that interface).
we haven't really worked out how text service components work (whether they are a completely different kind of pluggable component to widgets) but I wanted to make a note about creating a text service component for handling non-chunked files that are either local or just served up as-is via HTTP.
e.g. I have a MorphGNT word-per-line file on disk for an entire book; or I have a TEI XML file for an entire work.
There's no reason we couldn't have a component that loads this into the store and does the chunking client side.