I’ve been running into a bunch of instances recently of needing to override existing ruby methods from plugins, and thought I’d share my best practices here.
Overriding an instance method
class ::TopicQuery
module BabbleDefaultResults
def default_results(options={})
super(options).where('archetype <> ?', Archetype.chat)
end
end
prepend BabbleDefaultResults
end
Here I’m removing chat topics from an instance method which is returning a list of topics.
The module name BabbleDefaultResults can be anything you want; I usually make it match the name of the method, plus my plugin name, to minimize any name conflict risks (although they’re already quite low)
Module#prepend is super cool and you should know about it if you’re writing plugins for anything in ruby. Note that it’s the fact that we’re prepending a module which allows us to call super inside the override method.
PS, always call super! This makes your plugin far less likely to break when the underlying implementation changes. Unless you’re really, really sure that your functionality completely replaces everything in the underlying method, you want to call super and modify the results from there, so that changes to this method in Discourse core don’t make your plugin break later.
The :: in ::TopicQuery is ensuring that I’m referring to the top-level TopicQuery class to override, and not some modulized version of it (like Babble::TopicQuery)
This can go straight into plugin.rb as is, or if your plugin is large you can consider separating each override out into a separate file.
Overriding a class method
class ::Topic
module BabbleForDigest
def for_digest(user)
super(user).where('archetype <> ?', Archetype.chat)
end
end
singleton_class.prepend BabbleForDigest
end
Here I’m taking an existing self.for_digest method on the Topic class, and removing chat topics from the result
Very similar to the instance method override, note the difference being that we’re calling singleton_class.prepend instead of just prepend. singleton_class is a mildly weird way of saying ‘I want to append this to the class level, not the instance level’, further reading if you’re looking for a ruby-related rabbit hole.
Overriding a scope
class ::Topic
@@babble_listable_topics = method(:listable_topics).clone
scope :listable_topics, ->(user) {
@@babble_listable_topics.call(user).where('archetype <> ?', Archetype.chat)
}
end
This one’s a little bit tricky because scopes don’t play well with super (or, at least, I couldn’t get them to). So instead, we’re taking an existing method definition, cloning it, storing it, and then calling it later.
Again, @@babble_listable_topics can be anything you’d like, but using your plugin name as a namespacer is probably a good idea.
More on the method function, which is also super cool, although the times when you’d really need it are pretty few and far between. Bonus free fun fact related to that; when debugging, if you’re having trouble figuring out what code is getting run for a particular method call (usually “Which gem is defining this method?”), you can use source_location to get the exact line of source code where the method is defined.
I use basically the same structure, except I tend to seperate out the module and the prepend.
As you pointed out, this pattern is “super” useful when trying to avoid overriding core logic.
module InviteMailerEventExtension
def send_invite(invite)
## stuff
super(invite)
end
end
require_dependency 'invite_mailer'
class ::InviteMailer
prepend InviteMailerEventExtension
end
One small tip here is that when overriding private or protected methods, your overriding method also needs to be private or protected, e.g.
module UserNotificationsEventExtension
protected def send_notification_email(opts)
## stuff
super(opts)
end
end
@angus@gdpelican Спасибо вам за это. Это отличные материалы. . Это было бы действительно необходимо всем разработчикам плагинов (особенно новичкам вроде меня).
Это именно то, о чём мне действительно нужно было знать. Я раньше думал, что если вы переопределяете метод только для внесения нескольких изменений, то, вероятно, стоит скопировать код в свой новый метод и внести туда изменения. Сама мысль об этом звучала как хакерское решение.
Да, действительно. С момента публикации этого поста обновления в использовании Rails в Discourse сделали require_dependency ненужным. Я не могу отредактировать пост, чтобы указать на это. Подробнее см.:
Есть какие-нибудь советы по переопределению классов модулей? Я хочу внести некоторые изменения в GroupGuardian (специальные условия для особого типа группы).
Новичок в разработке Discourse и Rails. Я использую локальную среду Dev Container (в VS Code). Руководства и документация были полезны.
Хотелось бы узнать, есть ли у кого-нибудь советы по переопределению основных классов Discourse, особенно в части обеспечения их сохранения в локальной среде разработки.
В моем плагине я пытаюсь переопределить метод в основном классе Discourse TopicEmbed (используя общий подход, хорошо описанный @angus выше). Это работает один раз после пересборки и перезагрузки VS Code, но при последующих HTTP-запросах мой переопределенный метод никогда не вызывается.
Мое переопределение определено в /plugins/my-plugin/app/models/override.rb, и я использую require_relative для включения этого файла в plugin.rb.
#override.rb:
class ::TopicEmbed
# модуль, который будет добавлен в TopicEmbed.singleton_class
module TopicEmbedOverrideModule
# метод в TopicEmbed
def first_paragraph_from(html)
Rails.logger.info("мой переопределенный метод срабатывает!")
# продолжить с оригинальной реализацией из TopicEmbed
super
end
end
# выполняем prepend здесь
singleton_class.prepend TopicEmbedOverrideModule
end
Подозреваю, что проблема с сохранением может быть связана с моей средой разработки и тем, как компилируется/кэшируется код Ruby.
Также я пробовал rm -rf tmp; bin/ember-cli -u и bundle exec rake tmp:cache:clear.
Я заставил это работать для класса-синглтона следующим образом:
# my overrides.rb
# Модуль, который будет добавлен в начало цепочки TopicEmbed.singleton_class
module TopicEmbedOverrides
# Переопределение метода parse_html
def parse_html(html, url) # примечание: здесь я не использую self.
# мой новый код
# затем вызываем исходную реализацию
super
end
end
# выполняем переопределение здесь
class ::TopicEmbed
singleton_class.prepend TopicEmbedOverrides
end
useful when trying to avoid overriding core logic.
. Это было бы действительно необходимо всем разработчикам плагинов (особенно новичкам вроде меня).