Post

Gregory Brown [MOVED, SEE BIO]
@skillstopractice.com

I had a passing curiosity about this having done a lot of Vue that only coincidentally was deployed within my Rails apps as they worked entirely via an API. (And the cost in the past was webpacker which Rails 7 helped reduce a bit) Now looking at Hotwire instead. Not sure how this compares...

Gregory Brown [MOVED, SEE BIO]
@skillstopractice.com

... It wasn't super difficult to use Vue Router on the JS side and a wildcard catchall on the Rails side. The API based approach seemed like a feature, and if I am not going to have one, then perhaps Hotwire feels more natural? So I am curious about Inertia but not seeing right away the upside.

Gregory Brown [MOVED, SEE BIO]
@skillstopractice.com

Taking a minute to look at that, seems like the main idea is... 1) You build serializers on the Rails side to decide what data is available to your JS components. 2) The JS components then get access to this data as props. This isn't bad. But for my own case, it solves a problem I didn't have.

0 reposts1 like

Gregory Brown [MOVED, SEE BIO]
@skillstopractice.com

In my own Vue + Rails apps what I had done was made an ApplicationResource concern that generated the various standard API methods and then a ResourceClient object on the JS side that consumed the JSON from that. That gave me a real API without much code for each new resource. And it used as_json()

Gregory Brown [MOVED, SEE BIO]
@skillstopractice.com

I could see how someone wouldn't want to roll their own glue layer like that, and so in that case, maybe Inertia is indeed the tool if you actually *want* JS on the client side and you don't want to write Rails API code. But serializers look a heck of a lot like as_json calls. So... tradeoffs. 😀