yurickh / pointz Goto Github PK

Even though the user is removed, the activeTicket doesn't seem to be removed in that case, which creates a zombie room.

The problem

Currently, a user status is defined by a combination of booleans (namely alive and done), and local status (showResults, creating).

Suggested solution

We could probably define a state machine for a single enum field in the user instance that would move between waiting, creating, voting, results, so we could make the UI code more declarative and hold less variables in our heads, keeping the routing logic inside the room component.

The problem

When joining a pre-existing room, users will see the 404 page since the client is still fetching for the room data.

Suggested solution

We can improve the loading state for the Room page by adding this case, and only show 404 after fetching is completed.

We want to make a simple readme on how to run the environment in development

The problem

Once a ticket is created, further edits are not allowed until voting is done. Users should be able to add more info to the ticket name.
Optionally, users could create a nameless ticket and add a description while voting is going.

The problem

Currently, when a user refreshes the page while the room is in a voting state, all other users will see the total number of users jumping around to account for the removal and the addition of the user in the room.

Suggested solution

We could debounce the total number of users so it has a couple sends leeway.

I have an idea for your voting app. We’re very commonly having to come up with topics to discuss and then vote on the topics during the meeting. How about having an app that allows you to have a round topic submission and then have round of topic voting.

Or remove them when calculating the room id.
The main problem is that this messes up the URL when we inject the room name there.