How Ruby and Web Components Can Work Together

the best code is the code nobody writes

                January 5, 2022

            How Ruby and Web Components Can Work Together

Greetings of the new year to you!
To kick off 2022, I thought it might be helpful to share some real-world code examples of how I use Ruby "view components" together with web components (aka custom HTML elements + frontend behavior) to add dynamic, reactive, reusable UI to my apps. It's somewhat of a follow-up to my recent podcast episode all about the utility of employing a componentized view architecture in your projects.
From the article:
As DHH is often fond of saying, conceptual compression is a hallmark of Rails, and it’s a philosophy I very much subscribe to as well. I also like to collapse mental models. The fewer layers of “different stuff” living in parallel universes you have to boot up in your mind in order to accomplish simple tasks, the better.
What I love so much about the patterns [in the article] is that once you’ve wrapped your mind around what’s a Ruby component and what’s a web component, the two can operate as one conceptually-speaking across a wide variety of use cases.
Read “How Ruby and Web Components Can Work Together” and let me know what you think!
Going forward, I would also like to start linking to other online resources I've found helpful as a Rubyist and a software writer writ large, so let's begin by featuring A Mindset for Better Code by Matheus Richard. I have to admit, I often find a bone to pick with generalized “how to program good 🤓”  articles out there…often the advice is way too broad or too trendy to be of concrete use. But in this case, I found myself nodding along with each section. The first one, “More code == More work”, is a true gem. I wrote a longer treatise along these lines in 2015: the best code is the code nobody writes. The single biggest mistake I see other programmers make is writing too much code. Accomplishing XYZ resulted in 300 new lines of code. Do we really need to add 300 new lines of code to this project? Can we do it in 200 lines? How about 100? What if we refactor the X and Y parts out as a shared library within the codebase, so we only need 40 lines for the Z part?
Remember, our primary role as developers isn't to implement features. It's to steward the overall health, readability, maintainability, stability, and performance of a codebase. Implementing new features is actually orthogonal to those goals, so we need to understand and accept the "pain" of building something new, and therefore attempt to avoid harm as much as possible. And sometimes removing features is a worthy endeavor!
Which part of Matheus' article stood out to you? Let me know!
Cheers,
Jared

Don't miss what's next. Subscribe to Fullstack Ruby: