The existing data annotations present for the game table create model need to be used for server side validation within the GameTableCreateController.ValidateAndCreate method.

The chat is currently sitting within a page, but would be more useful as a component.

The component should have the following structure:

• bottom entry box for messages the user want to post with a send button
• above the entry box a list of historical messages, showing up bottom first and pushing the history up. It should scroll, and each message should have the user identifier next to the message they send

An endpoint to log the user out of the page.

Have to replicate implementation details in the Identity logout.

Seems that when the <Nullable>enable</Nullable> value is used in the project that the controllers start handling input parameters differently. It breaks the site, but also enables omission of [FromBody] in the request signature, might be worth exploring, maybe adjusting how the application handles state transition and navigation with return URLs.

Create a shared component that would be at the top of the page. With an unauthenticated user, present the login/register links. When authenticated, have a user bar that will contextually change content.

Contexts:

• dashboard
• game
• login
• register

Create components that enable a user to auth against the application.

This basically need to replicate implementation details of the Login Identity UI page.

The current implementation details within the controller are not in an ideal location or well structured, should be refactored to something worth while.

The default ico for the site can be replaced by something more representative.

Potential sources:

• iconarchive.com
• icon-icons.com
• findicons.com

just use a search engine why don't you :)

Right now the user needs to press the "send" button to send a message, a hotkey linked to enter should be enabled as well.

When the application server launches, the chat history doesn't show up until the first message gets sent by the user. This is because the initial state of the chat history component is set to empty messages.

The history doesn't show up until another message gets sent to the chat, that sends a signal to all connected clients with the entire history.

Resolution of this should be a loaded history on landing, if a history is available to view ofc.

Use the fluent validations library and add validation to user name.

Shouldn't be empty
Should be between 3 and 16 characters

In the current prototype repository a few things are missing to create an initial commit:

• .gitignore file
• LICENSE file
• README.md file
• build/watch commands for working on the project (backend files already work with this but not the client code)

Add a color picker component that will be used to select a color in addition to a username by a user that lands on the web app. The color will be used to flair up the username (either by coloring the name itself or as a badge next to it, have to decide)

Right now the history of messages stays in the same position after a new messages shows up. This is a problem when the scrollbar is present as users don't see the latest entry in the history view.

The JS ecosystem (if it can even be called that) is a lot to take in. Given the potential performance enhancements that WASM supposedly gives, the opportunity to write client side logic in C# and the chance to learn a new technology, the transition seems like a good idea.

Another motivator is the fact that the current output is almost nothing anyway, so making this decision sooner rather then later is a good idea. The rest of the present notes/tasks should be reevaluated once this is done.

A player should have control of their notes.

A player can have 0 to N notes.

A note can be added, viewed, edited and deleted.

A note can have a title.

A note can have content

The existing data annotations present for the registration submit model need to be used for server side validation within the AccountCreateController.ValidateAndRegister method.

This ticket is pulled out from #46 .

There are a few places now where I need to use the User prop in the controller to find the user data stored for the account. This should be exposed through a shared place.

Currently, every time a new message is posted, the chat component scrolls to the latest message .

We have two context situations where we do not want to scroll

1. when the new message is already in view
2. when the user has manually scrolled away from the bottom of the chat history

For the first situation, the handler for the scroll request should be able to check if the new message is already on the screen, and if so, it should not call the scroll to view method.

For the second situation, when a user scrolls away from the bottom (viewing chat history) the chat scroll shouldn't get activated because maybe they are reading something. when the chat is scrolled to the very bottom, then the autoscroll should be activated. This scenario should also be able to differentiate between first load of the page (we do want to scroll to bottom on initial load), vs user scroll away from the bottom of chat (we don't want to scroll to bottom on new message).

The current display style of the list of game tables is horrible. It should be touched up to look like something presentable.

The chat component is a static element within the application page. We would like to enable the "pop-out" and "pop-in" behavior to it.

When "poped-out", the chat should be removed from the main application window and show up in a separate window (tab) that can be worked with independently. "Popping-in" should have the reverse behavior.

Include relevant Identity libraries and boilerplate to store account data. The IdentityDbContext class provided in the namespace Microsoft.AspNetCore.Identity.EntityFrameworkCore sets up database tables for the data storage. Initial implementation should use SQLite, with maybe a note/task created for the future of this datastore, and how maybe a different backing store might be used in the future depending on needs.

A table can be edited by it's owner. The information that can be edited is the table name and description. The editing can be done in the details view of a given table.

As mentioned in #3, this tasks looks to be non trivial.

Seem a script in the directory root is the way to go. I might be able to use Start-Job or something similar for this task.

Goals:

• one command that runs both dotnet watch run and npm run build (the npm command is also an alias defined in package.json).
• output should be forwarded to the terminal the script is called in
• calling Ctrl + C should stop the watch process

Current chat history becomes sluggish when several dozen messages are present, the redraw might be the issue. Needs more research

A table can be deleted by its owner. The delete button can be found in the table details page, with a confirmation window on the UI to ensure the action isn't a mistake.

A table can have details that can be viewed by navigating to the table details page. Only the owner can see the details of the tables they have created. If a user navigates to a details page of a table that doesn't exist or that they don't own, a redirect will happen back to the dashboard. The details view will hold buttons for editing and deleting a table.

There is a lot of property duplication in models used by the application. this should be consolidated. Also move them to a single unified location.

Each message that appears in chat should have its own component for the presentation.

Messages you send should be somehow distinct from messages sent by others.

when a user lands on the page, they should be prompted to enter a username. The username is used as an identifier that is displayed next to chat messages

The newly added color picker should be wrapped in a dedicated component that can be used instead of using the raw input element.

Right now both register and login handle returnUrls badly/not at all. A robust way should be created to handle return URLs

A user can click on a button on their dashboard (landing page after login) to create a table. They choose a name for the table and an optional description.
All tables created by a used should be shown as a list in the dashboard.

A new database table needs to be created to store table information. Currently a table has an owner, name, description and identifier.

Create a set of components for user registration and the backend to support it.

• Registration form needs to be validated on both back and front
• Users register with emails

This basically needs the logic contained in the register Identity UI element

The chat component should stick to the right hand side of the web app, with distinguishing borders and have a height of a 100%. Width should be set by default to the minimum width of the chat column, that can be set at ~350px for a start.

The chat width can be expanded to the size of up to double the min size (~700px).

Running dotnet build creates an index.js in the same directory where index.ts is. This should be removed since webpack is responsible for generating the static assets.

The registration form is currently raw and isn't styled.

Within this task

• the elements of the registration form should be extracted into a dedicated component
• the new component should be used within the page
• labels should be displayed for all form elements
• styling should be applied to conform to a look (TBD)

Currently, when any user sends a message to the chat, all clients receive a full chat history as a notification and it gets re rendered on the client side.

This should be adjusted to only get the message being sent, and the chat component should hold the history in its own state and building it up from received messages.

Find a resolution to the warning messages showing up with possible null reference exceptions

A shared component should be built that has the default behavior of showing a loading indicator before it gets called back with info that the data is ready. then it switches to the display of its content. A handle should also happen if loading goes wrong, displaying some friendly error message.

display every message as a block with 2 elements one on top of another.

First (top) element should have:

• User identifier on top left
  • if the poster is not you it should be HANDLE :
  • if the poster is you it should be You (HANDLE) :
• timestamp on top right (use timestamp component

Second (bottom) element should contain the actual message

When the response to register isn't successful, ValidationSummary should be used within Register.razor to display the new error state.

This ticket was pulled out from #46 .

The login form is currently raw and isn't styled.

Within this task

• the elements of the login form should be extracted into a dedicated component
• the new component should be used within the page
• labels should be displayed for all form elements
• styling should be applied to conform to a look (TBD)

There is some fat present in the template output for the blazor project (bootstrap, open-iconic). It would be good to identify what the project can do without and remove it from the code base.

Currently the user is identified in the chat with their handle. This can cause problems with users that might use the same handle. A unique identifier should be part of the user data that will be used to get the identity right

Create a component that formats date/time information into a timestamp UI element with quality of life in mind.

The element should display the timestamp as a info label that is more human friendly then full date/time information.

Thinking about x min ago, x hours ago, yesterday etc...

On hover over the element, the full datetime data should be displayed in a human readable format

When the response to login isn't successful, ValidationSummary should be used within Login.razor to display the new error state.

This ticket is pulled out of #47 .

Right now, there is no way to know who is online and who is not.

A component needs to be built that lists out all of the peers currently connected to a session. The component will manifest on the screen as a list of people currently connected to the session.

WebRTC should be used to realize this.