We should have a viewpoint of when to use django signals and when to not

[fgregg]

these powerful features are causing a bit of headache for @smcalilly and @xmedr in CCFP. we have to use them, and are using them well enough in Councilmatic land.

let's maybe create some guidance for this.

[smcalilly]

• when to use them?
  • when you need to hook into a model that you don't control (see councilmatic -- couldn't stuff custom code into their save methods)
  • signals to add/remove a many-to-many field (see workplace app @antidipyramid)
  • fallback for when you can't use the model.save method
• when to not use them?
  • when you can encapsulate the logic in a custom save method
  • when you control all of the relevant models
  • batch operations / update doesn't trigger a signal

percolation in elasticsearch signal. is there a better way to do this without signals?

best practices:

• observability, should we keep them in a signals.py file? it's not always obvious from the model when the signal exists there, and the model is the first place you'll look when debugging model stuff.
• if you're using signals, it should be documented in the readme.

there are different POVs, but we still need some guidance.