Detailed display #22
Detailed display #22
Conversation
… displayed at the bottom. It also works if no recording is scheduled in the next 24 hours. Not tested for the 'capturing' case. Need to parse the yml file to get the agent id and the username/password
…if less than one hour is remaining
|
This fixes #21 |
There was a problem hiding this comment.
Mostly nitpicks. But parsing JSON using regular expressions is… interesting 🙈
However, If I have a planned event (here it's starting in ~17 min) and start an ad-hoc recording before that, the display shows that the event ends when the next scheduled event ends. That's not correct. I'ts certainly a special case. Maybe we should just show nothing if there is a non-scheduled recording?
assets/index.js
Outdated
| @@ -41,7 +47,53 @@ function updateTimer() { | |||
| } | |||
| return response.json() | |||
| }).then(capturing => { | |||
| console.debug('capturing', capturing) | |||
| console.log('capturing', capturing); | |||
There was a problem hiding this comment.
Why remove the debug logging and turn this into a global log? I'ts often suggested to not use console.log at all.
assets/index.js
Outdated
| if(is_active != capturing && !capturing){ | ||
| updateCalendar() | ||
| } | ||
| is_active = capturing; |
There was a problem hiding this comment.
Not sure why we do this additional update? We do an update every minute anyway, don't we?
assets/index.js
Outdated
|
|
||
| now = Date.now(); | ||
| if (calendar.length > 0){ | ||
| t = is_active ? calendar[0].End : calendar[0].Start; |
There was a problem hiding this comment.
You don't use t anywhere else, so make it a local variable or constant (since it's never being modified). Also, t isn't the greatest name for a variable ;-P
Maybe something like
| t = is_active ? calendar[0].End : calendar[0].Start; | |
| const event_time = is_active ? calendar[0].End : calendar[0].Start; |
assets/index.js
Outdated
| console.debug('Calendar is empty'); | ||
|
|
There was a problem hiding this comment.
You could probably already return here.
main.go
Outdated
| Title string | ||
| Start int | ||
| End int |
There was a problem hiding this comment.
We use lowercase for the other JSON endpoints. Maybe we should do that here as well?
main.go
Outdated
| r.GET("/calendar", func(c *gin.Context) { | ||
| client := &http.Client{} | ||
| // Cutoff is set to 24 hours from now | ||
| cutoff := time.Now().UnixMilli() + int64(86400000) |
There was a problem hiding this comment.
Do we actually need the explicit conversion to an int64 here?
There was a problem hiding this comment.
Nope, we actually don't :D
main.go
Outdated
| s := string([]byte(bodyText)) | ||
| start := regexp.MustCompile(`"startDate":[\d]+`) | ||
| end := regexp.MustCompile(`"endDate":[\d]+`) | ||
| t := regexp.MustCompile(`"event.title":"[^"]+"`) | ||
|
|
||
| startDates := start.FindAllString(s, -1) | ||
| endDates := end.FindAllString(s, -1) | ||
| titles := t.FindAllString(s, -1) |
There was a problem hiding this comment.
Why do we use regular expressions to extract data from the JSON and not just parse the JSON?
There was a problem hiding this comment.
because the JSON contains some characters that aren't parsed correctly and that caused errors
| right: 0; | ||
| padding: 3vw; | ||
| font-size: 3vw; | ||
| } |
There was a problem hiding this comment.
I'm really not sure, but I'm wondering if this would look better with a light font. Maybe something like
| } | |
| font-weight: 400; | |
| } |
There was a problem hiding this comment.
Lighter font looks good, but 400 looks too thin. Using 500 for the info field.
assets/style.css
Outdated
| align-items: center; | ||
| position: absolute; | ||
| top: 0; | ||
| bottom: 75; |
There was a problem hiding this comment.
I don't think you want this element to be positioned 75 (unit is missing) from the bottom of the container. That's what CSS bottom does. You probably just want to remove this.
| bottom: 75; |
|
I think this can be merged @lkiesow your review was addressed by the last two commits, right? |
Created an additional field to display the remaining time until the start of the next event if idle or the time until the end of the current recording if capturing.
An additional page for the backend was created which contains all planned events for the next 24 hours from the time of the request. The information for each event is the title, the start time (in ms) and the end time (also in ms).