Path Helpers Failing when email is sent before call (CCI)

[benlieb]

I have a feature spec that calls

visit company.decorate.h.new_company_path

This works as expected on my local machine but fails in Circle CI with:

NoMethodError:
undefined method `new_company_path' for #<#<Class:0x00007f0ce1116710>:0x00007f0ce5926f28>
Did you mean?  new_company_url

Is there a reason this would fail in Circle CI but not locally? This is the only spec out of about 150 that is failing, so I'm not inclined to think it's a general configuration issue.

For full context here is the whole spec. Is it because there isn't a view context yet, with nothing yet rendered? If so why does this work locally but not on CCI?

  describe 'Contact Details Panel' do
    specify 'errors show where they belong when the data is bad' do
      company = create :company
      visit company.decorate.h.new_company_path

      find('.sticky-entity-header .btn', text: /save/i).click
      expect_async_user_message("couldn't be saved", :danger)
      expect(find('.help-block.warning-for-company-name').text).to include("can't be blank")
    end
  end

[graaff]

Does that feature send out an email before this failure? We are seeing a similar issue and this seems to happen because an email is sent out first. This causes the view context to switch to the Mailer, but it does not appear to switch back to the controller. This means that the view context is now used on a controller context, leading to this error (because Mailers only have fully qualified URLs).

[prognostikos]

@graaff we are also seeing an error when when using Draper after ActionMailer where Draper can no longer find methods defined in helpers. Did you end up with any fix or work-around?

[prognostikos]

For anyone else running into this a workaround is to include the missing helper(s) in your ApplicationMailer so they're available to Draper, etc. even after ActionMailer switches the view context.

[taylorthurlow]

This is still an issue. I found a cleaner solution that affects only tests:

RSpec.configure do |config|
  config.before do
    Draper::ViewContext.clear!
  end
end

It's not really clear to me if this problem is sort of a natural consequence of how Draper is caching the view context, or if its actually just a bug/shortcoming that can be fixed.

[Alexander-Senko]

@taylorthurlow, thank you for your findings and the fix.

I’ve dug a bit deeper into the code and found Draper having that piece of logic already:

draper/lib/draper/test_case.rb

Lines 6 to 9 in 4173a0f

	def before_setup
	Draper::ViewContext.clear!
	super
	end

It seems not to be running in this case for some reason, though. The first thing I’d assume may be the order before hooks are running in — maybe, this one is running too late? 🤔

Anyway, we need a deeper investigation to fix that properly.

Meanwhile, anyone can easily incorporate the fix into their rails_helper.rb until it’s fixed upstream.

[Alexander-Senko]

Anyway, we need a deeper investigation to fix that properly.

Unfortunately, it’s quite unlikely that I’ll do it on my own.

At first, I was eager to develop Draper and bring it back to life, but I don’t see it viable for now. The reasons are:

1. Me and @y-yagi, being the only active maintainers for now, don’t have access to RubyGems.org to publish new releases. That’s why the last one was published as a Git branch.

2. I consider refactoring Draper a better way than fixing a ton of bugs here and their, caused by it’s architecture. The new version would unlikely be fully backwards compatible and would require a major release.

3. Every PR requires a code review. It’s OK for the small ones, but we need more active maintainers to review and discuss that big ones.

That’s why I came to rewriting Draper from scratch on my own and splitting it into several libs:

0. SimpleDelegator from the standard library is the base.
1. Magic Lookup for the generic class inference.
2. Magic Decorator for generic decorators.
3. Magic Presenter for Rails presenters / view models.

They do virtually all the Draper does and more.