We want to get a chapter of RCUV. Have a look at https://github.com/cheukyin699/pc-auto/blob/master/docs/architecture.md#save-data to see how to store the chapter.

Problems that need to be solved:

• (Automatically) remove HTML formatting from RCUV string
• Format RCUV string such that each array item corresponds to a verse
• If we want Mark 14:66-15:5, it will Just Work :tm:
  • Requires sequential GET requests because a single GET request only gets a single chapter

When I drag a part of a song right beside the song in the timeline, it should automatically group itself to save space.

Similarly, I should be able to easily rearrange (via drag-reorder) the parts within a group, even going so far as to dragging the part up and out of the group (un-grouping) and to some other part of the timeline.

Below is a RFC for templates.

Behaviour

A template is a series of sequential parts that the user can select. You can only select a template at the start of your editing session, when there are no parts in the editor. Selecting a template will copy all the selected parts into your timeline.

Implementation

A template is a Part[]. We can store templates within public/templates/, and index them on build. We can also have all templates in a single file and export them.

The future

We want users to be able to create their own templates, localized to their own browsers. Thus, the site must take templates from both the site itself and from wherever the user stores them.

Our app supports getting cached song information, in the event that our Cantohymn site API stops working.

This script should take 1 argument, which is the song name (path slug), and write to a file in the directory /public/data/songs/ the song JSON data.

This entire directory will later be indexed whenever the site gets built.

Use case

$ npm run songs:download "神大愛"
Saved song "神大愛" by "鄧淑儀 Yvonne" as public/data/songs/神大愛-bb40d.json

Flow

1. Create the URL (e.g. https://cantonhymn.net/song/%E7%A5%9E%E5%A4%A7%E6%84%9B/)
2. Get data using API (i.e. GET https://cantonhymn.net/api/song-detail.php?slug=神大愛&songHierarchyType=parent)
3. Parse the data and marshall it into our JSON format
4. Store the data in the directory with a unique file name

Gotchas

• Because the way we marshall things is the exact same way we marshall things on the site, code can be reused (it just hasn't been written yet)
• The same can be said about the API, which as of writing, does not have a neat wrapper function around it
• As of the time of writing, no structure for the JSON file exists, which means it has to be designed

Testing

• The script itself does not need testing; it merely integrates a bunch of existing functions together
• The song string to JSON object function requires testing. A lot of testing to cover weird edge cases

Related to #3 and #2 and probably also #1

We want to store cached song information in a file. The question is: what would that file's format be like?

As stated in documentation, a user should be able to configure their presentation with options that override each other.

For example, a global font size can be overwritten by a song's default font size, which can be overwritten by a part's default font size.

Presentation options should be stored in the config key. This is true for the options at all levels.

For this ticket to be considered done, only the ability to change font sizes is required. You must display the options and allow the user to change it.

Create a download button that:

• When clicked, downloads a presentation file that has the slides displayed in the timeline
• Downloaded presentation file should be properly configured (#8) according to the available options
• For MVP, only global options should be considered

Our app supports getting cached song information in the event that our Cantohymn site API stops working.

This script takes no arguments.

Use case

$ npm run songs:reindex
Found 254 songs in public/data/songs/
Written to index file public/song-index.json

Flow

1. Do glob on directory public/data/songs/*.json
2. Open each glob-ed file and read into memory
3. Store all metadata into public/song-index.json or some other suitable format

Gotchas

• Due to the number of possible songs, it is possible that storing the index itself as a list of key-value objects is too memory-intensive and would potentially balloon the index's file size; thus other options can be explored such as CSV (Colon-separated values), CSV (Comma-separated values), or other CSVs (Character-separated values)
• As of the time of writing, there is no structure for the song JSON files or the index file, thus implying it must be designed

Testing

• The one-time-use nature of this script requires no functions; just shove everything into a file and call it a day