Add ruby_render Liquid tag

[fpsvogel]

This is a 🙋 feature or enhancement.

Summary

Adds a Liquid tag ruby_render that renders a Ruby expression or a simple Ruby component. "Simple" meaning without content in a block:

{% ruby_render MyComponent.new(title: "My Title") %}

Context

Resolves #976

Manual test

I created a new site with bridgetown new test_site -t liquid, then created two Ruby components:

• one copied from bridgetown-core/test/source/src/_components/ruby_component.rb
• the other a component with an ERB template

Then I rendered these two components plus a Ruby expression (to show that's possible too) at the top of the blog post:

{% ruby_render RubyComponent.new %}
{% ruby_render TemplatedComponent.new(name: "Felipe") %}
{% ruby_render "A Ruby string with the random number #{rand(100)}" %}

Added section on website "Ruby Components" page

Adapted from the section on liquid_render

[fpsvogel]

Adding this becausepage is a Bridgetown::Drops::ResourceDrop, not the full resource that is needed to create a RubyTemplateView in the new tag below.

There's also context["resource"], but it too is a Bridgetown::Drops::ResourceDrop.

[fpsvogel]

I tried nested Structs too, instead of .as_dots below, but that didn't make the tests in this file run noticeably faster.

[fpsvogel]

I made these into keyword arguments in a separate commit to avoid one gross call to this method. If it's preferable to keep the positional args, I'm fine omitting that commit.

I added the :page_title arg because one of the new tests uses it in the component that it renders (see the expectation below). I'm passing in the page title rather than parsing the YAML header because that seems like overkill for just one test case that needs the page title to be available.

[fpsvogel]

:resource is needed for testing ruby_render (below).

[fpsvogel]

The rest of the changes in this file are the switch to keyword arguments.

[fpsvogel]

If we want to avoid eval, it might be better to use a non-Ruby syntax for the Liquid tag contents (such as the one we previously discussed in the GH Issue), because the other way to parse the contents (apart from eval) is via regex, and trying to emulate Ruby parsing via regex seems difficult to do well, even if we allow nothing other than component instantiation.

If the regex route is preferable, I assume it's because eval is insecure, but I would be curious to know how specifically, for this use case.

[fpsvogel]

Ruby components are the primary use case, so I'm not sure if it's worth mentioning that it's possible to render any Ruby expression—if it's not a component (i.e. doesn't have #render_in) then it's rendered with #to_s (see above).

[jaredcwhite]

Some cool stuff in here @fpsvogel. I'll want to think on this a bit…one of the promises of Liquid is that you're working within a "sandboxed" environment and all the values/tags/etc. live with the Liquid environment. If we punch a hole right into Ruby land with eval, it could end up with unexpected weird behavior. I'm not worried about the security aspect per se as Bridgetown isn't built around a "user-contributed" Liquid template content model, and there are no guarantees of safety in that respect, but there could be other gotchas.