Print export progress, button disabling and slight Component refactor

[sweco-sedalh]

• Show a loading spinner while exporting to PDF (fixes Print - Indicate progress when exporting pdf #1359)
• Disable print export buttons while the map is updating (prevents accidental incomplete exports due to pending tiles)
• Refactor the base Component to make use of ES6 class syntax as well as introduce a convenience html tagged template literal for use in render() methods

The third point is introduced in a way so that it does not affect its interface. If wanted it can be extracted into a separate PR.

[Grammostola]

Disable print export buttons while the map is updating (prevents accidental incomplete exports due to pending tiles)

This makes sense as can't think of a scenario where a partially loaded map should be printed. What does everyone else think, is it clear enough to disable the buttons? It's often noticable that tiles are loading / the preview is working, though maybe not super obvious for the OSM map / if the paper size is large and the tiles are happening off-screen. It doesn't take much to make the mental connection though.

Show a loading spinner while exporting to PDF

The issue specifies pdf and this PR solves pdf yet it seems reasonable to do the same for Save image.
I quite like the visual effect, it clearly indicates what is happening.

[sweco-sedalh]

@Grammostola Good point, I've added the loading indicator to PNG export as well now.

[steff-o]

#1515 Also introduces a spinner utility. It was previously only used internally in infowindow when exporting selection. It is however used inline, not as a global DOM-object. Also that one is an oldschool animated gif so they doesn't look the same. Not sure which is the best approach to have a global spinner or an inline. Maybe there is a place for both, but code wise it should be implemented in the same utility module so it is easier to find when developing and use the same look. In terms of technology, I prefer a css-spinner over gif, but I was lazy and didn't change the old one.

Btw, there already is (at least) one hidden class: o-hidden.

[sweco-sedalh]

#1515 Also introduces a spinner utility. It was previously only used internally in infowindow when exporting selection. It is however used inline, not as a global DOM-object. Also that one is an oldschool animated gif so they doesn't look the same. Not sure which is the best approach to have a global spinner or an inline. Maybe there is a place for both, but code wise it should be implemented in the same utility module so it is easier to find when developing and use the same look. In terms of technology, I prefer a css-spinner over gif, but I was lazy and didn't change the old one.

Having the same spinner would make sense, if nothing else then for consistency across the UI. Global vs. local usually depends on how much of the UI should be locked down; while printing we can't allow the user to click on anything since it might interfere with the process.

I can adjust the usage of the gif-spinner to also use the same CSS, do you want me to do so as part of this PR?

Btw, there already is (at least) one hidden class: o-hidden.

I saw that one, but it was scoped to .o-map, and the global spinner had to be placed outside of it so .o-hidden could not be used in this case.

[steff-o]

@sweco-sedalh Totally agree that global vs inline depends on if the user can do something else in the meantime but also the visual impact and timeframe, so probably there is a place for both. Just wanted to raise the question as I haven't seen this one in action (just had a look at the code). As #1515 is not yet merged I think it's easier to just leave it for now as they would not really benefit from each another anyway.

Didn't realise the spinner was outside the o-map scope, but still I think it quickly becomes confusing when having several different classes doing the same thing. But on the other hand: I don't know anything about css design.

[jokd]

LGTM