Implement support for the amp-bind premutate message

[josh313]

• Implements the amp-bind premutate message (I2I at Intent to Implement: Premutate amp-bind state #12811)
• Update Viewer.receiveMessage to support sending responses to messages from the viewer

Closes #12811

@choumx

[dreamofabear]

Does this mean that a given eventType can only have one handler? Not sure that's desirable or safe -- let's retain the current behavior if possible.

How about adding an optional parameter to Observable#fire such that it returns Promise.all(<invoked_handlers>) if provided?

[josh313]

I don't think that would work because then the promise would return an array, and that's not what we want to send in the response. I updated this code now to keep the onMessage method as is, and add a separate onMessageRespond method that makes the provided function the sole handler that responds to the message. So any given message type can have one responder, but multiple other observers.

[dreamofabear]

@return {!Promise}

[josh313]

Done

[dreamofabear]

Nit: This can fit on the previous line.

[dreamofabear]

"Calls setState(s), where s is data.state with non-overridable keys removed."

[josh313]

Done

[dreamofabear]

/cc @honeybadgerdontcare Validator change FYI.

[honeybadgerdontcare]

validation changes look good

[dreamofabear]

Oh, are you planning to return error info from premutate_? I assume this will be in the next PR?

[dreamofabear]

Are you planning to use awaitResponse?

[josh313]

No, I didn't end up using it. I removed eventType and awaitResponse from the function signature for the handlers now.

[josh313]

@choumx I'm not planning on returning error info (I assume you mean non-overridable keys?) from premutate_. I thought we decided in the design review not to do that, and to just log them here instead. If we decide to do it, I can do it in a follow up PR.

[dreamofabear]

Just asking because I wondered why Promise.all(observableHandlers) didn't suffice. It implies that you need the return value of one of the handlers instead of just waiting for the promise. Or am I missing something?

[josh313]

I guess you're right that would have possibly worked in this case, although I think it probably would have returned an an array with just one undefined item in it, which isn't good. And this solution seems cleaner since there is a clear way to define what does go in the response and which handlers do the responding.

[josh313]

Obviously, feel free to merge if you think it's ready. I'm not able to.

[dreamofabear]

Thanks for contributing this!