Allow I18n in render lifecycle

[23tux]

What are you trying to accomplish?

1. Sometimes we call t(".some_key") inside a #render? method. Think of def render? = items.any? and items is a hash of translations
2. To test a components method, I'd like to be able to just do the setup of a component's render lifecycle inside my test. This shortens our test run time, as we don't need to actually render the HTML. And due to the change when the @virtual_path is actually set, I can now test t(..) calls in my helper method, because the teardown hasn't happened yet.

What approach did you choose and why?

• I extracted the setup, actual render, and teardown of the #render_in method into methods.
• I moved the line @view_context.instance_variable_set(:@virtual_path, virtual_path) outside of the @output_buffer.with_buffer do block. I just hope this doesn't break anything else.

Anything you want to highlight for special attention from reviewers?

• I couldn't get the system tests with a real browser to run, but all the other tests are green
• I'm not sure if I can just change the values in assert_allocations

[23tux]

Maybe someone can help with the failing checks, I'm not sure what to do

[boardfish]

@23tux This looks good to me. Those checks are failing on main – I don't think they're blockers to merging this, but because this affects the number of allocations it'd probably be good to make sure those tests pass locally if it's convenient to do so.

[23tux]

@boardfish I added a test helper as well, could you have another look at it? Apart from the integration/system specs that require a browser (as I said, I had some problems with the setup and can't run them), all the tests pass on my machine. I added one commit to make the allocation spec more robust.

And the Lint check also fails, but it doesn't seem to involve my changes.

[joelhawksley]

@23tux thank you for taking the time to make this contribution!

In https://viewcomponent.org/best_practices.html#test-against-rendered-content-not-instance-methods, we say:

ViewComponent tests should use render_inline and assert against the rendered output. While it can be useful to test specific component instance methods directly, it’s more valuable to write assertions against what’s shown to the end user

I stand by that recommendation and thus am hesitant to add any test helpers to enable testing component instance methods. There is a reason https://viewcomponent.org/best_practices.html#most-viewcomponent-instance-methods-can-be-private immediately follows the guidance above!

I am happy to have my mind changed here, but for now I'm going to close this PR in favor of #2511 which cherry-picks your bug fix ❤️