Replies: 3 comments 4 replies
-
|
Thanks for trying it out, Will, and for your thoughts! I’ll try to respond to your questions below. Let me know if I miss anything or if anything needs more clarification.
That’s right. If
Yes, that’s correct.
Web components make custom elements possible, which are just markup that can be swapped into the DOM (either entirely or in part). How the web component behaves is going to be up to you, but this an area that I too have to do more experimenting. If you could help out with that, it would be much appreciated!
Most of what you describe in the latter section is related to Datastar, including:
Yes, this is temporary and Spark will eventually have an option for including Datastar automatically via a local file or manually.
Yes, of course! <div id="dynamic-content" data-on-load="{{ spark('_spark/dynamic-content') }}">
Placeholder content
</div> |
Beta Was this translation helpful? Give feedback.
-
|
Correction: data-store is a global singleton and can be accessed anywhere. |
Beta Was this translation helpful? Give feedback.
-
|
Also, check out this Spark demo of an inline table editing app at #2 (comment) |
Beta Was this translation helpful? Give feedback.
-
Definitely! I have a couple ideas but probably won't be able to test it out until later this week or this weekend.
Oh, good catch. It turned out to be the Safari Passwords extension for Chrome.
Thanks for mentioning that. I didn't read the plugins section because I assumed that was more along the lines of implementation (within Spark) but I see where that and a few things are helpful to know. I think this is where working with web components will be key and it'll be interesting to see how Datastar’s reactivity inside a web component’s attributes will function. admin-bar-component would be a good one to test this on, but also maybe some form input web components might be a good test. |
Beta Was this translation helpful? Give feedback.
-
|
For completeness, your “Hello, World!” example would read as follows, using the Spark 0.0.5 syntax. <div class="content" data-store='{ "textInput": "planet" }'>
<input type="text" placeholder="Type here!" data-model="textInput" />
<button id="main-button" data-on-click="$$post('{{ sparkUrl('_spark/main.twig') }}')">
Change it!
</button>
<div id="first">
This is the first thing.
</div>
<div id="second">
This is the second thing.
</div>
</div>
<div id="first">
Oh, hi, {{ store.textInput }}!
</div>
<div id="second">
And uh, hello, {{ currentUser.friendlyName ?? 'nobody...' }}?
</div> |
Beta Was this translation helpful? Give feedback.
-
|
Also, since you asked about how Datastar is loaded @wbrowar, there’s now a |
Beta Was this translation helpful? Give feedback.
-
|
FYI your “Hello, World!” code can (optionally) be simplified to the following using the Spark 0.0.6 syntax. <button id="main-button" data-on-click="{{ spark('_spark/main.twig') }}"> |
Beta Was this translation helpful? Give feedback.
-
Hi Ben, here are a few things I tried out and some initial thoughts to take from what you will.
Setting up Admin Bar
I started by seeing if I can replace the thing I currently use Blitz
includeDynamic()for on my personal site, which is to load Admin Bar at the top of the page. I also wanted to check that this works with a web component pulled in through Spark.I added the
divbelow and gave it an ID and passed through theidof the current page entry. Below that I added the same Twig code I use on my personal site to handle loading the JS and CSS needed for Admin Bar to render:Then in my templates folder I added a
fragmentand followed along the Datastar guide and your examples and added thedivwith the ID here. Inside of that is the code to get the current entry and then embed Admin Bar.{% fragment %} <div id="admin-bar-spark"> {% set entry = craft.entries.id(entryId).one() %} {{ adminBar({ entry: entry ?? null, useCss: false, useJs: false, }) }} </div> {% endfragment %}I have one issue with this setup in that I didn't want to add an extra
divhere, but it is currently required that you have an element with an ID based on how it's passed through Datastar. I wonder if you can find a way to put an ID on thefragmenttag or use<template>elements or something else to allow whatever you put into the fragment to get swapped out with thedivwith the ID on the front end without requiring a wrapper.My understanding is that the ID is required on the root element to match up the front-end ID and which fragment belongs in its place here, so I went into the Admin Bar source and hard coded an ID,
admin-bar-spark, to the render of Admin Bar (which is not something I want to add to Admin Bar itself for real, but I might add anidparam after this). Then I took out that wrapperdivin my fragment to see what would happen.{% fragment %} {% set entry = craft.entries.id(entryId).one() %} {{ adminBar({ entry: entry, useCss: false, useJs: false }) }} {% endfragment %}I was sort of surprised to see that this worked but I guess it had found the ID from the rendered
adminBar()Twig method and that's how Datastar matched it to the front-end page.I tested this when logged in and I get what I hope, the
<admin-bar>element and all of the buttons, including the Edit button for the entry ID I passed in. What I like is that just like Sprig and Blitz, it was rendered for my logged in user, which means permissions and are taken into account and it means that the Twig code in thefragmentshave the global context available to them (just not the context of the page the request is coming from).Here's what I got back when logged in:
When I logged out of my test site I noticed that the request from Spark comes back with the status code,
200, but that it doesn’t replace the placeholderdivon the front end and that's also a good thing in that that's how I hoped it would work. It's telling me that the fragment didn't have anything to send back so maybe at that point Datastar doesn’t bother to replace the placeholderdiv?Anyway, so far so good. My only question in this portion is how using a web component works when you're adding it via a Twig fragment.. When a web component is added to the DOM it fires callbacks and constructors and I wonder if that re-triggers every time
spark.post()is called and the Twig fragment is rendered. That would be a huge problem if your web component reset every time values changed.I'm happy to test the web component stuff out more if you'd like as I'm very curious on how well they play with Spark.
Hello, World!
After that I started diving into the examples and set up this on my front end. This example simply updates a couple of
divelements based on what you type into theinputfield:And this is in
_spark/main.twig:{% fragment %} <div id="first"> Oh, hi, {{ textInput }}! </div> {% endfragment %} {% fragment %} <div id="second"> And uh, hello, {{ currentUser.friendlyName ?? 'nobody...' }}? </div> {% endfragment %}Here's what I saw with this:
planetright away, which is good for returning to a form, pre-filling in data, or after some errors are triggered in validation. I'm curios to know how dealing with checkboxes and select fields would go but I didn't play around with them yet.data-storein a wrapper element seems fine for a smaller template, but I think it could get a little cumbersome if you're doing something like handling a lot of form inputs. I assume you could use Twig to make this a little easier (maybe put your default state in Twig up above in the block you’re rendering and then just reference that below or something? I guess this wouldn't be all that different from the way you put state in ascripttag in a Vue SFC.#firstelement I was testing to see what it looks like to triggerspark.post()and then to see what the return looked like. It works great when you hit the button, but I was thinking about how you can use any JS event here and addeddata-on-blur="{{ spark.post('_spark/main.twig') }}"to the input to do some validation in the Twig fragment as you’re filling out a form. So that’s very cool.control-id="ControlID-1". I would really prefer it if it wouldn’t add attributes that aren’t valid on regular HTML elements and that instead it would usedata-control-idhere. I'm not sure that you have control over that, but it was something that bothered me when I first saw it. From an HTML standpoint I don’t think it’s an issue, but I'm not a fan of random attributes popping up.Beta Was this translation helpful? Give feedback.
All reactions