Skip to content

Setting the context of a liquid variable can cause a namespace collision #1930

@brendon

Description

@brendon

I have a drop like this:

class FolderDrop < Liquid::Drop
  def initialize(folder)
    @folder = folder
  end

  delegate :name, to: :@folder

  def children
    @folder.component_instance.children.current.front_end.to_a
  end
end

I have a ComponentInstance drop that exposes a few methods like normal.

In the past, returning an array of ActiveRecord models that respond to to_liquid worked well. Liquid would call to_liquid on each in turn and we'd get the resulting liquid array with liquid objects.

This PR introduced the concept of calling context= on the item before calling to_liquid. This is confusing anyway since how do we know that this common method name isn't already being used? Shouldn't the attribute at least be namespaced (liquid_context)?

#1781

In my case I have a column called context and coincidentally set it as a attr_readonly in Active Record. This caused a hard to debug LiquidError: internal so I ended up hacking my copy of liquid to raise the real error which was ReadonlyAttributeError on the column.

So I guess I have a few questions:

  • Why doesn't Liquid allow the real error to be surfaced in a development environment (acknowledging that it's not just used in Rails)?
  • Am I wrong in returning an array of values without calling to_liquid on them myself first?
  • Is the solution to this to namespace the context attribute in liquid?

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions