🎉 Native gdocs tables

[ikesau]

Adds support for tables in our articles via the Gdoc table element.

The template property determines which rows/columns get highlighted in the table. Its possible values are: header-column, header-row, and header-column-row.

This is the Gdoc content for the first table in the preview:

The inline table gets parsed and converted into an Archie representation:

{.table}
template: header-row
[.+rows]
    {.table-row}
        [.+cells]
            [.+table-cell]
                Deadhead
            []
            [.+table-cell]
                Danfan
            []
        []
    {}
    {.table-row}
        [.+cells]
            [.+table-cell]
                rectangular granny glasses
            []
            [.+table-cell]
                steely dan t-shirt
            []
        []
    {}
    {.table-row}
        [.+cells]
            [.+table-cell]
                sense of oneness
            []
            [.+table-cell]
                LA Eyeworks clipons
            []
        []
    {}
    {.table-row}
        [.+cells]
            [.+table-cell]
                beat poetry
            []
            [.+table-cell]
                MacMall catalog
            []
        []
    {}
[]
{}

And this then gets parsed as a regular archie component in our rawToEnriched pipeline.

Known remaining work:

• Fix list parsing
• Design QA with Marwa

[larsyencken]

Hey @ikesau, can you add a test article onto the staging server for this for quicker QA?

[danyx23]

I added the env vars for gdocs to the staging server

http://staging-site-gdocs-table/admin
I'm playing around with this doc (which may at any time be broken :) )
http://staging-site-gdocs-table/admin/gdocs/1ImYJfRy_cXvsRTsI1lYgXmh1vG1mMtvnXWrGuDtrGLw/preview

[danyx23]

The code and structure look good. When using it I found that any kind of archieml component breaks because apparently the properties are not preserved. Arguably we don't want too many kinds of blocks to appear there anyhow but I think the parsing issue should be resolved.

Of the block content types that we do support, I think lists are pretty likely to be legit and probably images as well. Using gdoc bullet points broke the rendering of the page.

I think once these issues are resolved it should be good to ship from my side.

[ikesau]

Lists broke? They shouldn't! I'll do some more testing

Thanks 🙂

[sophiamersmann]

hello! thanks a lot for recording those videos. I had several aha moments watching it - I worked with gdocs a little bit to make narrative charts work, so I had some understanding of it, but you just really helped me to connect those dots :)

btw, I really appreciate how the types flow through the pipeline. I remember that to be incredibly helpful when I looked into narrative charts!

I focused on the low level stuff, and there is not much from my side:

• tables don't seem to take up the full width for me (see screenshot below)
• the scope attribute on th elements should be the other way around, no?

Screenshot:

[sophiamersmann]

I recently learned that, if you have a custom Tag (must be uppercase), you can also just do <Tag /> which surprised me a bit, but it is possible. obvs no need to change, just a little fun fact :)

[ikesau]

Thank you @sophiamersmann

I hadn't pushed up the min-width changes on this remote 🤦

Definitely had the scopes the wrong way around. Need to be more vigilant to stop automation blindness with copilot. 😱

@danyx23 the table issue should be fixed now. Usually paragraphToString takes care of closing tables because there's always a new line before the [.body] closing tag, but that wasn't the case inside the table context, so I needed to add a manual check to ensure it gets closed properly before moving onto the next cell.

i.e. we were effectively getting this:

{.table-row}
[.+cells]
[.+table-cell]

[.list]
* one

* two
[]
[]
{}

(A missing [])

And now we properly get

{.table-row}
[.+cells]
[.+table-cell]

[.list]
* one

* two
[]
[]
[]
{}

[danyx23]