Bridgetown 1.2 “Bonny Slope” Takes Your Applications to the Next Level
Jared White
on Earlier this year we released Bridgetown 1.1 “Belmont”, which itself was a followup release after 1.0 “Pearl”. It’s been a busy year! 😄 And now we’re pleased to announce the beta release of Bridgetown 1.2 “Bonny Slope”. There are some specific points to make around upgrading to Bridgetown 1.2 for both sites and plugins, so read up on all that in our latest Upgrade Guide.
There’s some cool stuff in the Bridgetown 1.2 release such as simplified data access in templates, and “slotted” content for both templates and components. But before we get to that, let’s discuss the Big Feature of Bridgetown 1.2 which at first glance seems not very exciting, but is actually really really important and will affect all your sites & applications going forward.
Start Me Up #
Most frameworks have some sort of initialization or boot up sequence. They typically give you a way to hook into this initialization sequence in order to import new code or customize what happens when the framework first loads. No doubt you have experienced this in many other frameworks from Rails to NestJS.
Bridgetown, curiously, has not offered an initialization sequence that’s “open to the public”. We just did stuff, as if by magic. Some magic in programming is good, but when it comes to how your application starts up and first runs, we’d prefer to err on the side of explicit determinism. If you want A, B, C, D, and E to happen—in that order— and only D should happen in this context, and only E should happen in some other context—then by golly you should be able to specify that in your code. (If you’re curious, there’s a whole podcast about this singular topic on Fullstack Ruby.)
To date, Bridgetown’s configuration format has been a single YAML file. You can set some options and…that’s it. Fine for simple projects, but after a while this starts to feel rather limiting. You could also add some Ruby code to your plugins/site_builder.rb file to set up a gem and whatnot, but honestly that file was never designed expressly for placing arbitrary “run this once and only once” boot code. In addition, we’ve had a long-running convention that placing certain gems in a certain Gemfile group (bridgetown_plugins) would mean that they are automatically loaded by Bridgetown during initialization. But this convention means you’d never really know what is loading when, and it doesn’t provide any code-level mechanism for attaching configuration options to that plugin. And more recently, our integration with the Roda web toolkit means we have to accommodate Roda plugins as well, which are traditionally loaded and configured in their own unique way.
Customize All the Things, Now in Ruby 😎 #
Wouldn’t it be great if we could solve all of these problems at once? 🤯😃
Yes, it would. And that’s just what we did in Bridgetown 1.2. We’ve introduced a brand new Ruby-based configuration format that lets you require gems, load plugins, set configuration options, and customize your Roda application—all at the same time with everything in one place. Say hello to config/initializers.rb. It looks something like this:
Bridgetown.configure do |config|
permalink "simple"
timezone "America/Los_Angeles"
config.autoload_paths << {
path: "models",
eager: true
}
init :dotenv
init :ssr do
setup -> site do
site.collections.products.read
end
end
init :"bridgetown-routes"
init :"bridgetown-feed"
init :"bridgetown-lit-renderer"
only :server do
init :parse_routes
roda do |app|
app.plugin :sessions, secret: ENV["RODA_SECRET_KEY"]
end
end
end
(Don’t worry if this all looks like gobble-dee-gook at first…it will be become clearer as you get familiar with the new system!)
Besides the obvious stuff like setting configuration options, you can set up your plugin boot sequence using init statements. And you can nest configuration within only or except blocks for context-specific settings.
Bridgetown plugins can provide their own initializers that are built out of real Ruby code and accept options as real Ruby objects. You can also write your own initializers, initializers can depend on other initializers, you can chain multiple initializers together, you can introspect initializers during boot…yeah, it’s a lot. 😄
Read more about this in our new Initializers documentation. If you maintain Bridgetown plugins, please start upgrading your plugins to support initializers in Bridgetown 1.2+. We also welcome your feedback on the new system to make things as easy and expressive as possible.
(What about bridgetown.config.yml? We will continue to support this configuration format for the foreseeable future, and in Bridgetown 1.2 it’s still recommended to have that file in place. But in Bridgetown 2.0+, it’s likely we will make it entirely optional. Ruby-based configuration can just do so much more than any YAML file.)
What This Enables in the Ecosystem #
The story doesn’t end there. A whole new ecosystem of plugins is now possible which will unlock powerful new features in your Bridgetown applications.
For example, you can now add Active Record to your Bridgetown projects. Pull content in directly from a database, or even create a dynamic CRUD-style application without ever leaving Bridgetown. We’ve also released a new Turbo plugin that lets you use Turbo Streams in responses from your Roda routes for some awesome UX around submitting forms. Speaking of submitting forms, there’s a new gem in the works called Lifeform which gives you the means to create declarative form objects which can be easily rendered in your templates (and then you’d process those form submissions via Roda routes). Sweet!
And stay tuned for even more goodies: an integration with Sidekiq for running background jobs to do all sorts of things from sending out email digests to updating content on your site without you having to lift a finger. Or how about authentication and authorization, or paywalls, or a cohesive story around using Stripe for accepting payments. Whoa!
Bridgetown 1.2 really blows the doors wide open for a new level of sophistication and quality around the kinds of plugins you can use in your applications. 2023 will be The Year of Bridgetown Plugins. And as we’ve been saying for some time now, we’re no longer just a static site generator but a feature-rich Ruby web application framework. Let’s get building.
About Those Other Features Though… #
The new configuration/initialization system alone may be a lot to take in, but Bridgetown 1.2 also comes with some helpful improvements to make your life as a developer easier. Namely: simplified front matter/data access, and content slots.
Are you getting sick of typing in resource.data.xyz all the time? Yeah, me too. So now you don’t have to. ☺️ Just type data.xyz. Boom! data.title, data.video_id, whatever, it’s all good. For certain fields of course, you’ll still need to use the resource object directly like with resource.relative_url or resource.summary.
But that’s not all! You can now merge in site data and access it via the same data object! So for example you could type in data.authors[data.author] to get access to site data about the author of a particular resource. Awesome sauce. Read the docs here.
Content slots provide a new way to manage how your content flows through templates and layouts. In a resource or page template, you could define a block of content to be put into a slot, and then “up higher” in the view hierarchy (a layout or a partial) you could render out the slotted content. This is great for additions to <head> or right above </body>, or extra content on sidebars…you name it. Slots are also a fantastic addition to Bridgetown’s Ruby components…you can render parts of your component via slots like headers, footers, or other content regions. Read the docs here.
(Note: this feature is only available via Ruby-based templates such as ERB, not Liquid.)
Save the Date! BridgetownConf 2022 is Coming Up Quick! #
With all of the work to get Bridgetown 1.2 out the door, we’re a little behind in getting our official materials published for BridgetownConf, but you can go here to save the date and get notified when it’s ready! It’s happening online, world-wide, for free on Monday, November 7, 2022. Don’t miss it! We’ll dive into some of the new features of Bridgetown 1.2, as well as showcase demos of how folks are building real-world sites and applications using Bridgetown.
Thanks for reading this far, and as always if you run into any issues trying out Bridgetown please hop into our community channels and let us know how we can help. And if you’re new to Ruby, we’re also pleased to recommend other resources and communities which can give you a leg up in learning this delightful and productive language.