HTMX-Powered Dynamic Content Blocks in Bricks Builder: A Proposal

Feature Requests / Improvements
1

Hello Bricks Community,

I recently initiated a discussion on the Cwicly forum, presenting the hypermedia concept that has captured my attention: the integration of HTMX for dynamic content rendering. This interest was sparked by an intriguing example where selecting a car model on a website could dynamically update server-side variables and conditionally render content. This idea seems particularly promising for enhancing Bricks Builder, allowing for the creation of dynamic content on WordPress sites with unprecedented ease and flexibility.

Concept: Enhancing Interactivity with HTMX-Enabled Dynamic Blocks

Imagine the possibilities if we could seamlessly incorporate HTMX within Bricks Builder. This would open the door to instant content updates triggered by user interactions, such as selections from dropdown menus or clicks on links. Picture a scenario where choosing a car model sends an HTMX request to the server to update a variable, which in turn dictates the content to be dynamically displayed on the webpage. Such an approach would not only make web pages more interactive but also ensure they remain engaging, with content that adapts in real time to user inputs, all the while maintaining the integrity and security of server-side processing. To get a better understanding of HTMX’s potential, I recommend exploring the HTMX examples page.

To bring this vision to life within Bricks Builder, we could consider the following implementation strategy:

  1. Declaration of HTMX-Enabled Blocks:

    • Introduce a designation for blocks, or attributes within existing blocks, to be marked as “HTMX-enabled.” This would earmark certain sections or elements for dynamic content updates.
    • Assign a unique ID to each HTMX-enabled block, serving as a reference for HTMX requests and interactions.

  2. Optimization for Initial Page Loading:

    • HTMX-enabled blocks would initially be omitted, ensuring the page loads quickly and efficiently by deferring the rendering of dynamic content until it’s needed.

  3. Mechanisms for Content Loading:

    • Content could be dynamically loaded in two ways:
      a. Lazy Loading: Content within HTMX-enabled blocks could be fetched and rendered as they become relevant, either by entering the viewport or through specific triggers, optimizing performance.
      b. Direct User Requests: User actions, facilitated by HTMX attributes on UI elements, could initiate direct requests to the server, specifying the content to be dynamically loaded based on the unique ID and loaded into the targeted block (both simple HTML attributes).

  4. Server-Side Processing:

    • The server would be configured to recognize and respond to requests for HTMX-enabled blocks, processing and returning only the requested content partial for seamless integration into the page.

  5. Ensuring Security and Efficiency:

    • This implementation would leverage the security of server-side processing while enhancing the user experience through efficient, on-demand content loading. It would also offer a simple way to build complex application logic visually as all HTMX requested partials are rendered like a regular bricks page and can contain loops, forms and display conditions.

Real-World Application:

Consider a car dealership website built with Bricks Builder, where selecting a car model could instantly update sections such as features, reviews, and pricing. This dynamic content, wrapped in HTMX-enabled Bricks blocks, would transform user interactions into an immersive, personalized web experience, significantly elevating user engagement and satisfaction.

This approach promises to revolutionize the way we build and interact with websites, making them more responsive and tailored to individual users’ actions without the need for full page reloads, thereby offering a smoother and more engaging user journey.

I’m eager to engage in a dialogue about the practicality of this concept, potential challenges we might face, and any innovative ideas to further refine this integration within Bricks projects. While this might seem more suited to backend development at first glance, I am convinced that there’s a unique opportunity here to harness such dynamic functionalities within a visual builder framework.

I look forward to your feedback and additional insights on this proposal.

Warm regards,
Max

For a deeper dive into this concept, take a look at the HTMX Value Select example.

Further Exploration of HTMX

7 Likes
2

What is hypermedia and why HTMLX is a great idea …

Meanwhile over in Gutenberg Land

A similar feature is being planned for the WordPress Block Builder, however, HTMX still seems to be more user-friendly and easier to understand … but this will have similar traits and be for an wider audience. The exact implementation details of the Interactivity API are yet to be seen.

For more information, you can check out the following links:

3 Likes
3

I’ve been fiddling with htmx and go and it is brilliant.

2 Likes
4

Yeah and now imagine integrating HTMX with Bricks Builder (instead of go), allowing you to visually construct and customize your HTML fragments. This would enable a nice intuitive and efficient way to design the partials that HTMX dynamically returns and updates on the web page, streamlining the development process and enhancing user experience through seamless content updates with all the feature richness you get in the builder (including potentially all plugins).

2 Likes
5

image

I will think about this after I mature this theme well enough.

and I made this too btw :slight_smile:

it is very easy to implement htmx transitions in bricks :slight_smile:

3 Likes
6

Hey Community,
Hey @sinanisler,

I like the seamless page transitions you’ve achieved in Bricks using HTMX, with the menu navigation being fluid and the content fade effects. This is the fundamental principles of hypermedia.

The proposal I’ve outlined could streamline this process even further. By leveraging the inherent capabilities of Bricks Builder and HTMX, we can sidestep complexities like redundant or missing CSS inclusion. Our approach ensures that all necessary styles are already loaded in the head of the HTML document, as the system intelligently filters out HTMX-tagged partials on the same page. This not only simplifies the development process but also optimizes loading times, ensuring a more efficient and responsive interaction for the user across the website.

Considering our ongoing discussions about improving Bricks Builder with HTMX, I’d like to explore the finer points of implementing this. The key idea is to blend dynamic content loading smoothly with the existing features and design possibilities of Bricks Builder.

The approach I envision would involve extending the existing bricks elements to incorporate HTMX functionalities at the section, block, and div levels. These elements could be augmented with new settings, or we introduce a wrapper element like a HTMX container. The crux of this integration is that these HTMX-aware containers (either wrapper or earmarked) are treated like any regular content by Bricks Builder, thereby ensuring consistency in design and behavior.

image
image4769Ă—3338 501 KB

This depicts the page in the builder and then renders (with omitted HTMX sections and blocks). The blocks and sections can then be requested later by lazy loading or interaction. The beauty is they are re-rendered (in an inverse output) and still can react to form data or other things changing between request.

Here’s how I anticipate it working:

  1. Earmarking Dynamic Containers: We would introduce an option to mark sections, blocks, or divs as “HTMX-enabled”. This would signal to the Bricks Builder that these elements are dynamic and should be handled differently during the page rendering process.
  2. Identification through Unique IDs: Each HTMX container would be assigned a unique ID, which serves as an anchor for HTMX requests. This ID is crucial for fetching content dynamically and for server-side processing of HTMX requests.
  3. Selective Rendering: While Bricks would generate CSS and handle all usual preprocessing for these containers, the actual HTML for these earmarked sections would be omitted from the initial page load. This ensures that the page remains lightweight and loads swiftly.
  4. Server-Side Handling of Partial Rendering: When an HTMX request is made, the server would treat it as a regular page render but only return the HTML fragment associated with the unique ID. This inverse rendering ensures that only the necessary content is delivered, optimizing performance and load times.

Using Bricks Builder, we can tap into all its cool design features and add some interactive magic with HTMX. I think this way, we keep things user-friendly without making the backend too tricky.

I’d love to chat with the backend pros here to make this even better. Let’s figure out the smartest way to pull this off in our projects.

2 Likes
7

Side note: While not as optimized for efficiency, hx-select enables the utilization of only a specific segment of the returned HTML (based on selector) from the response, effectively acting as pseudo partials. This means it retrieves the entire page, including all state updates and changes, and then isolates only the elements defined by the selector. Therefore, the approach mentioned previously should be feasible. However, I believe that server-side filtering, using a partial ID, would likely be more bandwidth-efficient. Nonetheless, for a Proof-of-Concept, this difference in efficiency might be considered minimal.

8

right now all you said is possible but of course they are manual by hand :smiley:

we have to add the attributes and stuff one by one. I mean it is possible to automate some of it like query loop with dynamic tags + attributes still will change case to case.

not sure how all of this could be automated seemlesly. :thinking:

but I will for sure will use bricks+htmx on client project this year. :blush:

2 Likes
9

Thats right. Its effortless to integrate… just making the partials idea seamless would be the goal.

I think we need a render function that can render based on a setting. Either, based on a wrapper Element (with nested elements) or on a setting that extends the existing elements (my favorite). The moment we have that we can render by omitting or only rendering a partial.

10

@MaxZieb @sinanisler This thread is crazy in the best possible way! I’ve been playing around with HTMX using other server-side frameworks. I never would have thought about combining it with WordPress and Bricks. Thanks for putting forth some really interesting ideas. I look forward to watching the progress evolve from here.

11
1 Like
12

I am still thinking about this how should I write htmx element for bricks but I am still not sure how to implement it. only dom based give the full nestable htmlx attrs…etc or do I need some kind of logic flow for any possible wp template hierarchy possibilities… I didnt started drawing anything yet.

rightnow I am developing the gsap element for simple scroll trigger stuff (and many other things) after that if I find a good abstraction logic I may implement the htmx element too.

any proposals are welcome discussions tab open on git.

2 Likes