HTMX podría ser un gran avance para WordPress.

Por:


translate this content to spanish and keep HTML tags

element which will serve as the root of our React application where the rest of the UI will be rendered.
const rootEl = document.getElementById("books-app");
const root = ReactDOM.createRoot(rootEl);
root.render();

function BooksApp() {
  return (
    

...

); }

So how do we list the books that are stored in the database? The code to do that is on the server, so we need a way to call it and get its result.

To do that, we can expose a JSON API from the server. The React app can then make a request at our API’s URL, receive the books in JSON format, then render the list. For this example, let’s assume that we’ve added an endpoint to the WordPress REST API:

GET 

{
  "books": [
    {
      "id": 15,
      "title": "Mistborn",
      "author": "Brandon Sanderson",
    },
    {
      "id": 44,
      "title": "The Hobbit",
      "author": "J. R. R. Tolkien",
    },
  ]
}

We can then write a React component that fetches the books and renders them as a list:

function BookList() {
  const [books, setBooks] = useState([]);
  const [isLoading, setIsLoading] = useState(true);
  const [error, setError] = useState(null);

  useEffect(
    function () {
      setIsLoading(true);
      fetch("https://my-wp-site.com/wp-json/books")
        .then((res) => res.json())
        .then((data) => setBooks(data.books))
        .else((error) => setError(error))
        .finally(() => setIsLoading(false));
    },
    [setBooks, setIsLoading],
  );

  if (isLoading) {
    return 

Loading...

; } if (error) { return

Error: {error}

; } return ( ); }

But this solution is too naive, and yields a rough user experience. It does not cater for state changes after the component un-mounts, caching the response, retrying failed queries, or prevent stale state from overwriting more recent state. In fact, the way we are using fetch() in a React effect is generally discouraged.

In many ways, this can be worse than a traditional MPA. So to do this correctly, we’ll need to implement a few more things in our client. Or, more realistically, use 3rd party packages.

But all of this is starting to feel like a disproportionate amount of effort just to render a list of books. Do we really need to create a JavaScript app and a JSON API to create a smooth user experience?

Let’s contrast this with an MPA, where rendering the list of books can be accomplished in just a few lines of PHP code, without any dependencies:


    
    

But of course, this is not a fair comparison. This list of books is just static HTML; it is not reactive to state changes or user input.

If we want to have a SPA-like experience while also rendering the HTML on the server, where our code has immediate access to the database, we’ll need to find a way to have the server-rendered HTML find its way to the browser and replace the previous list of books. But achieving this without any JavaScript code is currently impossible, so we’d have to bite the bullet and use JavaScript anyway.

But we don’t need to write it ourselves.

Introducing HTMX

HTMX is a small JavaScript library that primarily does one thing: allow HTML to request new HTML from the server. It does this using new attributes, which allow us to tell HTMX where to get the new HTML from, what to swap it out with, and what triggers the swapping. It acts as a bridge between our HTML server and the page in the browser.

This is a vastly different way of thinking about SPAs, since we are not building a client JavaScript application to update the current page. Instead, we simply add some HTML attributes to tell HTMX how we want the page to change when certain events happen.

Even without HTMX, you can already change what is shown on the screen using just HTML, albeit in a very limited way. You’re already familiar with this HTML feature: the humble link element.

View books

A link element gives the browser all of the information that is necessary is carry out navigation. When it is clicked, the browser takes the href from the element, makes a request at that URL, downloads the response and, assuming that it contained HTML, replaces the contents of the page with the new HTML.

The element is another example of how HTML can request new HTML.

This time, the browser collects the values from all the inputs in the form, send them to the server, downloads the response, and renders it on the screen.

Why should only and be able to make HTTP requests? Why should you only be able to replace the entire screen?

From HTMX’s GitHub readme

Well, HTMX changes that.


  View books

With the HTMX hx-target attribute, clicking the link will now place the response from inside the element with the "books" ID. Of course, embedding a page inside of another is not the goal here. Our server does not need to response with the full page, and can instead just respond with an HTML fragment.

By exposing HTML fragments from our server and telling HTMX how, from where, and when to get those fragments, we can create a SPA-like web application without any JavaScript, where the server is in full control. In a sense, HTML has become our new JSON.

And all we need to do is load the HTMX script into our page: