The problem is, that sometimes, there's an overhead of the extra work to support the Ajax responders.
If you stop treating Ajax as something special, you'll find it's barely any extra work on the server side.
Book nowModern Universal React with Next.js
Stop worrying about configuration, and complex codebases: Next.js makes SSR with React easy. Book your masterclass today.
Think of it like this: the Ajax response is the content that drives the page (or parts of it), only without the HTML.
On the server side, you've got to collection different datasets to build up the page. The Ajax responders should go through exactly the same route to get that data.
So here's how you write your Ajax responders compared to how you write the server side code:
- The Ajax call should use the same functions.
- The Ajax call should use the same controller.
- The Ajax call should use the same url.
- The Ajax call could use the same query string.
Ajax requests via popular libraries such as YUI, jQuery, Prototype, etc, all include a header that indicates the request is via Ajax:
So you can control the logic flow in the controller by checking if this header is present.
For a practical example, I created (some time ago) a user registration page that includes validation. If the fields are valid, then the registration happen. If any of the fields aren't valid, it returns the page and the error notices.
It reuses the validation module and the same controller as much as possible.