Simplify access to data syntax and Roda rendering #890
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
After writing
data.xyz
a zillion times, you start to wonder if you can just writexyz
. 😂And in the continuing saga of questioning boilerplate, I wondered if I could get rid of
render_with {}
(which works due to copying local block variables down to the template) while at it.So this is now possible in a dynamic Roda route:
Nice! 😌
Of course this will still work equally well:
And regular front matter in static resources:
For folks who for whatever reason don't like this simplified syntax, the
support_data_as_view_methods
option can be set tofalse
in the Bridgetown config, and thendata.foo
syntax is still mandatory.For the Ruby nerds out there, the previous
instance_eval
code I'd written turned out to have a very strange side effect: even though the procs are eventually executed in the context of a Roda app instance, any modules/classes defined would actually be attached to the singleton class ofBridgetown::Routes::CodeBlocks
. Weird, right? The likelihood of a file-based route needing to define a standalone module/class is low, but if it's supported it might as well work like any standard Ruby file beingrequire
d at runtime. So I switched it up to useKernel.eval
andTOPLEVEL_BINDING
instead ofBridgetown::Routes::CodeBlocks.instance_eval
. Works! 😅Also I finally got proper line number error reporting working as expected. This has been an ongoing frustration…turns out part of the reason why this has been inconsistent is our front matter regexps were swallowing a variable amount of newlines as whitespace around the template boundaries via
\s
. Changing that to[ \t]
resolves the issue, and then callinglstrip
restores the previous whitespace behavior after regexp parsing.