JS: Phoenix Channel to accept params as a promise

[ivan.y...@gmail.com]

I would like to propose an extension of Channel API to be able to accept params payload as a Promise. Our use case for it: an implementation of AbsintheSocket with async token manager, that checks token expiration and retrieves the new token without trying to hit the socket and then handle 401 (which is I assume classic approach). It seems to be relatively easy to do inside of Push (it would push on resolution of promise here): https://github.com/phoenixframework/phoenix/blob/ae2fb6bddd64fc7e3908ee6dd632f608254f532e/assets/js/phoenix/push.js#L37

[Chris McCord]

If you search the issue tracker, you can see previous discussions and solutions for this kind of thing. Since this can be accomplished easily without introducing a promise vs non-promise interface, I'd prefer to keep it as is. Thanks!

On May 20, 2022, at 3:11 PM, ivan.y...@gmail.com <ivan.y...@gmail.com> wrote:

I would like to propose an extension of Channel API to be able to accept params payload as a Promise. Our use case for it: an implementation of AbsintheSocket with async token manager, that checks token expiration and retrieves the new token without trying to hit the socket and then handle 401 (which is I assume classic approach). It seems to be relatively easy to do inside of Push (it would push on resolution of promise here): https://github.com/phoenixframework/phoenix/blob/ae2fb6bddd64fc7e3908ee6dd632f608254f532e/assets/js/phoenix/push.js#L37

--
You received this message because you are subscribed to the Google Groups "phoenix-core" group.
To unsubscribe from this group and stop receiving emails from it, send an email to phoenix-core...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/phoenix-core/50bda5eb-3196-4e79-af27-c6419fb073d5n%40googlegroups.com.

[ivan.y...@gmail.com]

Are you referring to this? https://github.com/phoenixframework/phoenix/issues/3515#issuecomment-628192821
This is not exactly what we're looking for. First off, we don't authenticate the socket (due to requirement not to expose a token in url), instead we authenticate the channel in join push.
Second, doing what you suggested would mean to reimplement large parts of AbintheSocket, while channel supporting promises would make it a plug in replacement.

Third, I'm not sure I understand why `value vs closure` is ok, but `promise vs non-promise` is suddenly a no-no, I pondered this would be a very small (<10 LoC) and clean extension of API.

But if it's a position Phoenix core team, so be it, we'll think about patching this locally or reimplementing the abstraction completely.