New Report Generator

[okdistribute]

This branch renders reports as PDFs and removes the dependency on react-mapfilter

This is a large PR, I know, but all of the relevant NEW code is quite small, with logic contained within:

• src/renderer/components/MapFilter/ReportView/ReportView.js.

The rest of the changes are just copy-pasted from react-mapfilter#pdf-reports branch.

TODO

• Remove unnecessary console.logs and replace with logger.log
• Get ReactPDF to render in electron-renderer
• Prev/next buttons
• Styling
• Print button
• Codesplit the report view
• Render a mini map in each page
• Render a point on the minimap for each observation

Bugs

• Images are not being lazy-loaded which causes reports to take a long time to load the first time they are generated.
• If you click forward too quickly, the Report view gets 'stuck' and won't advance anymore, you then have to click 'previous' then 'next' again to continue viewing

Cleanup

• CSS issue with prev/next buttons
• Factor out hidden-mapbox into it's own module
• Loading indicator after filter is applied and before pdf has rendered

v2

• Add intro page with a map of all observations and a summary of the observations in report (see prototype given by @jencastrodoesstuff)
• Preview more than 5 pages at a time

[gmaclennan]

Hi @okdistribute I pushed my work on this but there is still work to do. I fixed the issue with React PDF not rendering in electron by switching the Webpack config to bundle all of the modules in node_modules. This will impact the overall app bundle size because the JS bundle static/bundle.js is now 11mb (production build) vs. <1mb, but we are still bundling all the node_modules which are no longer needed. Once we fix that duplication, the app size should be much smaller than before. Working from a bundle should also speed up initial load of the app. On my machine it goes from about 5600ms to 1400ms (production build) and it might be even better on spinning-disk machines.

After fixing the bundling the next issue was errors with React Context. It seems like React PDF was unable to deal with any component that read from context (it throws an error). The main uses for context were the "react-pdf=true" context and also the components from react-intl.

After fixing those I ran into a bug that was unable to render some of the FeaturePage code that was returning an array as a sibling to other View components. I wrapped the array in a <View> and it fixed it.

After that bug I hit a bug of React PDF not being able to render components which return null. I had to stop before fixing that.

I understand it that you were able to render to a PDF with the code when you were running it all on the server? I wonder if all these bugs are in PDFViewer, which is rendering everything to the DOM rather than a PDF for a preview. I don't think we need to use this - electron should be able to show a PDF in an iFrame, so we should be able to render to the PDF blob and show it directly, but I haven't tried that yet. For performance it might be worth only rendering one page of the PDF at a time.

I can continue to look at this next week - I feel like I have got my head into the code now and I can make some progress.

[gmaclennan]

Note: to use the Chrome default PDF viewer in Electron we will have to upgrade to Electron v9 beta (set to be released as stable on May 19th). See electron/electron#12337

[gmaclennan]

Great work on this @okdistribute. As discussed on our check-in today, I think it might make sense to just use the code in https://github.com/gmaclennan/mapbox-gl-local-static-maps/blob/master/index.js for generating map images. mapbox-map-image-stream has a bit of overhead due to the way it does a stream of the map image and mosaics tiles from multiple map instances. It does this in order to handle extra large hi-res maps (there is an upper limit on the map canvas size, and memory use would shoot up otherwise) but it makes the map generation slower. Since for reports we are not going to need map images larger than about 2000px for an A4/Letter report, I think it will be fine to just use map.getCanvas().toBlob(). The getMapImage() function should have all you need.

For caching, another option is to lean on browser caching with a Cache-Control: max-age header. The browser (e.g. the Chrome renderer process where the report is being generated) will take care of caching the map images, so we do not need the file cache module.

The style and access-token are best managed by the renderer process (they are already defined there) and passed as query parameters (I imagine what you have currently is just for testing). For the API HTTP end-point, for the mapbox-gl-local-static-maps lib I used the same API as the Mapbox Static Maps API. It wouldn't be my first choice of API design, but it seems to make sense to use something compatible with a defined API. To parse the URL I statically generate a RegExp based on a path expression and then use parseMapOptions to parse the URL. I'm not wedded to this API, but sharing here in case this code is helpful for you.

I do think it makes most sense to define the API with a center and zoom, rather than a bounding box, because it's easier to generate a bounding box from center,zoom,dimensions than vice-versa.

For showing observations on the map there are a few options:

1. For the maps for each individual observation, the cheating / easy way is to just overlay a marker in the middle of the image (since the map center will be the observation location, and we only need to show a single observation on that map).
2. For the overview map that shows all observations in the report (if we choose to have one, this could be "reports v2"), I see two options:
   1. Encode the overlay / markers into the URL, like the Mapbox Static Maps API does. This means that our static maps server does not need to know anything about observations or the current filter, everything it needs to know is encoded in the URL. I feel good about being able to write this in half a day if you don't have the bandwidth for it.
   2. Pass the current filter encoded in the URL, and then the map server requests the observations and filters them on the server side, then adds them as a layer to the map. The request for a list of all observations from osm-db can be slow though, so I think this might be a perf issue, and more complicated than (i) to implement.

[okdistribute]

We probably need a bounding box for the front page, but zoom/center for each observation seems fine