Dashboard base

[cohlexyz]

Adds a basic Dashboard under localhost:1350/dashboard:

• [x] Switch to saving data on the server
• [x] Maybe add option to start polls

[y-a-t-s]

The premium chats are now stored in a Vec in ChatServer. As for loading from that vector, I would say that job is perfectly suited for the template renderer.

[cohlexyz]

So the /dashboard endpoint would render the stored super chats? My initial idea was to just fetch the data as json from the server and then let the dashboard populate the list. That way new super chats can be added by just listening for them via a websocket. If the server renders the super chats it would also have to deliver new ones somehow, unless we just don't care about live updates.

[y-a-t-s]

My idea is iteratively rendering whatever is in the superchat vector at the time of page load, and then you can handle any new messages like normal. The messages still get passed through the sockets the same way. I would rather avoid creating new request types to the server if we can leverage the renderer instead.

[jaw-sh]

Displaying multiple views based on server URL endpoints and not relying on JavaScript collection is the correct answer. The polls can run as JavaScript, that works effectively as a little trick, but the whole point of wanting to collect superchats is so that no matter what specific view messes up, they remain accessible.

[cohlexyz]

My idea is iteratively rendering whatever is in the superchat vector at the time of page load, and then you can handle any new messages like normal.

We can do that, but then wouldn't both the server and the javascript for the dashboard need a way to render a donation?

Displaying multiple views based on server URL endpoints and not relying on JavaScript collection is the correct answer. The polls can run as JavaScript, that works effectively as a little trick, but the whole point of wanting to collect superchats is so that no matter what specific view messes up, they remain accessible.

I guess just rendering the collected super chats on the server for now would work then? So you just need to open/refresh the dashboard at the end of a stream, since having new donations show up live through a websocket isn't that important.

[y-a-t-s]

wouldn't both the server and the javascript for the dashboard need a way to render a donation?

I may be misunderstanding the question, but the main overlay page is already set up to have new messages (whose HTML is rendered from templates/message.html) appended using JS reading from a socket. You can use that rendered HTML by putting an EventListener on the socket. Regardless of whether it's the renderer or JS that loads this HTML onto the page, they're just two different methods—with varying levels of difficulty, depending on timing—for loading the exact same thing.

The Message objects are all the same, regardless of any monetary value. They get serialized to a JSON string along with their rendered HTML and sent down the socket, after which they used to just get freed. Now they get kept in a vector instead of being freed if the amount value in the Message is > 0.0.

[cohlexyz]

wouldn't both the server and the javascript for the dashboard need a way to render a donation?

I may be misunderstanding the question, but the main overlay page is already set up to have new messages (whose HTML is rendered from templates/message.html) appended using JS reading from a socket. You can use that rendered HTML by putting an EventListener on the socket. Regardless of whether it's the renderer or JS that loads this HTML onto the page, they're just two different methods—with varying levels of difficulty, depending on timing—for loading the exact same thing.

The Message objects are all the same, regardless of any monetary value. They get serialized to a JSON string along with their rendered HTML and sent down the socket, after which they used to just get freed. Now they get kept in a vector instead of being freed if the amount value in the Message is > 0.0.

Yeah, you're right. I didn't use the rendered html that gets sent for my tests, because I'm retarded and wanted to create the html for the messages myself. So I guess this is approach would make the most sense:

• Render dashboard on the server with all super chats that are saved in the vector up to that point using the message template
• Any new super chats that are sent through the websocket are just appended using the rendered html which the server sends for each message.

I'll try to work on this tomorrow.

[y-a-t-s]

Yeah, the JsonWrapper is a neat little trick, but it's not immediately apparent what the final JSON object looks like. The div in templates/message.html is set up in a way where it can be easily themed with CSS. You could always use DOM manipulation for really nuclear changes.

That approach looks good. Usually, the more the server can directly handle when rendering a page, the better.

[cohlexyz]

I think this should now work mostly. I usually do not use rust, so I'm not sure what I did is the correct way. The server has the super-chats in a vector, but from what I can tell there's no way to directly access that data when rendering the template, so I added a message that retrieves the data from the server.

This is what it looks like now:

I didn't add polls or re-submission of a super-chat to keep it simple. The delete button could also probably go as it doesn't really make any sense anymore.

[y-a-t-s]

The server messaging is good. I made a small change to directly use Askama for initial page creation.

[cohlexyz]

I've removed the delete button and cleaned the CSS up a bit. This is what it looks like now

I think this is good enough for a first iteration (except for the readability of the links, but that's a different issue). I've made sure that unlike with the chat overlay, long messages do not get cropped.

[y-a-t-s]

@jaw-sh Are we good to merge? I am putting off committing some small fixes to keep from making extra merging work for others. This is an important feature and it would be good to get it in upstream.