ronnigaba / BoyumFoosballStats-2.0

2 stars 0 forks source link

Implement a 'Session' concept #21

Closed ronnigaba closed 1 year ago

ronnigaba commented 1 year ago

We should allow users to start a Session.

The Session state would be kept on the server so the user can always resume their session, until they decide to close it. This will also allow ut so get around the issue of Blazor Server closing the connection after a while.

The Session would be utilized for various things, such as match balancing, reporting scores for specific sessions etc.

ronnigaba commented 1 year ago

@alexandrutatarciuc Do you have any thoughts on the format for saving the session? I considered saving it as a Match object alongside a list of selected Players [at the table], but I can see that we don't create a Match until we're about to save the results on the score page.

Should we save it in a less specific format or should we have the Score Collection page utilize a Match object from the start?

alexandrutatarciuc commented 1 year ago

@ronnigaba I believe the Match object shouldn't be changed, we need to create a separate Session object. A Session has 0 to many Matches, the list of all players at the table, a start date, and an end date. Optionally, a Session needs to have a ShouldGenerateHighlights field.

ronnigaba commented 1 year ago

image This is more or less what I came up with - I don't think it makes sense to store the scores, as those are only edited when a match is about to be saved. I'm not sure about the ShouldGenerateHighlights field, it might be needed at some point, though the user would then have to toggle it somehow.

alexandrutatarciuc commented 1 year ago

Something like this image

alexandrutatarciuc commented 1 year ago

@ronnigaba I think what you have is similar with what I thought, but I think we can get away with a CurrentMatch instead because it's one property instead of 4 (or even 6 if we see the need to also score the current score). Besides that, I think that a Session should also score its configuration (auto-swap, show inactives, etc.)

ronnigaba commented 1 year ago

Yea, good point about the configuration states. Once those are added, they should definitely be stored to state as well.

I think it makes sense to store the match state as a Match object if we decide to use the match object on the page, prior to saving. Otherwise it seems odd to create a Match object just to store it in the state.

alexandrutatarciuc commented 1 year ago

I think this feature will also come with some UI changes. Overall, I think this would enable us to add more features in the future and create a better UX, yet I think other stuff is more important right now.