Self-Refreshing Hotwire Components in Rails

Host

Welcome back to another episode of Boring Rails, where we skip the bullshit and ship fast! I’m your host, and today we’re diving into a really exciting topic: hotwire components that refresh themselves. With us today is Jesper Christiansen, a long-time fan of all things Ruby on Rails. Jesper, thanks for joining us!

Expert

Thanks for having me! I’m really excited to talk about this pattern that makes working with Hotwire apps so much easier.

Host

Absolutely! So, let’s start from the beginning. What exactly are hotwire components and why is it important for them to refresh themselves?

Expert

Great question! Hotwire is a framework that allows developers to create modern web applications with minimal JavaScript. When we talk about components that refresh themselves, we mean components that can update their UI based on actions happening in the backend without needing to reload the entire page.

Host

Sounds powerful! Can you give us an example of where this might be used?

Expert

Sure! Imagine you have a user card component that displays a user’s information and a button to send them an introduction email. When the button is clicked, we want the UI to show that the email is in progress and then update to reflect that it has been sent.

Host

That makes sense. But I’ve heard you mention that there are challenges with using turbo_streams out of the box. What are those?

Expert

Yes, exactly. Turbo streams typically rely on partials, which can become quite messy. You end up needing to manage a lot of identifiers and data between the components, which can lead to confusion, especially in larger codebases.

Host

So, what’s your proposed solution to this mess?

Expert

I recommend creating a component for the view along with its own logic. Instead of using partials, you can use turbo_stream.replace and pass the component object directly. This encapsulates all the implementation details, such as DOM IDs and ActionCable channels, into the component itself.

Host

That sounds much cleaner! How does that improve the coding experience?

Expert

It streamlines everything. For instance, when you need to update the UI, you are not worried about matching identifiers across different files. You just communicate with the component directly, reducing the risk of breaking things.

Host

I love that! What about the issue of maintaining unique identifiers? You mentioned a workaround involving helper methods?

Expert

Right! A common approach is to define a helper method to get the unique ID for components. But even better is to fully encapsulate that logic within the component itself, so if you ever change how the component works, you don’t need to hunt through your codebase to make updates.

Host

This sounds like a game changer for developers using Hotwire! In closing, what’s your main takeaway for our listeners?

Expert

Focus on using ViewComponents or similar structures to manage your UI components. They help keep your code clean, maintainable, and make the development experience much smoother.

Host

Thanks so much for sharing your insights, Jesper! I think our listeners are going to find this incredibly useful.

Expert

Thank you! I really enjoyed discussing this with you.

Host

And that's it for today's episode of Boring Rails! Don’t forget to subscribe for more tips on shipping fast and staying ahead in the Ruby on Rails community!