Publish the full list of scriptures and signs

[justincy]

Related to #27, this will help people see which scriptures have already been analyzed. This is necessary for identifying scriptures which haven't been analyzed and for knowing where the analysis can be reviewed for accuracy. The purpose of publishing the full list on the website is to avoid sending people to GitHub because that can be confusing for people who are not programmers.

[justincy]

A simple way to do this, at the start, would be to dump the signs.gv file into a <pre> tag.

How could we do better?

[justincy]

When parsing signs.gv, we could build a JSON object with the data, write it to a file, and use Hugo's data templates to render it on a page.

Two possible data formats:

1. Build a list of ['scripture', 'first sign', 'second sign']
2. Build a list of {scripture:'scripture',signs:[['first sign','second sign'],...]}

Rendering ideas:

1. A table with columns Scripture, First Sign, Second Sign
2. A list with the scriptures as headings and the signs as content.

I prefer the table because then you can scan it quickly, but it might be odd to have the scripture repeated when multiple signs are annotated with the same scripture. If that's a concern, we could avoid repeating a scripture and leave it blank in successive rows.

[justincy]

I think the list should be published at /signs/references

[justincy]

I created a section page for references that iterates over a data file and builds a table.

The next step is to create the references.json file during the graph build. We're already parsing the graph file and processing it. We can't use the final graph to generate the file we want because the scripture refs won't be in order.

Two possible options:

• Find a way to hook into the current graph processing to gather the data
• Create a new method that reloads and parses the graph file

If we chose the second option, we'd want to pull the graph file parsing out of utils.loadGraph() into a parseGraph method which loadGraph will call as well as the new method. And yet, pulling the parsing out of loadGraph is probably a good idea regardless of which option we choose.

What will the API of parseGraph() be?

It could be an emitter:

parseGraph('graph.gv')
    .on('ref', () => { })
    .on('signs', () => { })

It could just return one giant list of data:

[
    {type: 'ref', ref: 'D&C 88'},
    {type: 'signs', signs: ['a', 'b', 'c']}
]

But then, that seems silly to not group refs and signs as all methods will likely need to do:

[
    {
        reference: 'D&C 88',
        signs: ['a', 'b', 'c']
    }
]

I guess we could start with that.

[justincy]

Except the last data example is not correct. It should be a list of a list of signs:

[
    {
        reference: 'D&C 88',
        signs: [
            ['a', 'b'],
            ['b', 'c']
        ]
    }
]

[justincy]

I wrote parseGraph. Now I just need to use it in the build to generate the references.json data file.

[justincy]

I'm generating references.json now and iterating over it to build the table.

One issue I need to investigate is that my local version of the simplified graph looks different than the deployed version. I need to compare the simplified.gv files I'm generating on the master branch vs the refs-list branch to see if the branch is changing the data.

[justincy]

I fixed the parsing bug which led to the graph looking different.

Last thing to figure out is where to link to the list. Perhaps in the graph footer where the scripture refs are shown.