danott.co

Archive 2016

Today I Learned

August 31, 2016

Today I needed to re-raise an error in ruby, but change the error message slightly. It turns out this is baked right in to the use of raise!

do
  # something that raises
rescue => e
  raise e, "This is my modified message"
end

The docs!


Today I Learned

May 3, 2016

import statements can be picky When using ES2015. With the variety of Babel plugins and configurations it’s easy to have some technically invalid syntax that compiles just fine in that configuration.

// family.js
export default {
  george: "Grandpa",
  michael: "Dad",
  maeby: "Cousin",
}

// uses_family.js
import { maeby } from "./family.js"

I don’t know what plugin I was relying on but previously this import statement worked. It turns out that destructuring off a default export is not actually a thing.

Option 1:

// family.js
export const george = "Grandpa"
export const michael = "Dad"
export const maeby = "Cousin"
export default { george, michael, maeby }

// uses_family.js
import { maeby } from "./family.js"

Option 2:

// family.js
export default {
  george: "Grandpa",
  michael: "Dad",
  maeby: "Cousin",
}

// uses_family.js
import Family from "./family.js"
const { maeby } = Family






Today I Learned

March 9, 2016

Rails will save associations by default. If you build an in-memory representation of a record that’s not intended to be saved with a call to update you need to do one of two things.

  1. Set autosave to false. Example: has_one :other_thing autosave: false.
  2. Don’t associate the built record with the object you’re saving

This default behavior manifested itself because I was doing something of the form:

class Thing
  has_one :other_thing # 1. Use autosave: false

  def optimistic_version_of_other_thing
    OtherThing.new(thing: self) # 2. don't associate the record with self
  end
end

thing = Thing.last
thing.optimistic_version_of_other # I don't want this persisted
thing.update(anything: "else")

Today I Learned

January 27, 2016

I’m almost always wanting to add configuration hooks to Rails engines when I build them. Up to this point I’ve never taken the time to figure out the most succinct way to provide configuration hooks. It turns out that it’s much simpler than I even imagined.

module MyGem
  class Engine < ::Rails::Engine
    isolate_namespace MyGem

    config.my_gem = ActiveSupport::OrderedOptions.new
    config.my_gem.some_setting = true
  end
end

That’s it! Setting config directly in the class definition will expose the configuration in the consuming Rails application.


Today I Learned

January 7, 2016

Today I re-learned about ActionController::TestCase. It’s pretty common to send the request parameters in as the second argument. What I always forget is that the third and fourth parameters represent the session and the flash respectively.

test "something that depends on the session and the flash" do
  post :create, { always: "money" }, { in: "the" }, { banana: "stand" }
  assert_equal params[:always], "money"
  assert_equal session[:in], "the"
  refute_equal flash[:banana], "stand" # because the flash will have been flushed!
end