Closed jaredcwhite closed 2 months ago
Your Render PR Server URL is https://bridgetown-beta-pr-890.onrender.com.
Follow its progress at https://dashboard.render.com/static/srv-conc9een7f5s73b4g0r0.
Your Render PR Server URL is https://bridgetown-api-pr-890.onrender.com.
Follow its progress at https://dashboard.render.com/static/srv-conc9emn7f5s73b4g110.
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.