Hah yeah, I think the naming on that one is just a little conflated, due to them calling normal non-keyword arguments ‘param’. It probably stems from before keyword arguments where in ruby core, and they were used more as a hash of options at the end of the list of your normal arguments.
I think that you've jumped the shark in this video suggestion. Personally, I believe that no additional libraries should be installed until all proper solutions have been exhausted. In this example, it sort of missed the point a little bit about the definition of Web Components (ie View Components in this case), a "Thumbnail" is a separate component to a Card, a thumbnail can be reused in other places, thus a Thumbnail component should be created, and in the initializer, place nil as the default, and in the call method put the image tag with @thumbnail.presence || "default title". Bam you're done. So, when the Card component gets created just use the thumbnail attribute or eliminate it, since it defaults to nil (optional), hits that part in the partial, just placing a render Thumbnail.new(thumbnail) and it will either have the thumbnail or nil and it will figure out what it should do, and you're just placing the one line in the Card partial without the if/else block. Or possibly to use the slot feature within the card component and point to the Thumbnail component. I enjoy your tips and suggestions and am a subscriber. This comment is being a little critical, since if I were a code reviewer and the developer thought that solving something by importing a new gem or library to solve something that is easily solvable using the current gem because all the avenues of the solution weren't examined, I would offer this as the simpler solution. Github (the creator of the View Component gem) has already thought of these scenarios for us, just use the solutions. And if it's not available and seems like it should be there, offer up a pull request.
Hi Tom, thanks for taking the time to put together such a detailed response! And thanks for subscribing to the channel :) Sorry, I haven’t made the purpose of this video clear, it’s not about how to design or compose ViewComponents, rather just how you can make use of dry-initialiser to simplify the initialiser and attr_reader code that we write for every single ViewComponent. While I agree that breaking down components into smaller more composable components is definitely the way to go. Doing this approach doesn’t take away from the removal of boilerplate code that dry-initialiser provides. If you have a separate thumbnail component, you still need to define an attr_reader and an initialiser on that component. Sometimes my example code can be overly simplistic for the sake of creating short videos, and to help take me a little less time to produce them. I do also agree with you on minimising third party libraries/gems, but would urge you to take a look at the dry-rb libraries, they are all very small and well put together and maintained. Hope that helps explain the purpose a little better :)
Been using dry-initializer with View Component in a previous company, works wonderfully 👌
very useful. I need to delve a bit more into view_component.
Quality tutorials.
Give us more.
Thank you please
Haha I’ll try my best!
Great tip
I was wondering for ages why this isn't a thing in vanilla Ruby 🤔
Yeah that would be neat!
Seems weird to me that an "option" is required by default :/
Great tooling though.
Hah yeah, I think the naming on that one is just a little conflated, due to them calling normal non-keyword arguments ‘param’. It probably stems from before keyword arguments where in ruby core, and they were used more as a hash of options at the end of the list of your normal arguments.
I think that you've jumped the shark in this video suggestion. Personally, I believe that no additional libraries should be installed until all proper solutions have been exhausted. In this example, it sort of missed the point a little bit about the definition of Web Components (ie View Components in this case), a "Thumbnail" is a separate component to a Card, a thumbnail can be reused in other places, thus a Thumbnail component should be created, and in the initializer, place nil as the default, and in the call method put the image tag with @thumbnail.presence || "default title". Bam you're done. So, when the Card component gets created just use the thumbnail attribute or eliminate it, since it defaults to nil (optional), hits that part in the partial, just placing a render Thumbnail.new(thumbnail) and it will either have the thumbnail or nil and it will figure out what it should do, and you're just placing the one line in the Card partial without the if/else block. Or possibly to use the slot feature within the card component and point to the Thumbnail component.
I enjoy your tips and suggestions and am a subscriber. This comment is being a little critical, since if I were a code reviewer and the developer thought that solving something by importing a new gem or library to solve something that is easily solvable using the current gem because all the avenues of the solution weren't examined, I would offer this as the simpler solution. Github (the creator of the View Component gem) has already thought of these scenarios for us, just use the solutions. And if it's not available and seems like it should be there, offer up a pull request.
Hi Tom, thanks for taking the time to put together such a detailed response! And thanks for subscribing to the channel :)
Sorry, I haven’t made the purpose of this video clear, it’s not about how to design or compose ViewComponents, rather just how you can make use of dry-initialiser to simplify the initialiser and attr_reader code that we write for every single ViewComponent.
While I agree that breaking down components into smaller more composable components is definitely the way to go. Doing this approach doesn’t take away from the removal of boilerplate code that dry-initialiser provides. If you have a separate thumbnail component, you still need to define an attr_reader and an initialiser on that component.
Sometimes my example code can be overly simplistic for the sake of creating short videos, and to help take me a little less time to produce them.
I do also agree with you on minimising third party libraries/gems, but would urge you to take a look at the dry-rb libraries, they are all very small and well put together and maintained.
Hope that helps explain the purpose a little better :)
@@rapid-ruby Thanks for clearing up the messaging. Keep up the good work.
@@tombranson9341 Thanks!