I appreciate that you went the extra mile by showing how a generic enough controller can be used for various use cases.
People coming a from traditional JS background tend to make very specific Stimulus controllers, but when you make them a bit more abstract and modular they become more usable and easier to maintain.
Glad you found the article useful!
That's because they can't handle it. I've seen a number of systems with 200-300+ tables that grew over 10+ years with 20+ developers working on it. This wasn't a Rails app btw, it's using a framework with much less opinions in a different language where an ORM wasn't being used.
You end up with `id` in some tables or `tablename_id` such as `post_id` as the primary key. It makes interacting with the app feel like a surprise depending on what section of the code base you're working on.
For those new to Rails, Stimulus (https://stimulus.hotwired.dev/) is a way to sprinkle frontend javascript code into your Rails views.
I held off using Stimulus in my Rails apps for a long time because I didn't understand it — the data= attributes looked weird, and the connection between my Rails views and Stimulus javascript controllers was confusing.
So I decided to write the guide I wish I had when I was learning Stimulus.
Hope you enjoy it! I'm happy to answer any questions, feel free to ask any.
Thanks, Harrison