Usually requests happen on natural events:
submit on forms and
elsewhere. You can use
ts-trigger="<event-type>" to change that behavior.
Syntax is also a bit more complex than just event-type, it allows some modifiers:
delay:<ms>- delay invokation by specified amount of milliseconds
once- remove listener after first invokation
changed- trigger only if elements’
valuehas changed since last invokation (or
checkedfor checkboxes and radios). Elements with no
nameare not supported.
Any regular DOM events are supported:
etc. There are some additional event types:
| ||Trigger on document load or when element appears on screen (if document is already loaded).|
| ||Trigger when window is scrolled.|
| ||Trigger when the target element is scrolled.|
| ||Trigger on click outside of the element.|
| ||Trigger when the element is removed. Uses MutationObserver.|
| ||Trigger when children are added to or removed from the element. Uses MutationObserver.|
| ||At least 1% of the element appeared in the viewport. Uses IntersectionObserver.|
| ||Element moved off the screen. Uses IntersectionObserver.|
| ||At least 1% of the element is closer than |
| ||Inverse of |
Triggering Requests #
Usually requests are triggered on natural interrupts: submit on forms and clicks elsewhere, but sometimes you want more, like triggering on being seen or hovered:
Doing something when element is almost visible makes it possible to implement lazy loading and various analytical events
You'll probably see this text after around 5 seconds or so. Click "Reset" to see loader again.
This sentence will log some message when it becomes invisible (moves out of browser viewport, and, actually, on load as well).
Click Outside #
Popups, modals, menus and some other elements can make use of
happened outside. It could be done with markup and underlying element,
but why bother if you have straightforward trigger.
This trigger is ideally used with modifier
once, since you're
probably going to remove that modal you calling it on - using
will clean up your listeners so you won't get memory leaks.
Dynamic Form Validation (advanced)#
Form validation is a common task, and TwinSpark allows to consolidate
validation logic on the server. Surprisingly, it could be difficult, but
ts-swap="morph" strategy allows us to just return whole new form
with errors and not mess up with focus.
- Inputs have an
idattribute - so that morphing algorithm can find them reliably.
- POST body contains
<input type="submit">'s value - this way backend distinguish submission and validation.
keyupupdates form on every character input and it feels natural - morph algorithm skips currently focused element so that state is intact.
Solve this problem with odd numbers
On Removal (advanced)#
It is useful to do something when node is removed (especially if that's some child or even non-related node triggering that removal). It's possible, but not recommended to use often since performance characteristics of the code are not well understood.
When this paragraph is removed by clicking button, it will resurrect itself.