Add spark.isSparkRequest()

[khalwat]

It could be useful if there was a test:

{% if spark.isSparkRequest() %}

The reason this could be useful if you might want to have a template that is rendered on the initial page load via regular old Twig, similar to what @croxton did here: #10

But then you want that same template to be rendered via Spark/Datastar to dynamically update content.

With multi-root fragments, this all works fine... except that Spark rendered templates replace DOM elements based on ID (so they can be anywhere), but the regular Twig render just does them inline as you'd expect.

Here's a simple example. Let's say I have a fragment that renders a shopping cart. I want to {% include %} this template on the initial page load, and then dynamically update it via Spark/Datastar.

But I also want to have a little indicator in the upper-right corner of the page that has the number of items in my cart. So maybe my template looks like this:

<div id='shopping-cart'>
{# Display some cool stuff #}
</div>

<div id='cart-indicator'>
{# display the number of items in the cart #}
</div>

This works fine for the Spark/Datastar render, because it replaces the IDs in the DOM... but for the regular Twig render via {% included %} it's going to add another <div id='cart-indicator'> to the HTML, whereas I already have it in my header HTML where I want it to appear.

If I could do this:

<div id='shopping-cart'>
{# Display some cool stuff #}
</div>

{% if spark.isSparkRequest() %}
    <div id='cart-indicator'>
    {# display the number of items in the cart #}
    </div>
{% endif %}

...then it'd work perfectly, because I can re-use the same template/code for both the regular Twig render (where I don't want the <div id='cart-indicator'> rendered, and also for the Spark render, where I do want it rendered so it replaces the existing DOM element.

Obviously, this could also be achieved by splitting things into multiple templates and then selectively including them (which is exactly how I ended up solving this), but I feel like this case may come up in real-world scenarios, and it might be useful to have.

[croxton]

This would be helpful. I do think though that it is logical to make non-contiguous template partials (like a cart component that is separate from a results listing) as individual templates that you just include in the Spark template. Then you can also include them in your main template.

[bencroker]

This previously existed, but I removed it because I wanted to prevent people recreating Sprig components, which is essentially what you’re describing (templates that can exist in one of two states). Ultimately I want to avoid templates that look like this:

{% if spark.isSparkRequest() %}
    {% do spark.runAction('commerce/update-cart') %}
    {% do store.productCount(newProductCount) %}
    <div id='cart-indicator'>
    {# display the number of items in the cart #}
    </div>
{% endif %}

<div id='shopping-cart'>
{# Display some cool stuff #}
</div>

And instead, encourage people to use includes. So for your example:

{# Regular template. #}

{{ include('shopping-cart.twig') }}

{# Spark template. #}

{{ include('shopping-cart.twig') }}
{{ include('cart-indicator.twig') }}

[khalwat]

Yeah fair, that's what I ended up doing anyway... and I think I do like it this way better