Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Server Event Income Handling #2

Open
muratmirgun opened this issue Nov 3, 2023 · 3 comments
Open

Server Event Income Handling #2

muratmirgun opened this issue Nov 3, 2023 · 3 comments
Labels
Accepting PR enhancement New feature or request good first issue Good for newcomers

Comments

@muratmirgun
Copy link
Member

muratmirgun commented Nov 3, 2023

Handle necessary events coming from the server and update the channel according to the event.

  • Currently, the package nothing 😄 (Example Events: EVENT_MESSAGE_INSERT, EVENT_MESSAGE_UPDATE...)

We can discuss from issue about the Events

@muratmirgun muratmirgun added enhancement New feature or request good first issue Good for newcomers Accepting PR labels Nov 3, 2023
@IcedTea2K
Copy link
Contributor

IcedTea2K commented May 12, 2024

Hey Murat 😄 are there any documentations on all the possible event messages? There is a pretty extensive list over the js side (link), but not sure if that's everything or what they all mean.

Edit: nvm, found the documentation on phoenix framework, which is used to build the realtime server.

@IcedTea2K
Copy link
Contributor

Hey @muratmirgun, here are a couple of design decisions that we could make. Currently, realtime-js allows you to create two channels of the same name, using the same real-time client. Should we:

  1. Allow the same. But probably need to document this somewhere because realtime-js is lacking in that aspect
  2. Disallow that by having a check, and throw an error
  3. Don't overwrite the channel. Instead, update the channel to listen to newly specified events. (But then the question arises, do we update the channel at On or at Subscribe?)

Personally, I like second option the most, because it's easiest to implement and it'll probably save developers from having to debug where the heck their events went. Though, I'm not too sure how much we can deviate from realtime-js behaviour.

@muratmirgun
Copy link
Member Author

We can choose the second method for now if somethings goes wrong we can change it later

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Accepting PR enhancement New feature or request good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants