So, the reason for this is that when we post a topic that creates a page, we're refreshing the entire page. (Because there's a lot of things on the page that need to be updated to reflect that it's a real page now, and that's difficult to update.)

However, the precise spot where we're refreshing it is after the widget has been cleaned up, which thus reveals the empty-state briefly. I'll look at what's involved in moving the redirect so it doesn't allow the cleanup...

(Amusingly, the thing that I know would be trivial is allowing the page contents to be replaced with the newly posted section and then doing a refresh.)

Change 710385 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Show a momentary \"loading...\" rather than the empty state after posting

https://gerrit.wikimedia.org/r/710385

This is probably the most-trivial approach: https://youtu.be/aUCPBHUUCfs

The awkward bit is that the teardown does some necessary things -- it cleans up the storage for autosave, most importantly. Could refactor the widget so that this is done elsewhere and separately-callable, of course.

In T288314#7265597, @DLynch wrote:

This is probably the most-trivial approach: https://youtu.be/aUCPBHUUCfs

This looks like an improvement to me. Let's go with it for now.

The awkward bit is that the teardown does some necessary things -- it cleans up the storage for autosave, most importantly. Could refactor the widget so that this is done elsewhere and separately-callable, of course.

I see. Let's consider improvements to what you've implemented above in this newly-created ticket: T288320.

In T288314#7265567, @DLynch wrote:

(Amusingly, the thing that I know would be trivial is allowing the page contents to be replaced with the newly posted section and then doing a refresh.)

Hmm, can we do this? It'd be a little inefficient, but it would look nicer.

Hmm, can we do this? It'd be a little inefficient, but it would look nicer.

I think the only objection would be that there's a chance the user would start interacting with the new contents and then lose that interaction as the page reloads.

Actually, I noticed one more objection, which is that it makes the "you replied" toast appear, disappear, then appear again. (Because it appears for however long it takes the reload to happen, disappears until the page is loaded enough to show it, then times out naturally.)

I've updated the patch to be the more-expansive "don't teardown, but do clean up the reply widget" variant. There's no flash of empty state, though there's a moment of the widget having emptied itself out.

https://youtu.be/qkUsjm12SG8

In T288314#7267303, @DLynch wrote:

I've updated the patch to be the more-expansive "don't teardown, but do clean up the reply widget" variant. There's no flash of empty state, though there's a moment of the widget having emptied itself out.

https://youtu.be/qkUsjm12SG8

@DLynch, of the two approaches you've now shared, this one [i] still seems like the biggest improvement over the experience that's live right now.

Thinking: it's important that people be confident they did the "right thing" to publish what they've drafted. And I think showing an "empty" form, even briefly [ii], could cause people to worry whether the content they wrote was somehow lost and potentially, motivate them to interrupt the publishing process.

i. https://youtu.be/aUCPBHUUCfs

ii. https://www.youtube.com/watch?v=qkUsjm12SG8

Fine, fine, fine, it's now updated to work without even that flicker of the widget changing: https://youtu.be/5r4B_D-VKa8

In T288314#7267366, @DLynch wrote:

Fine, fine, fine, it's now updated to work without even that flicker of the widget changing: https://youtu.be/5r4B_D-VKa8

This looks good to me. Nice.

Resulting question: would it be accurate for me to think the time between someone pressing Add topic and said topic being posted to the page will be significantly faster on production? Also: by implementing what you have here, are we taking on the performance hit Bartosz mentioned in T288314#7267159?

Note: I ask the above thinking, "Huh, it looks a bit slow."

Test wiki created on Patch Demo by PPelberg (WMF) using patch(es) linked to this task:

https://patchdemo.wmflabs.org/wikis/2889ede3b7/w/

would it be accurate for me to think the time between someone pressing Add topic and said topic being posted to the page will be significantly faster on production?

You mean compared to what's shown in the video there? That was taken locally in a docker container on my laptop. I'd generally expect production to be a bit quicker, though it's complicated. (Much more powerful servers, but serving more traffic at once, and with more room for your internet connection between you and the server to be slow. 🤷🏻)

Also: by implementing what you have here, are we taking on the performance hit Bartosz mentioned in T288314#7267159?

Not really. Bartosz was talking about the inefficiency of completely rerendering the page and then redirecting. This approach is still aborting before that initial rerender. It is technically slower than just doing the rerender without a redirect... but that'd leave us in a state with the page-chrome not being correct for an actually-created page.

In T288314#7267379, @DLynch wrote:

would it be accurate for me to think the time between someone pressing Add topic and said topic being posted to the page will be significantly faster on production?

You mean compared to what's shown in the video there?

Yep

That was taken locally in a docker container on my laptop. I'd generally expect production to be a bit quicker, though it's complicated. (Much more powerful servers, but serving more traffic at once, and with more room for your internet connection between you and the server to be slow. 🤷🏻)

Ah, okay. This context is helpful.

Also: by implementing what you have here, are we taking on the performance hit Bartosz mentioned in T288314#7267159?

Not really. Bartosz was talking about the inefficiency of completely rerendering the page and then redirecting. This approach is still aborting before that initial rerender. It is technically slower than just doing the rerender without a redirect... but that'd leave us in a state with the page-chrome not being correct for an actually-created page.

I see. IMO, the latest iteration looks good.

Change 710385 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Don't detach the reply widget when posting to an empty page

https://gerrit.wikimedia.org/r/710385

Test wiki on Patch demo by PPelberg (WMF) using patch(es) linked to this task was deleted:

https://patchdemo.wmflabs.org/wikis/2889ede3b7/w/