after_save callback

[alexandred]

I had the need for an after_save callback so I have added it in akin to how before_save works.

[ryanstout]

@alexandred what do you need after_save for?

[alexandred]

@ryanstout I needed to run a task that parses a chat message for certain commands and then fetch some relevant data from APIs.

[ryanstout]

@alexandred can you give me more details? What do you do with the API data?

[alexandred]

@ryanstout Okay so in the after_save callback, I run a regex match to see if a user has entered a command to query Wolfram Alpha. If so then I pass the message ID to the task. The task then collects all the match groups and runs a query to Wolfram Alpha for each match. Wolfram returns images (representing the query response) which I then use to replace the command in the chat message body.

My reasoning behind this method is to make use of Volt's reactive updating to automatically update the message once the Wolfram query results have resolved.

[ryanstout]

@alexandred So I would say that an after_save callback is probably the wrong place for that. You probably want to create another class that handles the interaction of both and use that (from a task or on the client depending on what the use case is) I hadn't planned to add after_save into volt. I've found in rails it was on my top 3 things that causes chaos list (imho): http://samuelmullen.com/2013/05/the-problem-with-rails-callbacks/ <- I tend to agree with that article that callbacks should only be used to modify the model state before saving or during validation. If your working with an API or modifying another something, I would argue that it doesn't belong in the model.

Also, in your example, updating a model in an after_save I would think would cause another save (which would trigger another after_save) At least thats my expectation.

A common pattern I use in volt is to trigger tasks from the client like this:

model.save!.then do
  WelcomeTasks.send_email
end

^ for example. Another thing I've been considering for use cases like this is to make it so you can create some sort of Proxy model (really a reactive service object) that behaves like a model (you can save to it and get reactive updaters on the client), but it is able to store to multiple models under the hood. (Something I feel like I'm going to need)

Thoughts?

[jfahrer]

@ryanstout The idea with a reactive service object sounds very interesting. I also try to avoid the use of callbacks in rails if possible. If I use them, I only do so to manipulate the state of an object before saving. Everything else goes in custom classes.

[ryanstout]

@jfahrer yea, I think the interesting thing would be to be able to use them on the client where you would a normal model. The reactivity is pretty easy, its just the syncing that would need a bit of thinking.

[alexandred]

@ryanstout Thanks for the detailed response. I can see now why an after_save callback might be a bad idea. Sticking that logic in the client after a buffer save seems like the best bet.

I like the idea of a reactive service object, will be interesting to see it implemented in Volt.

I'll close this PR considering what we have discussed.