search

edelvalle / reactor

Phoenix LiveView but for Django
635 stars 26 forks source link

Error when connecting to the WebSocket #3

Closed adamghill closed 5 years ago

adamghill commented 5 years ago

When loading up the sample increment/decrement code, the WebSocket seemed to never connect. This was the error I was seeing in error logs:

File "/Users/.../Library/Caches/pypoetry/virtualenvs/django-reactor-py3.7/lib/python3.7/site-packages/reactor/channels.py", line 44, in connect
    self.scope['channel_name'] = self.channel_name
  'ReactorConsumer' object has no attribute 'channel_name'
edelvalle commented 5 years ago

Hi, thanks!

Take a look at #5, try to run it locally and tell me if it works. Or tell me how to reproduce it.

adamghill commented 5 years ago

Your #5 works fine for me, so I'm not sure what I was missing when setting everything up on my own. :( I'm going to close this and open up a new issue with a test/steps to reproduce if I find a problem. Thanks for looking into this!

adamghill commented 5 years ago

Just following up after playing with this library again. This issue was because I hadn't created the CHANNEL_LAYERS setting correctly. So, definitely not your fault, but maybe this will be useful if someone runs into the same error in the future.

edelvalle commented 5 years ago

True! What do you think?

I have another question not related to this topic:

Each call in a component is transactional. So every time there is a send from the front-end, whatever is executed in the backend is inside a transaction. Should I keep it like that? or is better to disable it and let the developer decide?

Just tell me your opinion... because I feel split between: not all calls should be inside a transaction but, is safer if they are by default.

adamghill commented 5 years ago

I think doing both might be best. I’ll throw in a PR for the channels install.

Do you have any instances where the calls shouldn’t be in a transaction? It seems like having that as the default makes the most sense. You could add a kwarg or another function for non-transactional calls if it’s needed in the future?

edelvalle commented 5 years ago

You have a call that does not touches the DB. like opening a modal for example... so you have:

def receive_open_modal(self, **kwargs):
    self.is_modal_open = True

Is just a call to change the state of the UI and does not have to be atomic.

adamghill commented 5 years ago

Oh, of course. Sorry. Thinking about this more clearly after some coffee, it seems like the default should be no transaction. The client can always create that transaction if they need it.

edelvalle commented 5 years ago

Well.. that's is already in this release :smile: https://github.com/edelvalle/reactor/releases/tag/0.3.0b0