Implement CSS selection

[0x546F6D]

Not sure if it is an interesting idea but instead of(/on top of) directives, what about using the attribute of an element to also select it with zts?
Looking at your zig-zag-zoe example, several directives only include 1 element:

.clickable
<div class="{[class]s} player{[player]}" hx-post="/square/{[x]}/{[y]}" hx-trigger="click throttle:1s"
    hx-headers='js:{{"x-player": getPlayer()}}'>
    {[player]}
</div>

which could also be selected with, for example, a data-zts attribute:

<div data-zts="clickable" class="{[class]s} player{[player]}" hx-post="/square/{[x]}/{[y]}" hx-trigger="click throttle:1s"
    hx-headers='js:{{"x-player": getPlayer()}}'>
    {[player]}
</div>

Of course, using directives, you can include more than one element:

.winner-victory
<span class="green">Victory !</span>
<div>
    Take off every ZIG
    <p class="yellow">For great justice</p>
</div>
<script>sing(victoryAudio, 1)</script>

But that could maybe also be solved using something like an "/inner" option?

<div data-zts="winner-victory/inner">
    <span class="green">Victory !</span>
    <div>
        Take off every ZIG
        <p class="yellow">For great justice</p>
    </div>
    <script>sing(victoryAudio, 1)</script>
</div>

The idea behind it is pretty selfish, it's for me to integrate zts and datastar more easily :)
for example, I would modify this code:

<div class="{[class]s}">
    <div class="grid-container" style="--Cols:{[columns]}">
        .square
        <div class="{[class]s} player{[player]}">
            {[player]}
        </div>

        .clickable
        <div class="{[class]s} player{[player]}" hx-post="/square/{[x]}/{[y]}" hx-trigger="click throttle:1s"
            hx-headers='js:{{"x-player": getPlayer()}}'>
            {[player]}
        </div>

        .end
    </div>
</div>

into:

<div data-zts="board" class="{[class]s}">
    <div id="board" class="grid-container" style="--Cols:{[columns]}"></div>
</div>

<div data-zts="square" class="{[class]s} player{[player]}">
    {[player]}
</div>

<div data-zts="clickable"
    class="{[class]s} player{[player]}"
    hx-post="/square/{[x]}/{[y]}" hx-trigger="click throttle:1s"
    hx-headers='js:{{"x-player": getPlayer()}}'>
    {[player]}
</div>

Datastar uses sse, which means that we can send as many html fragments as we want for a single GET http request. Datastar also gives several DOM merging strategies, such as idiomorph/inner/outer/prepend/append/etc..
So the logic would be to answer the http request with the "board" element 1st:

event: datastar-merge-fragments
data: fragments <div data-zts="board"...

and then send as many "square"/"clickable" elements as necessary to append to this #board elements:

event: datastar-merge-fragments
data: selector #board
data: mergeMode append
data: fragments <div data-zts="square"...
data: fragments <div data-zts="clickable"...
data: fragments ...

• "data: selector #board" Selects the target element of the merge process using a CSS selector.
• "data: mergeMode append" Appends the fragments to the target’s children.

... I just realised that I could get the same result with zts current implementation 🤦 :

.board
<div class="{[class]s}">
    <div id="board" class="grid-container" style="--Cols:{[columns]}"></div>
</div>

.square
<div class="{[class]s} player{[player]}">
    {[player]}
</div>

.clickable
<div class="{[class]s} player{[player]}"
    hx-post="/square/{[x]}/{[y]}" hx-trigger="click throttle:1s"
    hx-headers='js:{{"x-player": getPlayer()}}'>
    {[player]}
</div>

Anyway, I'll just leave this issue as food for though, maybe using a data-attribute instead of a directive would still make the template.html cleaner and easier to maintain? Not sure 🤷

[0x546F6D]

I just changed the title to something that might be more interesting: implementing CSS selection.
The idea would be that the selection passed to zts.s() wouldn't be limited to looking for a specific "data-zts" attribute but also to some common CSS selector.
This way, you could select elements by id using for example #board, bu also by tag, using for example .main, .nav, etc..
An option could also be implemented in zts.s(.., ?enum{outer, inner}), to select the element's inner or outer HTML, with outer being the default.
I understand that it's a lot of work to implement such a functionality, and not what zts was meant to do.

[zigster64]

Hey

Yeah I think I see what you are wanting to do there with the datastar integration

Let’s have a play with that, and see what we can do. Because zts is “designed” to leverage the power in std print(), all the tricky bits need to be comptime, and return a comptime known string from the template.

That sounds simple enough, but quickly gets into a knot in practice, since you can’t have the addresses of data at comptime, so in turn you can’t have offsets into a string at comptime, or dynamically search the data and return a slice.

That’s ok though.. what we can probably do is have a runtime helper function as part of zts that does tag lookups from data inside those comptime known sections or something like that.

I’m probably not explaining that well - might be easier to just write it than attempt to explain it :)

I think - let’s build some nice example / test cases for what we want here, and work backwards from there to make them happen

[0x546F6D]

As much as I can spend hours playing with zig or rust, I really have troubles finding the motivation to dive deep enough into html or css. So when I need an html/css element, I often just look online for a suitable template.
Let's say that I want my app to behave like an SPA and display a 404 page in an overlay instead of redirecting the user to the 404 page.

• 1st, I check online how to do an overlay, get the .css, sprinkle a bit of datastar on top of it and add this line to my index.html:

<div id="overlay" data-signals="{'_overlay_display':false}" data-show="$_overlay_display"></div>

The data-* stuff informs datastar to create a local boolean signal called _overlay_display, initialize it to false and show that div when this signal is true.

• Then I look for a 404 page that looks descent, grab the html/css, makes some minor changes if necessary, sprinkle some datastar and some zts on top of it, to finally get this notfound.html file:

<!DOCTYPE html>
...
<body>
  <div id="err_ctn" class="error-container">
    <h1> 404 </h1>
    <p>
      {[req_url_path]s} not found..
    </p>
    <a data-on-click="$_overlay_display=false"> OK </a>
  </div>
</body>
...

{[req_url_path]s} is for zig. data-on-* tells datastar to do stuffs on events; here it says to change the signal _overlay_display back to false on a click, and hence to hide the overlay div.

Finally, the notfound() function for my httpz Handler could be something like that:

pub fn notFound(self: *Handler, req: *httpz.Request, res: *httpz.Response) !void {
    const tmpl = @embedFile("html/notfound.html");
    const html_fragment: []const u8 = zts.print(tmpl, "#err_ctn", .{
        .req_url_path = req.url.path,
    });

    // do some datastar stuffs:
    var sse = try datastar.ServerSentEventGenerator.init(res);
    try sse.mergeFragments(html_fragment, .{ .selector = "#overlay", .merge_mode = .inner });
    try sse.mergeSignals("{_overlay_display: true}", .{});
}

Ask zts to get me the div with the id="err_ctn" and format it with the request url path. Then tell datastar to merge what zts gave me into the inner html of the overlay div, and show that overlay.

By the way, I am using that overlay for different things, and not only to display a 404 message, so its inner html is changed accordingly.

I can currently manage to do something similar using zts.s() on such a file:

  .error_container
  <div id="err_ctn" class="error-container">
    <h1> 404 </h1>
    <p>
      {[req_url_path]s} not found..
    </p>
    <a data-on-click="$_overlay_display=false"> OK </a>
  </div>

The only issue with this current implementation is when working with minified files. While working directly with css selector it probably would not matter if the template.html got minified or not.

[0x546F6D]

btw, this part of the zig code is not from me, but from the official zig sdk of datastar for httpz:

var sse = try datastar.ServerSentEventGenerator.init(res);
try sse.mergeFragments(html_fragment, .{ .selector = "#overlay", .merge_mode = .inner });
try sse.mergeSignals("{_overlay_display: true}", .{});

I scratched whatever I had come up with to deal with datastar, when those people more qualified than me released the official sdk for zig :)

[zigster64]

Cheers - I have a bit of reading to do there

I looked at data-star when it first started up as a htmx alternative a while ago. Nice ppl.

Holy moly, they have made some progress ! And an official zig sdk too - impressive!

Best way to attack this is, I think, write another little toy game or something that exploits data-star, and I’ll use a modified zts to try and remove the pain points around these fragment references

I will need to do that anyway to learn datastar properly first (it’s how I learn best)

I can see now what you mean about being able to use zts already by splitting up the template into its fragments, but it’s not as easy to read as a continuous block of html

Agree with you too that it’s really hard to be motivated about getting excellent at html/css at all, because it just feels so arbitrary and wrong :)

If we do a good enough job of this, might try and add the whole template processing as a PR to add to the datastar zig sdk, if there is interest. See how we go first

[0x546F6D]

zig-0.14.0 release notes / language changes - Labeled Switch made me think at the switch(mode)/switch (c) of pub fn s() right away.