Live data from Hacker News

Escaping the SPA rabbit hole with modern Rails

medium.com

131–137 of 137 posts

Re: Escaping the SPA rabbit hole with modern Rails

#131

Earlier quoted context omitted.

Dude, I've got work to do. You threw down a URL to a framework I don't know that is apparently similar to a framework I don't use and runs on Clojure, which I don't work in and none of my codebases run in. You did that with no context or even taking the time to explain why I would do such a thing. Objectively, there's nothing simple or expressive about the samples on their homepage. Their demos are simplistic (todo?!…

So just because you don't know German and I ask you to read some German text, you will say this looks super complex, even if it's a simple line saying "Good day!". Wow! Indeed our definitions of simple are different.

If you want to spend your days learning flavor of the minute web frameworks instead of actually building stuff, knock yourself out.

If you have anything more substantial to add to the conversation that actually relates to my original comment, I'll be here.

Re: Escaping the SPA rabbit hole with modern Rails

#132

I have nothing against SPAs for complex UI interactions. It's sort of like taking anti-biotics; there should be a moment of reflection when you should justify your true need, lest the cure be worse than the disease. Most developers of a certain age have come up when it's SPA by default, and can't truly defend why they need it. In this thread, there are several claims that it's impossible to write well-organized jQuer…

I generally agree with you, and as a front-ender-first that feels kind of uncomfortable to say. In my personal projects I do often go for a more conservative server-side first approach.

That said, it really feels like a chasm that quite often I choose to cross simply because it'll be easier down the line. I've been bitten more than once by server-side-first projects where going full-on client-side with the server-side as an API would've probably been better.

Whether it was because I needed a mobile app to communicate with said API, or whether the complexity ended up being more of a client-side thing, the result was often that I had to focus on the back-end as as API and go for the full complexity of a front-end app anyways.

I'm enough of a fan of my preferred back-end languages (Ruby, but mostly Elixir these days) that I try to find ways to keep the complexity there, but truthfully I often opt for going for the full complexity of a client-side JS/TS stack because I'm likely to end up needing it eventually anyways.

I've looked into things like Drab (https://github.com/grych/drab), but ultimately there are many reasons why 'going with the flow' seems like the better solution (even if just because it's so much easier to find JS devs than Elixir ones).

So far I'm not confident enough to make any sweeping statements, but from that lack of confidence I tend to opt for the 'safer' option, which seems to be the SPA route much of the time.

Re: Escaping the SPA rabbit hole with modern Rails

#133

Earlier quoted context omitted.

Poor choice of words on my part. For me, using Vue is worth for CRUD pages, trivial pages (pure HTML), etc. There's enough it gives me that even though I don't need it, I enjoy utilizing it in my workflow. What I was attempting to express is that I understand that for many, it doesn't give them anything in a basic CRUD page, and in fact can add a lot of complexity when you move away from built-ins with the backend fr…

Reading this, I am windering if the way I am approaching Vue is more complex than the way others do. Could you outline your approach to including Vue, to carrying state and changes from the rails api to the Vue-powered views, incl. initial state? Do you think you could share a code sample?

Hey Andrei! I don't have any clean code examples easily handy, but let me work on it for you. Shoot me an email (email is in my profile) and i'll share a gist with you.

The tl;dr is: [0] Use single file components [1] API endpoints return JSON. Nothing super fancy, just taking rails objects and return JSON. [2] What would have been a rails "view" corresponds with a route in my vue-router config. Nothing special there either. [3] A top level page (think /index or /item) [4] Each top level page calls a private endpoint, which is just its own natural route in the browser, and pulls down data it cares about through the JSON request. Each json object corresponds with an ES6 class which wraps any object specific logic (usually end up having to dupe some code between ruby + js here). [5] Each top level page is broken down into components (widgets, major sections of the page), for code clarity. [6] Anytime I find myself doing a for-each loop, I usually look to see if whatever the sub element is should be its own component. Usually the answer is yes (just depends on whether it has its own independent logic).

Everything is passed top down as an object, but I do break the "cardinal sin" of mutating props on the object. Traditionally, props should be immutable in Vue, which requires use of Vuex or an event bus to change state. I haven't had a case yet where this has been an issue, likely because each page transition reloads whatever data it needs, and the same object isn't being mutated by multiple components in a way that would cause debugging nightmares.

A few patterns I use to keep myself sane are wrapping objects with their own save methods (so I can just .save() ) an object and persist it back to the server.

I dunno, probably a lot more there, but I haven't given this any deep thought. Reach out, and let's exchange thoughts!

Re: Escaping the SPA rabbit hole with modern Rails

#134

Earlier quoted context omitted.

Having built some SPA's, I'd argue that at least those two things that you mentioned are the fault of whoever built bad SPA's, rather than issues with SPA's as a whole. It's possible to build an SPA that works well with the browser controls because modern browsers expose a lot of their functionality to JavaScript (like it or not). You can use tags for buttons and links in an SPA (and keep the link functionality) -- y…

Would you say Youtube works better now as it is fully SPA?

It does not. The SPA is so sluggish I’ve learned to just force a page refresh after clicking on anything because a full page load is actually faster than their bullshit SPA.

Re: Escaping the SPA rabbit hole with modern Rails

#135

Earlier quoted context omitted.

So just because you don't know German and I ask you to read some German text, you will say this looks super complex, even if it's a simple line saying "Good day!". Wow! Indeed our definitions of simple are different.

If you want to spend your days learning flavor of the minute web frameworks instead of actually building stuff, knock yourself out. If you have anything more substantial to add to the conversation that actually relates to my original comment, I'll be here.

Well, I've built stuff in reagent, enjoyed it immensely, and been paid for it. Enjoy your jquery! (and your ignorance!)

Re: Escaping the SPA rabbit hole with modern Rails

#136

Earlier quoted context omitted.

Reading this, I am windering if the way I am approaching Vue is more complex than the way others do. Could you outline your approach to including Vue, to carrying state and changes from the rails api to the Vue-powered views, incl. initial state? Do you think you could share a code sample?

Hey Andrei! I don't have any clean code examples easily handy, but let me work on it for you. Shoot me an email (email is in my profile) and i'll share a gist with you. The tl;dr is: [0] Use single file components [1] API endpoints return JSON. Nothing super fancy, just taking rails objects and return JSON. [2] What would have been a rails "view" corresponds with a route in my vue-router config. Nothing special there…

This is also exactly how I build Express APIs. One thing I'd add: when building an API, use Swagger (or something similar, but Swagger/OpenAPI have basically won, just do it). It makes API clients way, way easier to wrangle and removes a lot of the surprise from your application development. I sometimes forget that not everyone using React or Vue uses Swagger-based APIs that really do just kinda work, but they're a large part of why, for me, writing a fully-featured frontend is way better than entering Rails template hell or whatever. It's really, really easy: just a bit of state in the React component, kick off a fetch during componentWillMount, and drop a spinner that remains 'til you get an error or your data. If you're using TypeScript (and you should be), you'll have some pretty happy autocomplete based on the contents of your state and can just write code off the returned objects. Life's fun this way.

On the server side I use Express in Node and either `tsoa` or `inversify-express-utils`, while in Ruby I use my own Modern[0] library to autogenerate a Swagger document from the controllers I specify.

[0] - https://github.com/lukeautry/tsoa

[1] - https://github.com/inversify/inversify-express-utils

[2] - https://github.com/modern-project/modern-ruby

Re: Escaping the SPA rabbit hole with modern Rails

#137

Earlier quoted context omitted.

Hey Andrei! I don't have any clean code examples easily handy, but let me work on it for you. Shoot me an email (email is in my profile) and i'll share a gist with you. The tl;dr is: [0] Use single file components [1] API endpoints return JSON. Nothing super fancy, just taking rails objects and return JSON. [2] What would have been a rails "view" corresponds with a route in my vue-router config. Nothing special there…

This is also exactly how I build Express APIs. One thing I'd add: when building an API, use Swagger (or something similar, but Swagger/OpenAPI have basically won, just do it). It makes API clients way, way easier to wrangle and removes a lot of the surprise from your application development. I sometimes forget that not everyone using React or Vue uses Swagger-based APIs that really do just kinda work , but they're a…

Thanks Eropple!

I'd love to take a further look at your modern-ruby library. Hope you're able to continue to flesh out examples and documentation :)

Post reply on HN