Testing implementation of wagtailcharts

[csebianlander]

This is a draft PR designed to test the wagtailcharts package as a potential replacement or supplement to our Simple Charts module.

Right now, the rendering template is not working, because of reasons presumably beyond my understanding or expertise, but you can add, edit, and save the block properly in the page editor (I've only added it to the Browse page type for now just for testing purposes).

[csebianlander]

You'll need to run pip install wagtailcharts on your local environment before testing.

[chosak]

@csebianlander I think I got this working thanks to some helpful JS tips from @anselmbradford. Ans, if you have a minute, can you take a glance at my JS and see if it seems reasonable?

I'm able to get working charts on a BrowsePage (for example http://localhost:8000/admin/pages/12070/edit/) with a configuration like this:

This generates a chart like this:

You'll need to yarn build to properly build the frontend script for this.

[csebianlander]

I've made a lot of notes and have a lot of thoughts about this. The most prevalent is that it's a wonderful improvement from a back-end usability perspective.

We can add our CFPB-specific palette using the ChartBlock(colors=COLORS) argument described in the wagtailcharts docs, but my attempt to implement this led to some weird artifacts, so I'd love it someone who knows better what they're doing could make this change and add this set of colors:

    COLORS = (
        ('#20aa3f', 'Green'),
        ('#0072ce', 'Pacific'),
        ('#5a5d61', 'Gray'),
        ('#257675', 'Teal'),
        ('#254b87', 'Navy'),
        ('#b4267a', 'Purple'),
    )

Some things I wonder if we can integrate simply into this test:

• Additional/custom fields
• SimpleCharts-based styling, to implement our fonts and color styles.
• Style/function overrides, either in the editor or (probably more practically) within the wagtail template? The more we can manipulate the charts.js API in our testing, the more easily we can convey to the wagtailcharts folks what we've found in terms of potential fixes and implementations for field options.

[chosak]

This change allows us to preserve the order of JS script loads for a block, for example given a block like

class MyBlockWithJS(blocks.StructBlock):
    class Media:
        js = ["b.js", "a.js"]

Our template will currently sort these and generate tags like

<script src="/static/js/routes/on-demand/a.js"></script>
<script src="/static/js/routes/on-demand/b.js"></script>

This causes problems if something in a.js relies on something in b.js being loaded first, as is the case with wagtailcharts.

I suppose in theory this change might break some alphabetized dependency we didn't know we needed, but I think it's better to be explicit with ordering.

[contolini]

The only place I thought this might cause an issue is with our video player loading youtube's iframe API but the loading order doesn't matter because all the youtube script does is load a second script that explicitly has an async attribute.

So this change looks a-okay. 👍

[chosak]

This is just a placeholder approach and there's definitely a better way to do this. After #7303 we assume either that a path is its own URL if it contains https:// or lives in js/routes/on-demand/ if not. The wagtailcharts block type needs to load its own JS file that is being served out of the static root, so neither of these work. Per @anselmbradford's comment on #7303 (comment), maybe this is sufficient motivation to adopt paths as objects?