datalog: clarify reload behaviour

[jaustin]

I'm breaking out some feedback from #110 to be discussed here.

@microbit-mark suggests some notification that the data table has been reloaded.

However, @microbit-matt-hillsdon and I have also been discussing the possibility that we really just want to alert the user that there is new data and let them reload. We also have to work out how reload interacts with the graph (do we re-render the graph on reload if it was up, or do we refuse to reload if the graph is up, or neither?)

I think my preference now is that we actually just alert the user to new data and let them relaod. I think this needs consistency across online/offline mode so it depends on whether we have the bytes to make this happen (the string alone, to tell a user there is new data and some way to reload the page is likely to break the bank!)

So:

• Is it better to auto-update and tell the user, or to ask them if they want to reload?
• Is it acceptable to have the online/offline mode behave differently? At least with the offline mode there's no graph to worry about
• If not, what's the minimal kind of notification we'd accept on the offline mode to tell the user there's new data: alert with "New data. Reload to update" perhaps?

If I had to call it now, I'd say we go like this

• we do auto reload, and in offline version nothing changes
• in online version, we autoreload and preserve the graph state, and tell the user why we reloaded ("The page was updated with the latest data").

As a reminder, the data will only update when

• you unplug and replug the micro:bit AND the data changes
• you flash the micro:bit with a hex file (which is equivalent to unplugging and replugging) (the data will be empty after this in most circumstances)

[microbit-matt-hillsdon]

I had a quick look at this to understand what we're free to change with online only code changes (that's not to say we couldn't change offline code too in a future codal release).

I've confirmed that "online mode" can intercept the message to reload to provide alternative behaviour.

It doesn’t get given the hash though so without changing that we could implement:

“Data changed on disk [Click to reload]” or “Data changed on disk [Click to reload] [Ignore this and all future changes on disk]”

but not:

"Data changed on disk [Click to reload] [Ignore this change but tell me about future changes]"

Labels intentionally more verbose than we'd probably use in an attempt to be clear!