You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository was archived by the owner on Nov 16, 2021. It is now read-only.
Currently the imperative Preact API (useImperativeHandle) is available to PreactBaseElement bridge (see ampproject/amphtml#30046). For instance, this is how PreactBaseElement subclasses implement on-actions.
However, this APIs also need to be exported in Bento mode so that developers can call these APIs on a DOM AMP element instance. E.g. a developer needs to be able to call:
Currently it's possible using CustomElement.enqueueAction API. However, this method has always been meant as an internal API and thus has serious issues with ergonomics.
In general the solution can be fairly straightforward simply proxying the Preact component's API on an element. However, some key nuances to be solved here are:
APIs may need to be either namespaced or somehow we need to ensure non-collision with DOM APIs. E.g. we can either ensure that element.pause() is always ok, or we can call it element.ampPause() (poor ergonomics), or element.api.pause() or similar. The naming is subject to bikeshed of course.
The Preact component's API is not available until the following sequence is executed: (a) AMP element is stubbed, (b) BaseElement is upgraded, (c) Preact component is rendered and its API is exported. This is quite a race condition and we need to think through how best to guide the developer API to avoid problems. For instance, element.api.pause() might work well because we can use element.api === undefined as an indication that the component/API are not ready yet.
Related to upgrade race conditions, the enqueueAction implements action queueing. This is probably not a useful feature in Bento mode, but should be analyzed.
We need to be careful with the fact that Preact component's imperative API handle can easily change given the Preact APIs. This means that we probably can't simply export the imperative handle directly, and should instead proxy it.
Not yet clear if an element's API would map 1-to-1 to component's API. Proxying helps since it provides a layer to transform.
Currently the imperative Preact API (
useImperativeHandle) is available toPreactBaseElementbridge (see ampproject/amphtml#30046). For instance, this is howPreactBaseElementsubclasses implementon-actions.However, this APIs also need to be exported in Bento mode so that developers can call these APIs on a DOM AMP element instance. E.g. a developer needs to be able to call:
Currently it's possible using
CustomElement.enqueueActionAPI. However, this method has always been meant as an internal API and thus has serious issues with ergonomics.In general the solution can be fairly straightforward simply proxying the Preact component's API on an element. However, some key nuances to be solved here are:
element.pause()is always ok, or we can call itelement.ampPause()(poor ergonomics), orelement.api.pause()or similar. The naming is subject to bikeshed of course.element.api.pause()might work well because we can useelement.api === undefinedas an indication that the component/API are not ready yet.enqueueActionimplements action queueing. This is probably not a useful feature in Bento mode, but should be analyzed.