DEV Community: Konnor Rogers

Pulling your dev.to posts down locally

Konnor Rogers — Tue, 20 Jun 2023 21:30:52 +0000

Alright kids! Strap in! This is kind of a meta post since I'm writing it here on dev.to, but I'm about to show you how I pulled all my writings on dev.to down locally into a new Bridgetown site I made! (Which may feature a blog...who knows...)

First step, create a file to run your script. I'll be using Ruby here, but feel free to use whatever language you fancy.

First, let's grab all the articles I've written. Feel free to change username to match your dev.to username.

#!/usr/bin/env ruby

require "json"
require "net/http"
require "time"

username = "konnorrogers"

json = JSON.parse(
  Net::HTTP.get(URI("https://dev.to/api/articles?username
=#{username}"))
)

Done right?!

Not quite! We still need to loop through all of our articles and gather the content we need. To help with exploring the dev.to API, you can write the return JSON to a file like this:

filename = "./articles.json"
File.write(filename,
  JSON.pretty_generate(
    JSON.parse(
      Net::HTTP.get(URI("https://dev.to/api/articles?username
=#{username}"))
    )
  ).to_s
)

However, I already did this part and know what I need for my Bridgetown site, but feel free to use the snippet above for exploring the API. We use pretty_generate on the JSON so its easier to read.

Anyways, when looking through the data returned we don't get back the body_markdown which has the raw markdown for our posts. What we need to do is loop through all of our "articles" and then grab the body_markdown property for each one.

Here we go:

json.each do |obj|
  title = obj["title"]

  # turn anything thats not a number or letter into a hyphen, then squash reoccurring hypens into 1
  # Example: 
  #   "How can I pull my data from dev.to?"
  #=> "how-can-i-pull-my-data-from-dev-to"
  file_title = title.downcase.gsub(/[^0-9a-z]/i, "-").split(/-+/).join("-")

  # Produces a string like this: 2023-06-20 17:24:40 -0400
  date = Time.parse(obj["published_at"]).to_s

  # Pulls only yyyy-mm-dd
  file_date = date.split(" ").first

  # produces a path like this:
  # "src/_posts/2023-06-20-pulling-your-devto-posts-down-locally.md"
  file_path = "src/_posts/#{file_date}-#{file_title}.md"

  # don't waste an API call!
  next if File.exist(file_path)

  description = obj["description"]

  # Comma separated string
  categories = obj["tags"]

  article_path = obj["path"]
  article_url = URI("https://dev.to/api/articles#{article_path}")

  # One second seems to be the secret sauce to get around rate limiting.
  sleep 1

  # We can't get the info we need from the initial API call so we need to go to the article_url
  # to get the raw markdown.
  article_json = JSON.parse(Net::HTTP.get(article_url))
  body_markdown = article_json["body_markdown"]

  content = "---\n"
  content << "title: "#{title}\n\""
  content << "categories: #{categories}\n"
  content << "date: #{date}\n"
  content << "description: "|\n  #{description}\n\""
  content << "---\n\n"
  content << body_markdown

  File.write(file_path, content, mode: "w")
end

Now let's run our script and watch the magic happen. This may take a while because dev.to rate limits to what seems to be about 1 API call per second, so if you have say 60 posts, it'll take roughly 1minute to gather all your files.

ruby my-script.rb

And here's what it pulled down for me!

src/_posts/2023-06-13-inserting-a-string-on-the-first-line-of-every-file-with-vim.md
src/_posts/2023-06-07-maintain-scroll-position-in-turbo-without-data-turbo-permanent.md
src/_posts/2023-05-30-button-to-vs-link-to-and-the-pitfalls-of-data-turbo-method.md
src/_posts/2023-05-22-rails-frontend-bundling-which-one-should-i-choose.md
src/_posts/2023-05-22-revisiting-box-sizing-best-practices.md
src/_posts/2023-04-08-how-to-keep-a-persistent-class-on-a-litelement.md
src/_posts/2022-11-22-jest-vitest-and-webcomponents.md
src/_posts/2022-10-20-actiontext-all-the-ways-to-render-an-actiontext-attachment.md
src/_posts/2022-10-10-actiontext-safe-listing-attributes-and-tags.md
src/_posts/2022-10-04-actiontext-modify-the-rendering-of-activestorage-attachments.md
src/_posts/2022-07-20-why-we-still-bundle-with-http-2-in-2022.md
src/_posts/2022-04-08-testing-scopes-with-rails.md
src/_posts/2022-04-07-adding-additional-actions-to-trix.md
src/_posts/2022-03-13-converting-a-callback-to-a-promise.md
src/_posts/2022-03-10-escaping-the-traditional-rails-form.md
src/_posts/2022-02-21-adding-text-alignment-to-trix.md
src/_posts/2022-01-29-modifying-the-default-toolbar-in-trix.md
src/_posts/2022-01-29-exploring-trix.md
src/_posts/2021-11-30-cross-browser-vertical-slider-using-input-type-range.md
src/_posts/2021-11-01-rebuilding-activestorage-first-impressions.md
src/_posts/2021-10-27-why-jest-is-not-for-me.md
src/_posts/2021-10-06-frontend-bundler-braindump.md
src/_posts/2021-07-08-writing-code-block-highlighting-to-a-css-file-with-rouge.md
src/_posts/2021-07-06-creating-reusable-flashes-in-rails-using-shoelace.md
src/_posts/2021-07-03-pulling-down-somebody-s-fork-with-git.md
src/_posts/2021-07-02-fixing-fatal-error-ineffective-mark-compacts-near-heap-limit-allocation-failed-javascript-heap-out-of-memory-in-webpacker.md
src/_posts/2021-07-02-migrating-hls-videos-to-mp4-format-in-rails.md
src/_posts/2021-06-25-querying-activestorage-attachments.md
src/_posts/2021-05-25-case-switch-statement-in-ruby.md
src/_posts/2021-05-15-arel-notes.md

Best of luck and hopefully this gives you some motivation to dust off your self-hosted blog! I personally have been writing on dev.to because my old blog site is a 4 year old Gatsby site I have exactly 0 hope of ever getting running again. So here's to new beginnings! 🥂

Inserting a string on the first line of every file with Vim

Konnor Rogers — Tue, 13 Jun 2023 19:15:30 +0000

Alright here it goes, I needed to add a header to all files. There are roughly ~72 files and I didn't want to do it by hand. The header in question was for test files in Shoelace.

I stumbled across this StackOverflow link:

https://stackoverflow.com/questions/30541582/how-do-i-insert-the-same-line-into-multiple-files-using-vim

Which was 99% of what I wanted, but didnt show how to use "put" without using a register.

So here's the magic few commands that saved me a bunch of time.

:args ./**/*.test.ts
:argdo 1put! = 'import \"../../../dist/shoelace.js\"' | write | update

The first line :args ./**/*.test.ts tells us what files we want to look at. The second line: :argdo 1put! = 'import \"../../../dist/shoelace.js\"' | write | update says: "On the first line, put this statement above whatever is already on the first line, save the file, then update it in Vim.

That's all I got, mostly saving this for future me who may need this!

Maintain scroll position in Turbo without data-turbo-permanent

Konnor Rogers — Wed, 07 Jun 2023 20:44:01 +0000

Alright, this will be short and sweet for future me.

Maintaining scroll position is notoriously painful.

Some articles like this have you add data-turbo-permanent: https://dev.to/mikerogers0/persist-scroll-positions-with-hotwire-turbo-1ihk

Why not data-turbo-permanent? Well, in our case we had a sidebar with a highlighted link for the current page, which means link clicks allowed for updating the highlighted current link. There were some workarounds we could have done, but decided not to.

There is also this GitHub issue which has a ton of workarounds:

https://github.com/hotwired/turbo/issues/37

There are some snippets in there that are pretty close to this. Here's what I used recently that worked well. Here's what I came up with that worked for me.

import * as Turbo from '@hotwired/turbo'

if (!window.scrollPositions) {
  window.scrollPositions = {};
}

function preserveScroll () {
  document.querySelectorAll("[data-preserve-scroll]").forEach((element) => {
    scrollPositions[element.id] = element.scrollTop;
  })
}

function restoreScroll (event) {
  document.querySelectorAll("[data-preserve-scroll]").forEach((element) => {
    element.scrollTop = scrollPositions[element.id];
  }) 

  if (!event.detail.newBody) return
  // event.detail.newBody is the body element to be swapped in.
  // https://turbo.hotwired.dev/reference/events
  event.detail.newBody.querySelectorAll("[data-preserve-scroll]").forEach((element) => {
    element.scrollTop = scrollPositions[element.id];
  })
}

window.addEventListener("turbo:before-cache", preserveScroll)
window.addEventListener("turbo:before-render", restoreScroll)
window.addEventListener("turbo:render", restoreScroll)

There are 2 key things to note. Every element must have a unique ID, and every element must have a data-preserve-scroll on it. Like so:

<nav id="sidebar" data-preserve-scroll>
  <!-- stuff -->
</nav>

Happy hunting!

EDIT: The one downside to this approach is I've noticed a brief flicker in Safari / Chrome. No flicker in FF. Perhaps a Turbo Transition, or using data-turbo-permanent could remove the flicker.

EDIT 2: Fixed the flicker. Article updated.

button_to vs link_to and the pitfalls of data-turbo-method

Konnor Rogers — Tue, 30 May 2023 18:49:01 +0000

If you're familiar with Turbo, or even HTMX

You'll see this pattern come up frequently.

<a href="/logout" data-turbo-method="delete">Logout</a>
<a data-hx-delete="/logout">Logout</a>

Before we get into the difference, checkout @excid3 's video on button_to vs link_to: https://gorails.com/episodes/link_to-vs-button_to-in-rails?autoplay=1

Now let's dissect these one by one and checkout the issues.

Turbo anchors

We'll start with the Turbo version.

<a href="/logout" data-turbo-method="delete">Logout</a>

JS hasn't loaded

The problem with this is even though you're writing HTML, there is no such thing as a "delete link" in regular ole HTML. This link will fire a GET request if a user manages to click the link before your JavaScript loads.

Accessibility

Buttons and links tend to get separated by screenreaders. Buttons tend to get lumped under form controls, whereas links are put together with navigation.

In reality, to get the screenreader to read the button similarly, you would need to do something like this to get the browser to read it a little easier.

<a role="button" href="/logout" data-turbo-method="delete">Logout</a>

Done right?!

Not really. First rule of ARIA is don't use ARIA. Anchors have different semantics than buttons. In fact, its not even technically possible to disable anchors with regular HTML!

<!-- This is still clickable and doesn't get disabled -->
<a href="/blah" disabled>Logout</a>

So if for some reason you wanted to disable that anchor, it wouldn't be possible without JavaScript to intercept clicks! Even further, similar shortcuts between button vs anchor behave differently!

If I ctrl+click a button, it will still send my form and log me out, because it doesn't need JavaScript. If I ctrl+click the above link, the browser wont be able to send the DELETE request, and instead issue a GET request to "/logout" and it will feel broken to a user.

The HTMX example

<a data-hx-delete="/logout">Logout</a>

The problem with this is that an <a> without an href will not be clickable and not within the accessibility tree of focusable elements.

Okay so lets fix it!

<a href="javascript: void 0;" role="button" data-hx-delete="/logout">Logout</a>

<a tabindex="0" role="button" data-hx-delete="/logout">Logout</a>

Please don't do this. It's merely an example. Again, this hits similar pitfalls as Turbo links. If your JS fails to load, if a user ctrl+clicks, if JS hasn't finished loading, all of those situations will get this to appear broken. This doesn't even address anything to do with accessibility because that is a whole other can of worms. Just because you set a role="button" on there, it still doesn't behave the same because its not attached to a <form> so many assistive technologies will not treat it as a <button type="submit"> which is the default behavior of a <button> within a form.

Okay? But forms only support GET / POST.

Yes. <form> only supports GET / POST. This is true. It will depend on your server. Look up "method spoofing" or "method masking".

I wrote a primer on this in mrujs: https://mrujs.com/references/understanding-method-masking

And here's Laravel's docs on method spoofing. https://laravel.com/docs/10.x/routing#form-method-spoofing

And heres the rough HTML you would use in Laravel or Rails:

<form action="/logout" method="post">
  <input type="hidden" name="_method" value="delete">
  <button>Logout</button>
</form>

Or if you want to get fancy you can have the form and the button in two different places!

<form id="logout-form" action="/logout" method="post">
  <input type="hidden" name="_method" value="delete">
</form>

<!-- Other stuff here -->

<button form="logout-form" type="submit">Logout</button>

If you're using Rails form helpers, the hidden input is handled for you:

<%= form_with model: current_user do |form| %>
  <%= form.submit "Logout" %>
<% end %>

Look mom! No JavaScript!

TLDR

Please, just use buttons inside of forms to do non-GET requests. Yes, it may require more work to style it to look like a link, but I promise your users will thank you.

Rails Frontend Bundling - Which one should I choose?

Konnor Rogers — Mon, 22 May 2023 16:46:07 +0000

Propshaft? Or Sprockets?

If you use the following options:

ImportMaps
JSBundling-Rails

you'll be using either Sprockets or Propshaft. The default that Rails ships with is Sprockets.

If you're in a new application, I would try to start with Propshaft if possible. If you're attempting to migrate an existing application, I would probably go with Sprockets for compatibility with gems that may ship their own assets.

Why Propshaft?

Propshaft is much more streamlined, isn't as heavy handed as Sprockets, and has much more predictable behavior. It doesn't ship with as many features as Sprockets, but in this case, that's a feature.

We won't get into caching bugs with Sprockets, but I have noticed when things are FUBAR in local dev with Sprockets, rails assets:clobber is your friend.

ImportMaps

https://github.com/WICG/import-maps

What are importmaps?

At their core, importmaps are essentially aliases.

import "@hotwired/turbo-rails"

gets expanded to:

import "https://{{cdn}}/@hotwired/turbo-rails"

We won't get into the nitty gritty, but this is the basics of ImportMaps. ImportMaps also only apply to JavaScript files. You cannot import svg, png, css, etc files like people have come to expect from bundlers like Webpack. You can only import .js files.

To import css files, generally the easiest way is to insert a <link> tag that points to a prebuilt .css file from a CDN or locally.

Import Attributes (Import assertions) are coming, but aren't here yet, and it'll be interesting to see how they map to ImportMaps.

https://github.com/tc39/proposal-import-attributes

Why ImportMaps?

ImportMaps are the least invasive of all the tools. It also has the least number of features. Things like transpilation for older browsers, dependency graph management, and dead code elimination (tree-shaking) do not exist in importmaps.

If you plan to stick to the default packages Rails provides and don't plan to add much more JavaScript, ImportMaps will be a great tool for you. If you plan to add packages from NPM, or add a lot more JavaScript, or leverage any more advanced features ImportMaps may not be right for you.

Additional Notes on ImportMaps

ImportMaps are getting near universal adoption in newer browsers. And the polyfill for importmaps is really good. However, the timing of your JavaScript is different between browsers.

The order of operations, or when the JavaScript executes, is different between all browsers. Meaning you will need to be much more careful between browsers because of timing issues. Without being too specific, the reason for this is because the timing and execution of JS Modules has never been fully defined. Each browser is free to implement the parsing, evaluation, and execution stage of JS Modules however they see fit. This is not a problem for bundlers because they are able to make more guarantees when they parse + build your JavaScript for you.

The other problem with importmaps is some NPM packages may not be properly compiled for use in browsers from a CDN without a bundling step. These dependencies may have non-standard syntax which the browser may not be able to handle. The other problem is with nested dependencies. If the CDN doesn't inline dependencies, you may be stuck in a scenario where you have incompatible versions of the same dependency. If the CDN does inline dependencies, you're now shipping duplicate code.

JSBundling-Rails

Alright, you've decided that ImportMaps don't provide enough features, or maybe you have a specific package that may be problematic. JSBundling-Rails actually has generators for Rollup, Webpack, and ESBuild

https://github.com/rails/jsbundling-rails/tree/main/lib/install

But we'll focus on the ESBuild portion specifically. It's important to note that JSBundling-Rails is a few rakes tasks, it does not handle your actual asset URLs and paths. Asset URLs and paths will still be handled by Sprockets / Propshaft. JSBundling-Rails basically compiles your files into app/assets/builds and then the Rails asset pipelines picks up the unhashed files and will hash them for you. So even if you're using ESBuild via JSBundling-Rails, you're still using either Sprockets or Propshaft.

ESBuild

ESBuild is a great middle ground between Webpacker / Shakapacker and ImportMaps. ESBuild provides transpilation, tree-shaking, scope-hoisting, non-js imports, bare module imports, and much more.

ESBuild is also written in Go and is crazy fast compared to other bundlers.

** For the majority of applications ESBuild is probably the best option **

Why not ESBuild?

There are very few reasons not to use ESBuild. But there are a couple.

There's a whole list here: https://esbuild.github.io/content-types/#javascript-caveats

But I'll simplify it for you:

IE11. If you need to support ES5 browsers, but are writing ES6+ syntax (very rare these days), then ESBuild is not the tool for you.
Problematic dependencies. Some dependencies like CKEditor are designed specifically to work with Webpacker and won't work with other tools.

Webpacker / Shakapacker

Webpacker (now Shakapacker) is the oldest of the current frontend bundling tools. It's very robust and solid...and also confusing. This is the nuclear option if none of the other frontend bundling options will work for you. It will handle just about anything you throw at it (as long as you set it up properly). I don't have much more to add here, we've all dealt with Webpacker for the last few years.

Vite

Vite, in particular, ViteRuby is a solid option. It sits between ESBuild and Webpacker, and if you're looking at Webpacker, Vite may actually be a better option for you. It is a very solid option, and I've enjoyed using Vite personally.

Additional Caveats

Vite uses ESBuild in development, and Rollup for production. Occasionally this can cause issues because now production and development can be different and it is worth calling out.

Honorable Mention

Parcel 2

Parcel 2 is a very solid step up from Parcel 1. There are currently no Rails integrations for it, but it is very close to Vite in terms of developer experience.

Conclusion

For new applications ESBuild + Propshaft is probably the best option.

For existing applications ESBuild + Sprockets is probably the best option.

Importmaps are good for small projects / prototypes.

Vite is good for more powerful apps that may be leveraging React, Vue, Svelte, etc. and would like a more robust experience.

Webpacker / Shakapacker is there if you really need to support old browsers, legacy syntax, or have a problematic dependency.

Revisiting box-sizing best practices

Konnor Rogers — Mon, 22 May 2023 04:50:13 +0000

We've all googled "best way to set box-sizing: border-box;" and come across this fun article from CSS Tricks about setting box sizing.

https://css-tricks.com/box-sizing/

If you haven't read it, let me spare you some time.

Here's the "recommended" approach due to increased flexibility.

https://css-tricks.com/box-sizing/#aa-universal-box-sizing-with-inheritance

html {
  box-sizing: border-box;
}
*, *:before, *:after {
  box-sizing: inherit;
}

While this works if all of your elements are in the light DOM, tonight I discovered a fun bug plaguing my site.

If you have an element that is "slotted" into a custom element's shadow DOM, it will "inherit" the box-sizing of the slot element.

Example:

<script type="module">
  class MyElement extends HTMLElement {
    connectedCallback () {
      this.attachShadow({ mode: "open" })

      // These slots are automatically 
      // "box-sizing: content-box;" 
      // so this default slot causes all its children to have
      // the same box-sizing properties...
      this.shadowRoot.innerHTML = `<slot></slot>`
    }
  }
  window.customElements.define("my-custom-element", MyElement)
</script>

<style>
  html {
    box-sizing: border-box;
  }

  *, *:after, *:before {
    box-sizing: inherit;
  }
</style>

<my-custom-element>
  <div>My box sizing is "content-box"</div>
</my-custom-element>

<div>My box sizing is "border-box"</div>

If you'd prefer, I also made a CodePen reproducing this issue.

https://codepen.io/paramagicdev/pen/abRPJjB?editors=1111

The "fix" is to use the "universal" box-sizing selector.

*,*:after,*:before {
  box-sizing: border-box;
}

Now, I don't know if the inherited box-sizing is a bug, but it sure does feel like a bug. But, at least there is a workaround. I tested in Firefox, Chrome, Safari, and Edge and got the same result in all 4. Modifying the box-sizing of the parent slot element does indeed fix it like you would expect.

How to keep a persistent class on a LitElement

Konnor Rogers — Sat, 08 Apr 2023 02:56:40 +0000

When working with lit, sometimes you want the host element to have a persistent class name. A good example is if I were using Shoelace I'd want my elements to look like this:

<sl-button class="sl-button"></sl-button>

That way if a user registers the button under another namespace, they can still target all instances with .sl-button {} in their CSS, or by using querySelectors. There are a number of use-cases, but lets forget about the "why", and focus on the how.

Here is how I found the most effective way to keep a persistent class on a LitElement.

import { LitElement } from "lit"
class MyElement extends LitElement {
  static properties = {
    class: { reflect: true }
  }

  connectedCallback () {
    super.connectedCallback()
    this.classList.add("my-element")
  }

  willUpdate (changedProperties) {
    if (changedProperties.has("class")) {
      this.classList.add("my-element");
    }
  }
}

Or for you folks out there using decorators:

import { LitElement } from "lit"
import { property } from "lit/decorators.js"

class MyElement extends LitElement {
  @property({ reflect: true }) class

  connectedCallback () {
    super.connectedCallback()
    this.classList.add("my-element")
  }

  willUpdate (changedProperties) {
    if (changedProperties.has("class")) {
      this.classList.add("my-element");
    }
  }
}

I'm sure there's another way to do this, but this has been the way that's worked for me!

Jest, Vitest, and WebComponents

Konnor Rogers — Tue, 22 Nov 2022 17:46:45 +0000

Purpose

Jest and the newer Vitest are inextricably linked with frontend testing tools. While I personally do not care for these tools, its important to understand a lot of projects are tied to them. As a result, even though their web component support / DOM mocking isn't the best, we should at least look at what it does support.

Shadow Root rendering

Jest underwent a major revamp and received support for web components around version 26.5.0 when it introduced JSDOM version 16.2.0 which added the ability to render shadow roots. Prior to this version, rendering of shadowRoots would not work as expected, so its important if your project is using shadowRoots, you make sure to check what version of JSDOM / Jest you're using.

Mocking more of the DOM

This major revamp also included a number of mocks for built-in
browser functions such as MutationObserver, document.createRange, and many others.

However, there are still some notable missing functionalities such as matchMedia, IntersectionObserver, ResizeObserver, and more that I'm sure I haven't bumped into. So if your WebComponents use these, make sure to mock those too!

https://jestjs.io/docs/manual-mocks#mocking-methods-which-are-not-implemented-in-jsdom

Jest transforms

I don't believe Vitest has this issue due to using ESM transforms via Vite, but when using Jest its important to remember that it expects CommonJS files, but will not transform node_modules for you. Many WebComponent libraries do not ship CJS files. So if you have an NPM package that ships ESM, you'll want to tell Jest to transform it via the "transformIgnorePatterns".

For example, if I were using Shoelace, I'd do this:

    "transformIgnorePatterns": ["node_modules/?!(@shoelace-style)"]

for more on transformIgnorePatterns, check this out:

https://jestjs.io/docs/tutorial-react-native#transformignorepatterns-customization

Focus order and keyboard events

I've noticed focus order and keyboard events can get messed up in JSDOM. Here's a spot where I don't have a fix. I've noticed that JSDOM does not always behave as expected with these and the only thing I can chalk it up to is that its dispatching events rather than sending the real actions to a browser.

JSDOM and Jest / Vitest come with so many caveats for WebComponents and browser testing in general, I can't recommend them in good faith. Nobody browses the web in JSDOM. If you hook up a custom runner to Jest that uses a real browser, now you're cookin'! I guess all this to say most of my beef lies with JSDOM and not necessarily Jest itself...

There are other projects like Playwright and Web Test Runner which will give you a real browser to work with and more closely mirror how your users will use your components.

ActionText: All the ways to render an ActionText Attachment

Konnor Rogers — Thu, 20 Oct 2022 23:11:46 +0000

There's so many ways to render an ActionText attachment, we can change the app/views/active_storage/blobs/_blob.html.erb as we saw in a previous post. This will apply to all ActiveStorage blobs. However, you may want more fine grained control for things like CustomAttachments. You'll also find some of the ways to change a models ActionText rendering method:

to_trix_content_attachment_partial_path
to_attachable_partial_path
to_partial_path

https://github.com/rails/rails/blob/b96ddea5f0b4ff8ed6e9dfe4df62f7571b147b11/actiontext/lib/action_text/attachable.rb#L70-L76

These methods are particularly useful when creating Custom Attachments. We won't cover those in this post, but that's where the above methods will come into play.

Let's talk about what each does:

to_trix_content_attachment_partial_path

Under the hood Rails calls value.to_trix_html when you render within your Trix editor using the rich_text_area form helper.

<%= form_with model: @post do |f| %>
  <!-- calls @post.body.to_trix_html -->
  <% f.rich_text_area :body %> 
<% end %>

https://github.com/rails/rails/blob/0c97d1db023de4df6d2df8829e5ee311ff0d0e28/actiontext/app/helpers/action_text/tag_helper.rb#L36

So to_trix_content_attachment_partial_path is what users will see in their editor.

to_attachable_partial_path

When the user hits save, then the editor will show the final output by calling:

to_attachable_partial_path

This allows you to create 2 experiences, one for the editor, and one for the final rendering.

to_partial_path

to_partial_path is a standard rendering path for models. This is used as a shortcut for to_attachable_partial_path and to_trix_content_attachment_partial_path.

For more on to_partial_path it's worth checking out this Thoughtbot article on rendering.

https://thoughtbot.com/blog/rendering-collections-in-rails

Here's what it may look like all together in an actual attachable model:

With an ActiveRecord Model

class User < ApplicationRecord
  include ActionText::Attachable

  # app/views/users/_mention.html.erb 
  # rendered in final rendering
  def to_attachment_partial_path
    "users/mention"
  end

  # app/views/users/_thumbnail.html.erb
  # rendered in Trix editor
  def to_trix_content_attachment_partial_path
    "users/thumbnail"
  end

  # app/views/users/_user.html.erb
  # rendered when calling <%= render User.first %>
  def to_partial_path
    "users/user"
  end
end

With a non-ActiveRecord model

class Youtube
  include ActiveModel::Model
  include ActiveModel::Attributes
  include GlobalID::Identification
  include ActionText::Attachable

  # to be eligible to create an "sgid" we need to implement an 
  #   "id" attribute.
  attribute :id

  # app/views/youtubes/_embed.html.erb 
  # rendered in final rendering
  def to_attachment_partial_path
    "youtubes/embed"
  end

  # app/views/youtubes/_thumbnail.html.erb
  # rendered in Trix editor
  def to_trix_content_attachment_partial_path
    "youtubes/thumbnail"
  end

  # app/views/youtubes/_youtube.html.erb
  # rendered when calling <%= render Youtube.first %>
  def to_partial_path
    "youtubes/youtube"
  end
end

Conclusion

to_trix_content_attachment_partial_path is for rendering in the editor
to_attachable_partial_path is for rendering in the final output
to_partial_path is for standard object rendering

For more on Attachments, particularly custom attachments checkout the following resources:

ActionText: Safe listing attributes and tags

Konnor Rogers — Mon, 10 Oct 2022 01:12:52 +0000

To safelist tags and attributes in ActionText we need to inspect the source since I was unable to find anywhere in the documentation how to do so.

Rails has a separate gem for sanitizing which can be found here:

https://github.com/rails/rails-html-sanitizer

The gem is utilized within ActionText by the content helper here:

https://github.com/rails/rails/blob/4328d0e16028a46bba79ab775e509a743ceaf18c/actiontext/app/helpers/action_text/content_helper.rb#L7-L10

What we can do with these mattr_accessors is override them by creating an initializer.

We can create a file called config/initializers/action_text.rb and fill it with some custom contents for allowable things. Let's say for example we wanted to add table editing. We'd need to add <table>, <tr>, <td>, <th>, <thead>, and <tbody>.

In addition, we may also want to add some additional attributes which we could also do here say perhaps target for links.

# config/initializers/action_text.rb

# Add table tags
ActionText::ContentHelper.allowed_tags += ["table", "tr", "td", "th", "thead", "tbody"]

# Add link attributes
ActionText::ContentHelper.allowed_attributes += ["rel", "target"]

You can also see an example from @excid3 's latest ActionText episode:

https://github.com/gorails-screencasts/modify-actiontext-html-output/blob/master/config/initializers/action_text.rb

https://gorails.com/episodes/modify-and-customize-actiontext-html-output?autoplay=1

If you're feeling real wild, you could even replace the sanitizer and scrubber with your own custom sanitizer / scrubber!

ActionText: Modify the rendering of ActiveStorage attachments

Konnor Rogers — Tue, 04 Oct 2022 21:39:36 +0000

If you have not already, make sure to run both the ActiveStorage and ActionText installers respectively.

The ActiveStorage generator should create a file that looks like this:

app/views/active_storage/blobs/_blob.html.erb

<figure class="attachment attachment--<%= blob.representable? ? "preview" : "file" %> attachment--<%= blob.filename.extension %>">
  <% if blob.representable? %>
    <%= image_tag blob.representation(resize_to_limit: local_assigns[:in_gallery] ? [ 800, 600 ] : [ 1024, 768 ]) %>
  <% end %>

  <figcaption class="attachment__caption">
    <% if caption = blob.try(:caption) %>
      <%= caption %>
    <% else %>
      <span class="attachment__name"><%= blob.filename %></span>
      <span class="attachment__size"><%= number_to_human_size blob.byte_size %></span>
    <% end %>
  </figcaption>
</figure>

You can modify this file however you see fit. For example, you may want to provide custom overrides onto these dimensions for things like retina rendering or other optimizations.

The reason I took the time to document this is because I noticed when I turned on file annotations for rendering partials, this is what showed up:

<!-- BEGIN /Users/konnorrogers/.asdf/installs/ruby/3.1.2/lib/ruby/gems/3.1.0/gems/actiontext-7.0.4/app/views/action_text/contents/_content.html.erb -->

Other use cases include using something like tailwind and adjusting the produced markup!

I'll be documenting more undocumented things from ActionText as I go along and hopefully will upstream them into the official Rails guides!

Why we still bundle with HTTP/2 in 2022

Konnor Rogers — Wed, 20 Jul 2022 00:05:28 +0000

HTTP/2 is out! CDNs are hot!

Perhaps you've heard of HTTP/2 and its Asset Multiplexing and the benefits it can bring to your project and allowing more assets to be loaded at once reducing the need for massive asset bundles and thus reducing cache churn.

The above is all true. HTTP/2 has done wonders for asset loading. However, HTTP/2 isn't a catch all solution that lets you ditch the current set of frontend bundlers and use CDN only solutions.

However, the problem is you lose out on a number of efficiencies that can be afforded by using a frontend bundler. To do this exercise, we'll be looking at Shoelace.

Shoelace is an open-source project that leverages web-components and CSS variables to create a coherent design system for your web application. This case study isn't about Shoelace is or is not doing, but merely used as an example of where CDNs fall down. Also, you should use Shoelace, it is a pretty cool project!

Lets get cracking

Shoelace's easiest installation path is by importing from a JS CDN like jsdelivr.

<link rel="stylesheet" href="https://cdn.jsdelivr.net/npm/@shoelace-style/shoelace@2.0.0-beta.78/dist/themes/light.css" />
<script type="module" src="https://cdn.jsdelivr.net/npm/@shoelace-style/shoelace@2.0.0-beta.78/dist/shoelace.js"></script>

Let's look at the network graph this creates.

Without diving too deep, what happens is Shoelace ships a base "module" that then uses a number of shared chunks generated by ESBuild. So when <script src="${cdn}@{versionNumber}/dist/shoelace.js" is requested, then it requests the chunks that also live on the same path, and those chunks may import other chunks and then those chunks are imported. You can see how if you have a deeply nested set of "chunks" this can quickly bloat response times and create the "waterfall" effect we see here. The "waterfall" is called that because each request is dependent on the request prior to it. Imagine you had multiple redirects happening on the same route.

redirect_to "/foo" -> redirect_to "/bar" -> redirect_to "baz"

It's the same effect. You don't know you need the next asset until you request the asset. Or in this case, the javascript file.

Mitigating The Waterfall

Enter <link rel="modulepreload">

https://developer.mozilla.org/en-US/docs/Web/HTML/Link_types/modulepreload

A module preload link allows you to request an asset without waiting for a browser to hit the chain of redirects for an asset. While good, its very hard to get right.

Let's look at https://jspm.org/ which is the default CDN used with the new Rails importmaps.

I generated a "modulepreload" graph for Shoelace-beta.78 and loaded it up in my index.html.

https://generator.jspm.io/#U2NjYGBkDM7IT81JTE5VyMwtyC8qyU0sYHAohorpFpdU5qTqw7gORnoGega6SakliXrmFgB/h42GPwA

You can see this 'waterfall' is a little less and the initial "chunks" are all requested in parallel reducing the "waterfall" effect! Modulepreloads are good and work to great effect here with Shoelace! However, they add a lot of overhead of whenever you upgrade your shoelace version you have to generate a new preload graph.

Let's also think beyond the scope of Shoelace, as we add more and more dependencies this module preload section can get quite large!

When you use a bundler, static code analysis is performed and your assets can all get preloaded into one single bundle and this code analysis is far deeper and much more complex than the simple file imports allowed by module preloading.

Unused import treeshaking

With traditional JavaScript modules imported from a CDN there is no treeshaking. What you request is what you get. With a bundler like Parcel / Rollup / Webpack / Vite, they can statically analyze whatever code you import and get rid of any code paths that don't get used. CDN's dont have this privilege since they have no introspection into your final code.

Heres a very basic example of how treeshaking would work from a dependency.

export function doTheRoar () { return "roar" }

export function doTheMeow () { return "meow" }

Then, in our application code we would do something like this:

import * as doIt from "./my-package"
console.log(doIt.doTheRoar())

In the above case, a bundler would get rid of the "doTheMeow" function and only ship "doTheRoar" in our final production bundle thus reducing the amount of JavaScript we ship. If we were using a CDN, doTheRoar and doTheMeow will always ship even if they don't get used.

Scope Hoisting

While we're on the topic of efficiency, we can talk about "scope hoisting". Scope hoisting is effectively as follows from the Parcel docs:

...concatenates modules into a single scope when possible, rather than wrapping each module in a separate function. This is called “scope hoisting”. This helps make minification more effective, and also improves runtime performance by making references between modules static rather than dynamic object lookups.

https://parceljs.org/features/scope-hoisting/

Scope hoisting helps minimize the amount of JavaScript we ship as well as improving our performance. That sounds pretty good to me!

Chunking, Code Splitting, and Code Duplication

Frontend bundlers allow us to "chunk" or "code split" our packages and ship smaller bundles and take advantage of HTTP/2! We can code split in a variety of ways that I won't talk about, but bottom line is you can do it. Code splitting allows us to make optimized chunks.

From the Parcel docs:

...allows you to split your application code into separate bundles which can be loaded on demand, resulting in smaller initial bundle sizes and faster load times

https://parceljs.org/features/code-splitting/

This means we can get per-page chunks and do fancy things like "lazy-load" non-critical dependencies. Yes, you can do this with regular module scripts, but it is a lot more manual work.

Chunking / splitting also lends itself to talk about dependency duplication. With CDNs, you can easily bloat the amount of JavaScript you import when you import similar, but slightly different versioned dependencies.

For example, Shoelace imports Lit and lets say you wanted to use Lit in your project. Because of how Shoelace imports Lit inside of CDN's to make it self-contained, you do not get access to Lit, so it means you have to import the library again on your own meaning its not a "shared" dependency.

https://unpkg.com/browse/@shoelace-style/shoelace@2.0.0-beta.78/dist/chunks/chunk.WWAD5WF4.js

With frontend bundlers, we could easily hook into lit and build Shoelace's source ourself allowing us to ship a smaller final bundle by not duplicating dependencies.

Our final point is in regards to cross-origin resource sharing. The common trope used to be

"if you import jquery on site A from a CDN and import jquery on site B from the same CDN, you don't incur the cost and the browser uses the cached version"

This isn't true anymore.
https://twitter.com/seldo/status/1486122838801063938

What does this change mean for you? If your sites live on modern hosting that provides a CDN and supports HTTP/2, you should drop the third-parties and ship all resources yourself. Relying on a third party resources offers little value in 2020.

While the final point may be contentious, especially those hosting their own resources on non-HTTP/2 routers (Looking at you Heroku), it is important to note that shipping first party dependencies offers a lot more control and can lead to better performance since an additional HTTP handshake doesn't need to be made to a 3rd party.

That's all folks!

While HTTP/2 offers a ton of performance benefits especially in regards to asset loading. It does not mean that we can't still find benefits in bundling our applications. At the end of the day, as long as you've evaluated the options and does what works best for your project, that's what really matters.

DEV Community: Konnor Rogers

Pulling your dev.to posts down locally

Inserting a string on the first line of every file with Vim

Maintain scroll position in Turbo without data-turbo-permanent

button_to vs link_to and the pitfalls of data-turbo-method

Turbo anchors

JS hasn't loaded

Accessibility

The HTMX example

Okay? But forms only support GET / POST.

TLDR

Rails Frontend Bundling - Which one should I choose?

Propshaft? Or Sprockets?

Why Propshaft?

ImportMaps

What are importmaps?

Why ImportMaps?

Additional Notes on ImportMaps

JSBundling-Rails

ESBuild

Why not ESBuild?

Webpacker / Shakapacker

Vite

Additional Caveats

Honorable Mention

Parcel 2

Conclusion

Revisiting box-sizing best practices

How to keep a persistent class on a LitElement

Jest, Vitest, and WebComponents

Purpose

Shadow Root rendering

Mocking more of the DOM

Jest transforms

Focus order and keyboard events

ActionText: All the ways to render an ActionText Attachment

to_trix_content_attachment_partial_path

to_attachable_partial_path

to_partial_path

With an ActiveRecord Model

With a non-ActiveRecord model

Conclusion

ActionText: Safe listing attributes and tags

ActionText: Modify the rendering of ActiveStorage attachments

Why we still bundle with HTTP/2 in 2022

Lets get cracking

Mitigating The Waterfall

Unused import treeshaking

Scope Hoisting

Chunking, Code Splitting, and Code Duplication

Cache sharing across sites and domains

That's all folks!