A number of users have run into issues where the default subscription signals aren't fired properly when they connect them to their app. I've also run into a number of signals-related issues on projects that I've worked on, and they are often confusing to debug. They also make writing unit tests difficult, because you need to be careful about disabling and enabling signals.
I'd like to move away from signals and towards an alternative that is a little easier to use. Django Lifecycle seems like it's potentially a good fit for this use case.
This would likely require a new API for connecting default signals. I'm leaning towards having a model mixin that users can add to their Django models which will set up created, updated, and deleted subscription triggers. A potential API could look something like this:
# models.py
from graphene_subscriptions import SubscriptionModel
class SomeModel(SubscriptionModel):
# ...
It would also be useful for users to be able to control which Channel Layer group names a subscription will send updates over. This could be accomplished by letting users override methods on SubscriptionModel, something like the following:
from graphene_subscriptions import SubscriptionModel
class SomeModel(SubscriptionModel):
# ...
def updated_group_name(self):
return f"someModelUpdated:{self.id}"
A number of users have run into issues where the default subscription signals aren't fired properly when they connect them to their app. I've also run into a number of signals-related issues on projects that I've worked on, and they are often confusing to debug. They also make writing unit tests difficult, because you need to be careful about disabling and enabling signals.
I'd like to move away from signals and towards an alternative that is a little easier to use. Django Lifecycle seems like it's potentially a good fit for this use case.
This would likely require a new API for connecting default signals. I'm leaning towards having a model mixin that users can add to their Django models which will set up created, updated, and deleted subscription triggers. A potential API could look something like this:
It would also be useful for users to be able to control which Channel Layer group names a subscription will send updates over. This could be accomplished by letting users override methods on
SubscriptionModel, something like the following: