Strict slots #1574
-
I feel like I've seen some discussion around this before, but I can't remember when or where. Is there any appetite for defining strict slots? Something like this, perhaps. class StrictSlotComponent < BaseComponent
renders_one :heading, strict: true
end <%= render StrictSlotComponent.new %> # raises MissingSlotError
<%= render StrictSlotComponent.new do |c| %>
c.heading { <h1>A big heading!</h1> }
<% end %> If there is, I can open a PR. |
Beta Was this translation helpful? Give feedback.
Replies: 3 comments 2 replies
-
It seems familiar to me too! However, the idea of raising errors when rendering components brings to mind fetch-or-fallback as mentioned in this talk (I forget where exactly, but it was in the context of validations). Fetch-or-fallback could naturally have compatibility with slots, particularly if it's implemented with, say, ActiveModel validations. Adding some tools to help folks implement that natively to ViewComponent has been in the back of my mind for some time, and I'm sure the others have considered it too 🤔 |
Beta Was this translation helpful? Give feedback.
-
What would be the behavior if strict is specified and a lamba is also provided? Does it call the lambda or does it still raise an error? |
Beta Was this translation helpful? Give feedback.
-
Hi @cpjmcquillan! Thanks for raising this question. I agree with @boardfish. The issue with errors like this in our experience at GitHub is that we haven't wanted them to raise in production. That's why we use the fetch-or-fallback pattern, where we have a safe default to use in production but raise an error in dev/test. I think 500'ing in production for a misuse of a ViewComponent is something to be avoided at all costs. |
Beta Was this translation helpful? Give feedback.
Hi @cpjmcquillan! Thanks for raising this question. I agree with @boardfish.
The issue with errors like this in our experience at GitHub is that we haven't wanted them to raise in production. That's why we use the fetch-or-fallback pattern, where we have a safe default to use in production but raise an error in dev/test.
I think 500'ing in production for a misuse of a ViewComponent is something to be avoided at all costs.