[invokers] Generalizing command invokers

Open
#1,487 19 comments 2 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
30/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
html

Research direction

Start with the existing commandfor/command and interestfor syntax described in issue #1487, then review the related value-change proposal in #1359. Compare the proposed command element, trigger, action, and for attributes against the listed use cases; done means the generalized API has an agreed scope and behavior for combining commands and supporting future triggers.

Written by the indexing model from the issue text.

Description

To design interest invokers, we have currently invented a parallel set of attributes with interestfor instead of commandfor. But essentially, interest invokers are just command invokers with a different set of events for the trigger. But re-using the same set of attributes would mean they cannot be combined on the same element, a common need.

But we'll run into this again. E.g. more triggers have already been proposed: keyboard shortcuts, overscroll, value changes (#1359), etc.

Instead of ad hoc copying the API for each case, which doesn't scale, what if we generalize it in a way that allows:

  1. customizing the trigger
  2. attaching multiple commands to the same element (this also allows multiple regular commands, for which there are use cases!)

I'd propose a <command> element:

  • The invoker is implicitly the parent. Later, we can introduce an additional attribute to specify a different invoker (either on the <command> or the invoking element), allowing for declarative reusable commands.
  • An attribute (action? value?), analogous to command. Possibly defaulting to toggle-popover to provide similar DX as today's interest invokers?
  • A new attribute for the trigger, e.g. type="click | interest". Singular value at first, later multiple values can provide multiple triggers if use cases emerge.
  • for as an equivalent of commandfor. Later, we could expand the syntax to produce dynamic targets for multiple different invoking elements.

I think this provides a lot more flexibility and room to grow with only marginally additional verbosity (and existing syntax can remain as a shortcut):

TodayWith <command>
<p>Some text with a <a href="#" interestfor="mypopover">link</a>.</p>
<p id="mypopover" popover>A short preview with some quick info</p>
<p>Some text with a <a href="#">link <command type=interest for=mypopover></command></a>.</p>
<p id="mypopover" popover>A short preview with some quick info</p>
<button commandfor="mypopover" command="toggle-popover">
  Toggle the popover
</button>
<div id="mypopover" popover>
  <button commandfor="mypopover" command="hide-popover">Close</button>
  Popover content
</div>
<button>
  <command for=mypopover></command>
  Toggle the popover
</button>
<div id="mypopover" popover>
  <button>Close <command action="hide-popover" for="mypopover"></command></button>
  Popover content
</div>

I think this offers a lot of room to grow, for example:

  • Additional triggers, or even custom triggers, analogously to custom commands!
  • Conditional attributes ike media
  • Many actions require additional parameters, it's trivial to expand to that
  • <command> elements would be hidden by default per the UA stylesheet, but if visible, they can be used as click-targets, providing a way to create interest buttons, feeding two birds with one scone!

WDYT?

Dominant language
MDX
Stars
4.5k
Forks
226
Avg merge
2d 22h
Merged PRs (30d)
4

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from openui/open-ui

All issues in openui/open-ui

Similar issues

More Design issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.