Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[bug] :view key being deleted from options hash by #render #451

Closed
1 of 2 tasks
ryanmccarthypdx opened this issue Aug 8, 2024 · 2 comments
Closed
1 of 2 tasks

[bug] :view key being deleted from options hash by #render #451

ryanmccarthypdx opened this issue Aug 8, 2024 · 2 comments
Labels
bug An issue with the system

Comments

@ryanmccarthypdx
Copy link
Contributor

ryanmccarthypdx commented Aug 8, 2024

Is there an existing issue for this?

  • I have searched the existing issues

Is this a regression?

  • Yes, this used to work before

Current Behavior

It seems that the process of rendering is deleting the :view key from the options hash. This breaks batching as only the first batch can be rendered correctly with subsequent ones falling back to the default view.

Expected Behavior

Options k-v pairs should persist through to subsequent batch renders.

Steps To Reproduce

Given this blueprint:

class FooBlueprint < ApplicationBlueprint
  identifier :id

  view :with_bar_id do
    field :bar_id
  end
end

This code:

options = { a_key: 'a value', view: :with_bar_id }
prerendered_foos = []
Foo.limit(5).in_batches(of: 2) do |batch|
  prerendered_foos += FooBlueprint.render_as_hash(batch, options)
end

generates this as prerendered_foos:

[
  {:id=>1, :bar_id=>101},
  {:id=>2, :bar_id=>102},
  {:id=>3},
  {:id=>4},
  {:id=>5}
]

The rendering of the first batch deletes the view option and the subsequent batches fall back to the default identifier-only view.

The workaround I am currently using is to re-add the view to the options hash after every batch, but this is unsatisfactory.

Environment

- OS: OSX 14.4.1
- Browser Name and version: N/A
- Ruby Version: 3.2.4

Anything else?

No response

@ryanmccarthypdx ryanmccarthypdx added the bug An issue with the system label Aug 8, 2024
@jhollinger
Copy link
Contributor

FWIW this looks like a good candidate to me, although it's five years old. But if your options hash is newly being shared across multiple renders, it seems a likely cause.

@ryanmccarthypdx
Copy link
Contributor Author

ryanmccarthypdx commented Aug 9, 2024

Ah, apologies, I was mistaken that this was working before; I discovered this during a refactor and I got my wires crossed. The code that @jhollinger references above is indeed the issue, so this is perhaps more of a 'feature request'.

I have this draft PR (currently without tests) to start the conversation about what a possible 'fix' for this could look like if we agree this is a good idea. I'm not really sure why the existing uses delete but perhaps someone has a good reason.

I have also edited the above to better illustrate this issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug An issue with the system
Projects
None yet
Development

No branches or pull requests

3 participants