Dynamically updated Structure Sheets while creating tournament

[ctm]

Make it so that when people are creating a tournament, if they click the circle-i they get a tentative structure sheet.

Currently, when people are creating a tournament, the circle-i takes them to a template for the structure they currently have selected. Instead, we can bring them to something like /structure/new and then send information from the parent window to the child window. That information would be the choices currently selected, then as choices are changed, we could update the child window.

This is easily done, but we need to implement structure sheets (#1439), first. It's not a high priority both because the functionality isn't really that important and because we still have about a month of the WSOP-Style series left and in round numbers, nobody will be creating tournaments during it.

[ctm]

I'm doing a "before mom gets up" spike to see if I can set up the communication pathway from parent window to child window. I'm doing this now because I deployed structure sheets for upcoming and running events already, but haven't yet adjusted how level durations are dealt with, and I think they can be done a little more cleanly in templates if we don't use templates directly during tournament creation. Here's what I'll explore this morning:

• [x] Parent
  • [x] Capture the circle-i click
  • [x] Save the WindowProxy that is returned by open_with_url_and_target_and_features
  • [x] Create an Enum for messages from parent to window
  • [x] Demo creation (DemoParams)
  • [x] Event creation (NewEvent)
  • [x] Have Create::capture_values send the appropriate message if a Window has been saved
  • [x] Remove the WindowProxy when its closed property is set
• [x] Child
  • [x] New route
  • [x] Add Listener for "message"
    • [x] Deserialize

Turns out, it took me a while just to write up this list, because I've been browsing MDN. postMessage has some intricacies I'm still exploring.

[ctm]

Since web_sys::Window::post_message_with_transfer uses JsValue for both the message and the transfer parameters, there's no option to use postcard into an ArrayBuffer. Considering the small size of the payload in the infrequency of transfer, this restriction actually makes things easier because it means I shouldn't (honestly!) spend any time looking into serializing via postcard. We'll just use JsValueSerdeExt.

[ctm]

Turns it was better to use serde-wasm-bindgen than JsValueSerdeExt, but I do have the pathway working. So now the child window gets the initial state of the create dialog and gets a new state any time the state is changed. The remaining steps are:

• [x] Create a HashMap<StructureId, Structure>
• [x] Make the appropriate API call to populate it as needed
• [x] Combine the contents of the data field with the appropriate Structure into an EventEventAndOwner
  • [x] Using all the info we currently have
  • [x] DemoParams (see NickMapper::demo)
  • [x] NewEvent (see NickMapper::process_pen_user_request on the CreateEvent match arm: i.e., line 769)
  • [x] Figure out why updating time to act doesn't refresh
  • [x] Passing in the creator's nick when known
  • [x] Updating creation time at minute (i.e., what's displayed) granularity
  • [x] Have update create and store the EventAndOwner
  • [x] Have view use the stored EventAndOwner
  • [x] Make an UpdateCreatedAt Msg variant and have it update the created_at field
  • [x] Add and call a set_created_at_timeout that sends an UpdateCreatedAt appropriately
  • [x] Test
    • [x] with second granularity
    • [x] with minute granularity
• [x] Call call the event's html method

[ctm]

This was supposed to just be a little bit of exploration yesterday morning, but mom's schedule went kittywampus yesterday and I chose to work on this issue in between events in her day. Now I'm close to results and I have "an hour" "to spare", so I'll push on and try to get it deployed today or tomorrow, not because it's important, but just to finish it and get it out of the way.

[ctm]

Done. Deploying now.

Decided to not test with second granularity because it'll only take a minute to test with minute granularity and it'll take more than a minute to set up the test with second granularity. OTOH, each time the minute granularity test fails, I have to poke around, make changes and/or add instrumentation and then test again, and then wait up to a minute to see my results. In the grand scheme of things, that extra minute doesn't mean much, but it'd be frustrating, however the minute granularity test worked on the first try. I love Rust.