Богдан

Есть общепринятый способ для расширения функциональности контроллеров и моделей - это concern
elegantbrew.tumblr.com/post/70990048275/controller...

Может это вам поможет rusrails.ru/action-mailer-basics ?

Вообще я считаю что в контроллере должен быть только вызов "контейнера" (где происходят какие то вычисления, получения данных из базы, например trailblazer, dry решают эту проблему) и рендеринг полученного, т.е. буквально 3-4 строчки кода.

Вот пример из traiblazer:

class Song::Create < Trailblazer::Operation
  step    Model( Song, :new )
  step    :assign_current_user!
  step    Contract::Build( constant: MyContract )
  step    Contract::Validate()
  failure :log_error!
  step    Contract::Persist()

  def log_error!(options)
    # ..
  end

  def assign_current_user!(options)
    options["model"].created_by =
      options["current_user"]
  end
end
####
result = Song::Create.({ title: "The Feeling Is Alright" }, "current_user": current_user)
result.success? #=> true

app/controllers/concerns, lib/

https://codepen.io/wokster/pen/MVaEgQ
Если коротко - inline-block не растянется на высоту ячейки. Надо делать block.

А есть ли смысл указывать для дочернего объекта конструктор прототипа, я так понимаю это только ссылка на функцию, и если его необязательно использовать?

У каждого конструктора есть прототип. По умолчанию это Object.prototype.
Если Вам нужен прототип, указывайте. Если не нужен, но и не за чем. Очевидно же.
Только одна поправка: прототип это объект, который (как и прочие объекты) состоит из полей, среди которых есть функции.

Как лучше всего добавлять в прототип свои свойства

Я не знаю. ИМХО, для прикладных задач лучше делать так, чтоб читало проще.

Как лучше добавлять свои методы, вариант только так, или есть более элегантное решение, например создать объект со своими методами и склеить его с прототипом?

Без разницы, но нужно учитывать один момент.
Пусть мы определили конструктор Son и ему задали Son.prototype тем или иным образом. Для простоты положим, что прототип состоит только из функций. Затем создали несколько экземпляров (new Son).
Далее, предположим, мы хотим добавить в прототип новый метод или изменить существующий.
Здесь необходимо решить, будем ли (1) мы менять прототип уже созданных экземпляров или же (2) у созданных экземпляров оставим их старый прототип, а у создаваемых будет уже новый.

P.S. наконец, в последних редакциях появились новые синтаксические конструкции. О них тоже забывать не нужно.

Проблема в том, что в методах прототипа Date идет проверка на то, что передан экземпляр даты. Причем проверка идет не по цепочке прототипов.
Старый исходный код V8:

function DateGetTime() {
  CHECK_DATE(this);
  return UTC_DATE_VALUE(this);
}

Кто-то писал, что CHECK_DATE имеет следующую реализацию:

CHECK_DATE(arg) = (%_ClassOf(arg) === 'Date' ? %_ValueOf(arg) : ThrowDateTypeError());

Тем не менее, сейчас все это переписано на C++.

Если посмотреть спецификацию, то видно, что методы прототипа вызывают нативные функции, выполняющие все расчеты и тут важно, чтобы им предавали валидный объект даты. Поэтому, видимо, и идет строгая проверка.

Вариант решения этой проблемы, изменить цепочку прототипов экземпляра:

function SpaceDate(...args) {
  var date;
  date = new Date(...args);
  date.__proto__ = SpaceDate.prototype;
  return date;
}

SpaceDate.prototype.__proto__ = Date.prototype;

SpaceDate.prototype.test = function() {
  return this;
};

Возвращаться будет объект Date, а цепочка прототипов будет с вашими методами. На прототип оригинального объекта Date это никак не повлияет.

Ну вообще это скрипт добавляет https://c2n.me/3S6y0ar
Можно посмотреть в браузере через инструменты разработчика.
Ваш пример с подключенными скриптами - https://jsfiddle.net/kreoTech/qewrdcn7/1/