TIL

Sometimes we learn stuff and we share it with you fine people.
All blog posts

• Mar 15, 2023 / Matthew Lettini / TIL

  With conversation threading (which almost everyone has enabled), Gmail was trimming the bottom of the emails we send with our new app because they were too similar to the other emails in the conversation thread.

  They’re similar because that’s just the link to get back into the app—you know, the important bit to keep our users engaged! Having that trimmed is bad.

  The solution to this is silly: Gmail will not trim content if it’s always unique, so now we add a unique/random number to the bottom of every email we send. Insert eye roll.

• Feb 23, 2023 / Barry Hess / TIL

  I am working on a new product that's a bit more complicated than our prior releases. Getting refamiliarized with nested parameters in Rails has been interesting. In this case imagine I have a discussion that, when creating it I also want to create the first comment. The discussion information is in a form with a nested form for the comment. So at the base you have these permitted parameters:

  params.require(:discussion).permit(:title, comments_attributes: [:body])

  That is fine, but I wanted to assure that the discussion and comment couldn't be messed with and would always be associated with the logged in, current_user. Stack Overflow told me this would be pretty straightforward these days. Unfortunately that didn't work for me. Perhaps I'm doing something wrong, but I had to get a little more…into it.

  def discussion_params
    _discussion_params = params.require(:discussion).permit(:title, comments_attributes: [:body])
    _discussion_params.reverse_merge!(user_id: current_user.id)
    _discussion_params[:comments_attributes].each do |key, value|
      _discussion_params[:comments_attributes][key] = value.reverse_merge(user_id: current_user.id)
    end
    _discussion_params
  end

  I'd be happy to hear that there's an easier way.

• Feb 15, 2023 / Barry Hess / TIL

  I am working on search for Album Whale and I was very confused when my JavaScript fetch requests were not resulting in turbo_stream rendering getting displayed on my page. I checked my logs to see if the render was happening. I looked for missing <%= tags. Debugged and logger.info'd all over.

  Then I finally noticed the following in my Rails logs:

  Processing by AlbumsController#search as */*

  Oh, I expected that to say something about TURBO_STREAM, like:

  Processing by AlbumsController#search as TURBO_STREAM

  This sent me on a dive into headers (I didn't have an Accept header on my fetch request), response handling, and the fetch API.

  Here's what I came up with for our first rough cut of a working, live search field (this is Stimulus code):

  async searchForAlbum() {
    let queryString = this.queryStringTarget.value
    if (queryString.length > 2) {
      fetch(this.urlValue, {
          method: 'POST',
          body: JSON.stringify({
            "queryString": queryString
          }),
          credentials: 'same-origin',
          headers: this.getHeaders()
        })
        .then((response) => {
          if (!response.ok) {
            alert("something went wrong!");
            window.location.reload(true);
          }
          return response.text()
        })
        # Here we need to pass the response to Turbo for processing
        .then((html) => Turbo.renderStreamMessage(html))
    }
  }
  
  getHeaders() {
    let headers = new Headers()
    headers.append('Content-Type', 'application/json')
    # Here we want a Turbo response
    headers.append('Accept', 'text/vnd.turbo-stream.html')
    headers.append('X-CSRF-Token', document.querySelector('meta[name="csrf-token"]').content)
    return headers
  }

  I suspect there's a more succinct way to do this, but I'm setting it down for now.

• Feb 8, 2023 / Barry Hess / TIL

  I had to figure out how to run browser-based tests in Rails again. In part that meant working around my lack of Chrome. Rails System Tests with Safari.

  I also had some problems with Rails Turbo Drive taking over EVERYTHING, which required me to figure out how to deal with a Rails form redirect not rendering HTML.

• Feb 7, 2023 / Shawn Liu / TIL

  We noticed that the victory symbol at the bottom of our homepage looked different in Chrome than Safari––it was playing smart and rendered the unicode character as an emoji. Lettini found a fix though! Append this string of code to the symbol: ︎.

  So ✌︎ renders to ✌︎ and not emoji. Weird.

  (Here’s a blogpost that explains it all.)

• Feb 7, 2023 / Barry Hess / TIL

  DoEvery.Day calendar navigation was broken. We built it using Turbo Rails as it was being developed. As we have updated libraries, including Rails, the API has changed. In order to get the calendar navigation working again, I had to pull out some old hacks that made use of turbo_stream_action_tag via Turbo Streams to get my Turbo Frames working. The code is a bit more straightforward now, though I find Turbo Frames to feel a little too magical.

  Turbo Frames Vs. Turbo Streams gave me my first hints at how to fix things up, but the example request flow was a little too odd for me to absorb. Turbo Frames and Turbo Stream templates ended up explaining things well enough that I could get the issue resolved.

  I ended up in this PR to re-discover how a Turbo-Frame-based request can update the browser’s URL. In this case that’s data-turbo-action, which in practice looks something like:

  link_to("My Link", my_path(data: { turbo_frame: "tf_calendar", turbo_action: :advance })

More to come.
Subscribe to A Good Enough Newsletter to stay tuned.