Click Me! But what if I want the response to populate the content of another HTML element? E.g. if I wanted an accordion-style FAQ where when you click on the question (or on a plus-sign before the question), the div below the question is loaded with the answer from the server via AJAX.
Intercooler.js – Making AJAX as easy as anchor tags
131–140 of 156 posts
Re: Intercooler.js – Making AJAX as easy as anchor tags
#132Earlier quoted context omitted.
What's wrong with "boilerplate with code-generator"? For smaller sites, the number of parts often isn't huge, so boilerplate isn't a big deal.
I probably don't understand what you mean. Generating code in a Turing-complete language use a program written in another Turing-complete language can get messy.
I mean scaffolding.
Just because something is turing complete doesn't mean that a generator has to be able to generate anything possible.
If boilerplate is an issue, scaffolding / code generators can be a quick fix.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#133This has been reposted so many times by the author and by others that I can't help but finally ask. What's the point? This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Why not just use REST + JSON? It would take no more than five minutes to set up client-side rendering, and you could even make it attribute-based like this with barely any more effort. Is it…
> Is it really not worth spending the extra five minutes it takes to set things up in a way that is reusable and standard?
HTML is standard. Even more importantly it has rich and standard semantics. Your homebrew protocol based on JSON is not and does not. You write an interpreter for it every single time without even realizing it.
The thing you cooked up in 10 minutes does not follow the principles of progressive enhancement. This immediately closes up lots of doors.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#134Earlier quoted context omitted.
Never so that funny interpretation of REST(ish) architecture. That R in the name is a dead giveaway that you not necessarily will get exactly what you put there. I may put json and request xml, what are you gonna do, stab me?
Well, if the server understands the payload, it can return it in a different representation. There is nothing wrong with that. But a GET should always return the original payload when requested with the Accept header that matches the original Content-Type of the PUT request. edit: Better is to use a PUT for different representations: PUT /foo Content-Type: application/json {"foo":""} PUT /foo Content-Type: text/xml
Seems to be no reason why GET should return the original payload. No client should even expect that as the resource could easily have been changed by another client in between requests.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#135This has been reposted so many times by the author and by others that I can't help but finally ask. What's the point? This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Why not just use REST + JSON? It would take no more than five minutes to set up client-side rendering, and you could even make it attribute-based like this with barely any more effort. Is it…
> All I see is piles of legacy code being generated where it hurts most - in the backend.
No problem. It's just views. If the need comes to make it general, and output JSON from everywhere, you just write another set of views. They are discardable. (And you'll probably need different URLs for the JSON anyway, so you'll probably keep both sets.)
Re: Intercooler.js – Making AJAX as easy as anchor tags
#136Earlier quoted context omitted.
I probably don't understand what you mean. Generating code in a Turing-complete language use a program written in another Turing-complete language can get messy.
I mean scaffolding. Just because something is turing complete doesn't mean that a generator has to be able to generate anything possible. If boilerplate is an issue, scaffolding / code generators can be a quick fix.
Can I have intercooler do that scaffolding for me?
Re: Intercooler.js – Making AJAX as easy as anchor tags
#137Earlier quoted context omitted.
> This has been reposted so many times by the author and by others The author did post a story about intercooler four times in the last 3 years. Where is the problem? > This would lead to your API being comprised of blocks of HTML which are probably only useable for one product. Whats the problem with that if their is no need to reuse the API, or if there is no API at all, just a bunch of uncool php scripts? > It wou…
The author did post a story about intercooler four times in the last 3 years. Where is the problem? Look at the author's comment history, rather than story history. He has a reputation of plugging intercooler in every discussion related to JS. Not that I mind; but most of the "reposts" that GP is talking about are comments, not actual stories.
I've seen he doing it before. The OP pushes Intercooler.js in every place.
Anyway, I'd like to thank him for it. It was because of this pushing that I learned about the lib, and I'm very glad for that.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#138Main intercooler.js author here, glad to answer any questions. Happy to see people are enjoying it!
Is there a typical pattern for progressive enhancement, going from the non-js case to the intercooler case when js is enabled?
Not yet, beyond the somewhat ugly duplicating of anchor tag hrefs and form actions and then checking for the 'ic-request' variable on requestsion.
It's on the list.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#139How many times will something like this be attempted? It ends up being awful for debugging. Works great when there are no bugs of course.
I don't find it particularly difficult to debug, it's simple enough to see what's happening with the requests and responses, but there are definitely situations where it can be hard to understand what's going wrong.
I've tried to log the most obvious problems to console to make it easier to understand what's going on.
Re: Intercooler.js – Making AJAX as easy as anchor tags
#140Earlier quoted context omitted.
I agree. There are instances where I think returning HTML instead of JSON works (think of Rails Actioncable or Phoenix Channels), but I have a hard time conceptually understanding what problem is solved by this library. Thinking of almost all of the full stack, I feel like you could have more flexibility with something like Rails with Angular on the front-end. You can set up a Rails controller to return JSON or HTML…
And that's how the monstrosities are born.
I work primarily with a legacy, enterprise PHP application and it is a monstrosity (large number of classes, breaking framework changes, deprecated front-end libraries, very old MVC patterns, heavily imperative).
There are elements that Rails (predictable routing, simplified MVC, templating rendering, and general ease of set up and deployment) and Angular (flexibility, directives, safe templates, state based routing, imperative but can be functional with filters) provide the feature set that I have described above (aside from the routing object idea for generating server and client side routing).
The underlying technologies are not important; Node already has isomorphic javascript. I think Phoenix might be on track to remove the need for a heavy use of javascript for creating a single page application by simply using channels.
However, I cannot speak on Node and Phoenix because I lack the experience with these languages to comment. I do have experience with Rails and Angular to generate an example of how I would like a full stack, AJAX heavy application to work.