feat(Quick Tags): Natively update posts after editing

[marcustyphoon]

Description

Quick Tags edits posts on the Tumblr servers, but this does not cause the rendered posts on the page to update with the new information. We add a fake tags element to the edited post to simulate this.

This, instead, hooks into the Tumblr front end to cause the post to be rerendered with the up-to-date information. The newly added util fetches the post from the server and calls an internal function used to do this when the user edits a post.

For simplicity and/or out of laziness, I delete the blog object out of the fetched post. I assume we're not going to be making edits to a post that would affect its blog (how would that work?), and this avoids having to test if specific blog info URL parameters are required on the API request so nothing explodes.

There is a longer delay than there used to be between submitting a tag edit and having the confirmation appear because we're waiting for two API requests with this. Maybe we should add an in-progress state somehow? Any ideas?

Testing steps

Confirm that adding a tag to a post using Quick Tags causes the tag to appear in the footer of the post, but does not affect the post in any other way:

• on a regular dashboard page (I did channel, presumably e.g. following would be fine)
• in the blog view
• when a single post is viewed in the blog view
• in a community
• when a single post is viewed in a community
• in drafts
• in queue

[marcustyphoon]

Uhhhhhh why the heck does a fetched community post have headerContext: { label: { type: 'text', text: 'Private community post' }, icon: 'lock' }? It—oh, that actually is how an individual community post gets displayed.

Meh. I guess either I have to make the util have a whitelist of keys it's supposed to update, or just assume the change went through as we thought and supply it the change. I guess the former is better; if Tumblr's servers transform our changes, we want to reflect that.

[marcustyphoon]

Uhhhhhh why the heck does a fetched community post have headerContext: { label: { type: 'text', text: 'Private community post' }, icon: 'lock' }? It—oh, that actually is how an individual community post gets displayed.

Oh, that's fun: this affects redpop itself; if you edit a community post in the community timeline it temporarily gains the above-header thingy. I guess I'll report that.

[AprilSylph]

There is a longer delay than there used to be between submitting a tag edit and having the confirmation appear because we're waiting for two API requests with this. Maybe we should add an in-progress state somehow? Any ideas?

I think it's fine. It's weird when you're used to the previous behaviour, but ignoring that it's not that bad.