forked from bridgetownrb/bridgetown
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
- Loading branch information
1 parent
4516964
commit b162454
Showing
1 changed file
with
113 additions
and
0 deletions.
There are no files selected for viewing
113 changes: 113 additions & 0 deletions
113
bridgetown-website/src/_posts/2022/2022-07-18-1.1-belmont-is-here.md
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Original file line number | Diff line number | Diff line change |
---|---|---|
@@ -0,0 +1,113 @@ | ||
--- | ||
title: Bridgetown 1.1 “Belmont” Has Landed | ||
subtitle: "" | ||
author: jared | ||
category: release | ||
template_engine: none | ||
--- | ||
|
||
We're pleased to announce the release of **Bridgetown 1.1 "Belmont"**. | ||
|
||
Read the [release notes](https://github.com/bridgetownrb/bridgetown/releases/tag/v1.1.0) or [installation instructions](/docs/installation), or to upgrade from a previous version of 1.0, simply bump up the version numbers in your `Gemfile` and run: | ||
|
||
```sh | ||
$ bundle update bridgetown | ||
|
||
# or | ||
|
||
$ bundle update bridgetown bridgetown-routes | ||
``` | ||
|
||
You'll also need to run `bin/bridgetown esbuild|webpack update` to get the latest default configuration of esbuild or Webpack installed. | ||
|
||
[Check out our initial beta announcement](/release/welcome-to-belmont-1.1-beta/) for a full rundown of what's new in v1.1. The TL;DR version is: | ||
|
||
* **I18n**: you can create multilingual websites featuring multiple locales with URLs to match (aka `/en/products/widget`, `/es/products/widget`, etc.). | ||
* **HTML & XML Inspectors**: modify your rendered markup after the fact with some Nokogiri magic! | ||
* **Sass support within esbuild/PostCSS bundling**: we forget to mention this in the beta announcement! Bootstrap and Bulma users rejoice, you're stuck with Webpack no longer… | ||
* Your choice of automated installations of **Lit**, **Shoelace**, **Ruby2JS**, and **Open Props**. Oh yeah. | ||
* **Phrase highlighting in Markdown** (aka ::highlighed text::) via `::` or `==`, along with a default syntax highlighting stylesheet. | ||
|
||
We're also excited about publishing our first round of documentation on [how to migrate from Jekyll to Bridgetown](/docs/migrating-from)! If there's anything we can add to improve the migration guide, let us know. | ||
|
||
Please visit our [Community page](/community) to learn how to submit feedback, request help, and report issues. And a big shout out to our contributors and all who help make Bridgetown a thriving and growing community. | ||
|
||
### As Per Usual, More Changes are in Store… | ||
|
||
In our "[Cherry Blossoms 2022 Edition](/future/whats-next-cherry-blossoms-edition/)" of what's coming next for Bridgetown, we talked about a few ecosystem additions and improvements coincidng with the release of Bridgetown 1.1 such as an ActiveRecord plugin. | ||
|
||
Well…it turns out that will have to wait for Bridgetown 1.2. | ||
|
||
Here's the deal: Bridgetown's Builder-based plugin system is an evolution from Jekyll's plugin architecture. And Roda meanwhile has its own robust plugin ecosystem. Both solutions are fine, but as I've been going deeper and deeper into building web applications and pulling in various Ruby gems using the Bridgetown + Roda "metaframework", it has become clear to me that a canonical method of configuring and extending codebases using an understandable and comprehensive initialization process was necessary. The ad hoc method of adding various gems and throwing various "requires" and initialization steps in a Ruby file here or there simply wasn't cutting the mustard. Things like dotenv, Mail, Stripe, Turbo & CableReady, etc. | ||
|
||
So work is now underway on a new initialization process which is self-aware of which pieces can be shared between static builds and the Roda server, and which pieces are server-only (or static-only, although I suspect that's much more rare). In addition, the way Bridgetown plugins get built will change a little—the ultimate goal being that the `bridgetown_plugins` group within Bundler will no longer be necessary as dependencies/initializers will be defined in a concrete file with a straightforward DSL. Yes, just like how Roda-specific plugins work today. | ||
|
||
We also have a few tricks up our sleeves for component rendering, testing, and even preview in tools like Storybook. Ongoing experiments there look quite promising. | ||
|
||
While I'm disappointed to have to backtrack a little in what I'd promised earlier this year, I anticipate it will all start to come together sooner rather than later. The plan for the Bridgetown 1.2 release (shortly before the start of Q4 2022) is that will be _laser-focused_ on enhancements to Roda, SSR, Components, and Gem integrations, which should prove to be a welcome improvement to Bridgetown as a framework for building fast, stable, maintainable, and _understandable_ web applications. | ||
|
||
In the meantime, enjoy the release of Bridgetown 1.1… | ||
|
||
### …and to Whet Your Appetite… | ||
|
||
I recently migrated [my business website](https://www.whitefusion.studio) from Netlify to Render, and in the process I needed to handle contact form submissions directly since I could no longer use Netlify Forms. [Bridgetown Routes](/docs/routes) (and the upcoming Roda Turbo plugin) to the rescue! | ||
|
||
Here's the `src/_routes/contact-form.serb` route file in its entirety. In a nutshell, I render the bottom template portion twice: once in text form and one as HTML. I then make sure the "bot check" field was submitted correctly, otherwise I use [Turbo](https://turbo.hotwired.dev) to swap the field out for one with an error notice. If all is well, I use the [Mail gem](https://github.com/mikel/mail) to deliver the contact message to myself, and finally update the contact form modal by re-rendering the `ContactModal` component with Turbo. | ||
|
||
```serb | ||
~~~{% | ||
r.post "reset" do | ||
sleep 1 # intentionally allow modal to close on the frontend first | ||
turbo_stream.replace "contact-modal", render(ContactModal.new step: 1) | ||
end | ||
r.is do | ||
render_with => | ||
text_message | ||
render_with( | ||
data: { layout: :emails } | ||
) => | ||
html_message | ||
next html_message if r.params[:preview] | ||
if r.params[:bot_check] != "11" && r.params[:bot_check] != "eleven" | ||
next turbo_stream.replace_all( | ||
"#contact-modal sl-input[name=bot_check]", | ||
ContactModal.new(step: 1).bot_check(error: true) | ||
) | ||
end | ||
mail = Mail.deliver do | ||
to "Jared White <[email protected]>" | ||
from "Jared White <[email protected]>" | ||
subject "Whitefusion Contact Form" | ||
text_part do | ||
body text_message | ||
end | ||
html_part do | ||
content_type "text/html; charset=UTF-8" | ||
body html_message | ||
end | ||
end | ||
turbo_stream.update "contact-modal", render(ContactModal.new step: 2) | ||
end | ||
%}~~~ | ||
# Whitefusion Contact Form | ||
## Email Address | ||
{{ r.params[:email] }} | ||
## Message | ||
{{ r.params[:message] }} | ||
``` | ||
|
||
And because the website code is public on GitHub, [you can check it out here](https://github.com/whitefusionhq/whitefusion.studio/blob/main/src/_routes/contact-form.serb). | ||
|
||
This may be a fairly simple example in the end, but getting the ecosystem moving in concert up to this point has been quite the journey. I can't wait share more with you all. ☺️ |