Shakapacker helper being stateful might cause issues in some edge cases

[tomdracz]

This is a fun one we've hit when upgrading our internal project to Shakapacker.

We use fair bit of turnip-like specs throughout, some are rendering the views. We've noticed that once upgrading to Shakapacker some of those specs started failing due to double render error:

You can only call append_javascript_pack_tag before javascript_pack_tag helper

Took a while to reproduce it but see below:
tomdracz/shakapacker-css-test@c71783f

It includes one view specs with two examples, each doing a render and then a turnip feature using steps that are also doing a two renders. In the Turnip feature, one scenario is defined that does single render (it passes), another does two renders.

Now the latter is seemingly a perfect combination that causes chaos. rspec-rails ViewExampleGroup provides a render method but it looks like that gives us back same ActionView::Base instance within example so Shakapacker state remains between two steps - first one sets javascript_pack_tag_loaded to true, the second tries to do render again but fails to do so, because it thinks it already rendered.

The solution we've rolled out was monkey-patched helper:

module Shakapacker::Helper
  def reset_shakapacker_internal_state
    @javascript_pack_tag_loaded = nil
    @stylesheet_pack_tag_loaded = nil
    @javascript_pack_tag_queue = nil
    @stylesheet_pack_tag_queue = nil
  end
end

And in the specs we can call view.reset_shakapacker_internal_state between steps to clear out the state.

Frankly this is fair bit of an edge case (doesn't seem to affect normal view specs, not usual rendering) and I cannot think of a way to get safe rendering without removing state from the helper but do we think it's worth adding some "escape hatch" methods to the helper similar to the above somewhere?

[G-Rath]

@tomdracz fyi your link is 404ing

[tomdracz]

@tomdracz fyi your link is 404ing

Good spot, amended repo visibility