palkan / abstract_notifier Goto Github PK
View Code? Open in Web Editor NEWActionMailer-like interface for any type of notifications
License: MIT License
ActionMailer-like interface for any type of notifications
License: MIT License
For the sake of easiness and reduce verbosity in mailers it's possible to set locale of current user like:
before_action do
if params
@user = params[:user]
end
end
around_action do
I18n.with_locale(@user.locale, &block)
end
I found there are no around wrappers in abstract notifier code.
Would be nice to have similar ability to wrap some code around notification call, similar to the actionmailer.
Currently it's only possible to wrap public_send
which calls notifications like so:
def initialize(notification_name, user:, **params)
@user = user
super
end
def public_send(*)
I18n.with_locale(@user.locale) do
super
end
end
Lets discuss and I'm able to provide a solution.
Would you be open to having an option (somewhere, not sure where) that would disable creating the default notifier
line for ActiveDelivery
? Looking at these lines here:
# Only automatically register line when we can resolve the class
# easily.
if "".respond_to?(:safe_constantize)
ActiveDelivery::Base.register_line :notifier, Notifier, resolver: Notifier::DEFAULT_RESOLVER
end
I'm using name other than notifier
and it would be nice to be able to disable the default so I don't have an extra line registering that I don't need. Happy to do a pull request if you have insight on how you wan options handled. Thanks for releasing these gems!
When testing a method that calls 2 different notification methods which sends exactly same message, the expect
with have_enqueued_notification
fails, saying that it wasn't enqueued not even once:
expected to enqueue notification: {:body=>"Here we go again"} exactly once, but haven't enqueued anything
I didn't test similar cases, like enqueue twice w/ same method, but at least the problem exists for this specific case.
When using this gem on projects with ruby 2.7 , there a few deprecation warnings that will break on ruby 3.0 (related to how ruby 3.0 handles keyword arguments).
Release a major version that drops support for ruby <= 2.6 (because this version already hit EOL) that fixes those warnings
I've considered forking the project and fixing the deprecation warnings locally
I am currently working on fix those warnings. I hope to open a PR soon. Let me know if there's something else I can do here.
I have the same issue with testing like described here:
You must pass an argument rather than a block to use the provided matcher (have not delivered to MyDelivery), or the matcher must implement `supports_block_expectations?
when spring is running.
So adding require "abstract_notifier/testing/rspec"
makes a trick! Let's add notice to the docs:
NOTE: test mode activated automatically if RAILS_ENV
or RACK_ENV
env variable is equal to "test". Otherwise add require "abstract_notifier/testing/rspec"
to your spec_helper.rb
/ rails_helper.rb manually
. This is also required if you're using Spring in test environment (e.g. with help of spring-commands-rspec).
Let me know if I could send PR or you will do it on yours end.
Thanks, for the great gem and all your open source works!
Am using ActiveDelivery
in combination with AbstractNotifier
. Thanks so much for both contributions. I have a few custom abstract notifier lines setup as well as a mailer line (default). Great results!
I have a question/issue with error handling and job queueing.
What I am observing is that when an error is raised inside the AbstractNotifier
it halts the execution of all the other delivery lines during the process of the delivery (even when using #notify
to enqueue the jobs). Whereas if an error is raised inside of an ActiveMailer
line the error does not stop the delivery lines from being enqueued (and instead the error actually gets raised when the enqueued job runs).
Simple example:
class FooBarDelivery < ApplicationDelivery; end
class FooBarNotifier < AbstractNotifier::Base
def foo
raise "This will halt the operating of `FooBarDelivery.notify(:foo)`"
end
end
class FooBarMailer < ApplicationMailer
def foo
raise "This will *not* halt the operation of `FooBarDelviery.notify(foo)`"
end
end
# => FooBarDelivery.with(foo: :bar).notify(:foo)
So the raised error in the abstract notifier halts everything; the raised error in ApplicationMailer does not. This is tripping me up in particular with nested job queues because I had one abstract notifier line that would error but all the other lines were being retried resulting in a lot of "spam" (as the one line never was getting delivered).
I would have expected them all to behave like ActiveMailer — they aren't actually executed until after the job is queued.
I wonder if I have my driver setup wrong or is this just how it happens to be?
Thanks!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.