I’ve been inspired by a simple yet powerful HTMX example, where selecting a car model updates a server-side variable and conditionally displays content based on that selection. This got me thinking about leveraging HTMX within Cwicly blocks for dynamic content rendering on WordPress sites.
Proposal: Dynamic Content Blocks Based on User Selections
Envision Cwicly enabling HTMX interactions directly from user interface elements, such as select fields or links. When a user makes a selection, for instance, choosing a car model, an HTMX request is sent to update a server-side variable corresponding to this choice. The server then determines which content to display within specific HTMX target containers on the page, dynamically rendering content inside a previously omitted HTMX endpoint block. This method allows for the creation of highly interactive pages with content that adapts in real-time to user inputs, leveraging both visual construction and server-side security. For more information, visit the HTMX examples page.
A dealership site where selecting a car model dynamically updates the available features section, customer reviews, and even pricing options without refreshing the page. Each section would be wrapped in HTMX-enabled Cwicly blocks with conditions checking the server-side variable.
This approach could significantly enhance user engagement by providing immediate feedback and tailored content, leading to a more personalized browsing experience.
I’m eager to hear your thoughts, potential challenges, and any additional ideas on how we can implement this within Cwicly projects. Usually, a thing for a backend-driven ecosystem, but just maybe there is some merit to such an idea in a page builder.
Very interesting… And very relevant in the context of TW integration
I admit that this kind of HTML extensions look very appealing, be it for styling or interaction purpose. I really like that everything can be done through HTML, thus in the same markup, without having to dig into the project file hierarchy to find CSS or JS definitions.
Yeah, totally, because we get an extended HTML set that has the base idea of hypermedia at its core. Also, we get back control to PHP and the HTML it produces. We are very fluent with that. So I would see it Cwicly and in a WordPress ecosystem as something that returns an HTML partial. That partial could be either in page builder land a section that is omitted on the first render, but can be requested through a certain partial URL, or lazy loaded, or there are so many nice things you can do with HTMLX. And the second way is you can just create endpoints yourself, run PHP from there, do whatever you want. So it’s very easy for developers, because they just have to know PHP and HTML, that’s all. And then they can use the entire WordPress API on the backend without all the security overhead from AJAX connections.
A comparable concept is on its way to the core framework, yet HTMX appears to be more accessible and understandable for a broader audience. The specifics of how the Interactivity API will be implemented remain to be observed.