App.js: poll for new calls

[masenf]

autoloadDelay

A new setting is added which controls how frequently to poll for new calls. By default, autoloadDelay is 0 (disabled) and can be turned on via the Settings panel.

getData

• Update getData to take fromTime as a parameter
• After fetching files, append them to the current calls. This is fine because a side-effect calls setCalls([]) when the serverIP or sinceTime changes. For live updates, the fromTime is limited to the time of the latest call in calls
• setLastUpdated with the most recently found call and the current time (to re-trigger the side Effect)

"poll" side Effect

When lastUpdated changes, queue a callback to fetch new calls after autoloadDelay sec. The side effect will clear the pending callback when it gets rescheduled, so only one outstanding callback should be pending at any given time.

When checking for updates, pass the timestamp of the most recent call for fromTime to only fetch unseen calls.

"play new calls" side Effect

When playNext doesn't have a nextCall to play, it calls setCallWaiting(true) which triggers this side effect to call playNext when new filteredCalls are available.

scrolling touchup

Set filteredCallsRefs null array at render time (rather than inside useEffect). This change allows other side effects to control the scroll visibility of calls in the list.

Adds a scrollIntoView function to simplify scrolling to the selected item (or offset of selected item)

Adds an onClick handler to the NowPlaying component container div which scrolls to the currently selected call. This makes it easy to see where you are in the list when it's been playing in the background for example.

fixes #8

[masenf]

One of the problems I just discovered when hide listened is selected is that autoplay jumps to the top of the filteredCalls list because after marking listened the previous selectedCall now has index -1, so the next call is index 0.

I think the fix for that would be to replace callWaiting state with something that stores the nextCall. If there is a next call, then it would get played on playNext, otherwise if it was some sentinel value, then the polling Effect could restart playing when new calls are available.

[masenf]

One of the problems I just discovered...

that was a bug that existed in master already, so i filed #17 and a fix in #18

thankfully i won't need to add more state variables and will simplify this a bit more now that i understand the audio tag autoplay attribute.

[masenf]

Marking this as ready for review. All of the issues that I was aware of are resolved.

Going to test it out with my deployment for a few days: http://sdrock.0x26.net:8080/. I have that connected to a RTL-SDR listening live (mostly), so it should get some updates, especially if you listen to 147.260.

[slavik0329]

@masenf Looks good so far. Will run some tests and then merge. Very nice!