coveralls
commented
1 year ago Pull Request Test Coverage Report for Build 5394465000
Warning: This coverage report may be inaccurate.
This pull request's base commit is no longer the HEAD commit of its target branch. This means it includes changes from outside the original pull request, including, potentially, unrelated coverage changes.
- For more information on this, see Tracking coverage changes with pull request builds.
- To avoid this issue with future PRs, see these Recommended CI Configurations.
- For a quick fix, rebase this PR at GitHub. Your next report should be accurate.
Details
- 0 of 0 changed or added relevant lines in 0 files are covered.
- No unchanged relevant lines lost coverage.
- Overall coverage remained the same at 61.089%
| Totals | |
|---|---|
| Change from base Build 5382225477: | 0.0% |
| Covered Lines: | 15801 |
| Relevant Lines: | 24117 |
Problem
Solution
I added a new very much work-in-progress cursor selector UI element to the bottom of the screen. It shows the current selected cursor and shows event processing progress. Check out the attached GIF for the general idea.
I moved event downloading to the web worker. The UI is only responsible for setting the "playhead" aka selected point where event processing should begin. You'll eventually be able to select playback speed to either "realtime" or some arbitrary millisecond value but for now it's processing events as fast as possible (i.e. next tick).
There's a new file, EventDomain, that handles all event-related state in the worker. It's got a few interesting methods:
setCursor: set the date where event processing should begingetNextEventDelay: get the number of milliseconds to wait before processing the next eventprocessNextEvent: do the thingOnce all the events for the current cursor have been processed, EventDomain increments the cursor by 10 minutes and then carries on. If the cursor is less than 11 minutes in the future,
getNextEventDelayreturns the number of milliseconds to wait until more data can be fetched.The path to the date in each event object is now specified via fake jsonpath. I'm not sold on it but it's the only alternative I could think of to letting each demo set its own "getDate" function (can't serialise a function and i don't want to bake demo-specific stuff into the web worker).
none of the names for any of these things are final, feel free to rename things as you please. naming things is hard.
I also added a mock, dev-only Bluesky API so I could test event processing locally without having to wait for 10K events to go by.
Result
Bluesky demo works now. There are still some bugs, most notably with cursor incrementing when enough time has progressed. I'll be looking into these bugs next.