-
I'm making a TabsComponent which renders a bunch of items as tabs. I know I can pass the items in as a keyword argument but I'm trying to make a nicer syntax and this is what I came up with. I don't want to use slots because each tab item is too small to justify its own component. Is there any reason why this approach is a bad idea?
|
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 4 replies
-
Hi @aa365, thanks for opening this discussion! I feel like this is acceptable, personally, and at least at this stage in your component's life, it may even be preferable to using slots. I haven't really used this pattern myself, but I feel like it's a good stand-in until you come to need a I wonder what folks think about officially documenting this pattern alongside slots? |
Beta Was this translation helpful? Give feedback.
-
@aa365 @boardfish a slot doesn't need to be a component. You can use a lambda slot instead [1], like this: renders_many :items, ->(name, url) { [name, url] } Then you use it like a regular slot: = render TabsComponent.new do |t|
- t.with_item 'foo', 'bar' I'm using this technique to support passing both a single value or a block to a slot: renders_one :action, lambda { |value = nil, &block|
block&.call || value
} Use it with a single value: = render Component.new do |c|
- c.with_action "foo" Or a block: = render Component.new do |c|
- c.with_action do
= link_to "foo" |
Beta Was this translation helpful? Give feedback.
Hi @aa365, thanks for opening this discussion! I feel like this is acceptable, personally, and at least at this stage in your component's life, it may even be preferable to using slots. I haven't really used this pattern myself, but I feel like it's a good stand-in until you come to need a
renders_many
slot. That day may come when tabs become their own components and/or takecontent
of their own, and this pattern will be compatible with that change when it comes to be made.I wonder what folks think about officially documenting this pattern alongside slots?