Make `Fig.Generator["trigger"]` more declarative

[Robert Clover]

Sanity checks

• I have searched github.com/withfig/fig/issues and there are no duplicates of my feature

Feature Details

There are some things that currently happen imperatively that could happen declaratively.

• Token length changes
• Token length changes around a number, eg for 5: from 4>5, 4>6, 6>5, 6>4, etc.
• Final index of one of N strings is changed, instead of just one

type Trigger =
  | string
  | ((newToken: string, oldToken: string) => boolean)
  | { on: "change" }
  | { on: "threshold"; length: number }
  | { on: "string"; string: string | string[] };

interface Generator {
  trigger: Trigger;
}

const _0: Generator = {
  // Trigger on every keystroke
  trigger: { on: "change" },
}

const _1: Generator = {
  // Trigger when length passes 5
  trigger: { on: "threshold", length: 5 },
}

const _2: Generator = {
  // Trigger when length changes to or from 0
  trigger: { on: "threshold", length: 0 },
}

const _3: Generator = {
  // Trigger when any of the last index of any of the strings are changed
  trigger: { on: "string", string: [":", ","] },
}

// Implementation / equivalent `trigger` functions

// change:
// () => true

// threshold:
// (curr, prev) => (curr.length <= length && prev.length >= length) || (curr.length >= length && prev.length <= length)

// string:
// (curr, prev) => Math.max(...makeArray(strings).map((string) => curr.lastIndexOf(string))) !== Math.max(...makeArray(strings).map((string) => prev.lastIndexOf(string)))

cc @fedeci - are there any extras you can think of? Better names? I think this covers the main use-cases.

[Robert Clover]

Also, selfishly this would help https://github.com/SeparateRecords/run-fig because there can't be any imperative code in generators aside from custom

[Brendan Falk]

hmmm, I do like declarative, however, I think no matter what we should always enable it to be done imperative. At the end of the day Fig.trigger is a function that takes in the text before and the text after a change and then decides whether we should retrigger suggestion generation.

There are infinite permutations. Likely many common ones. And we already have a semi declarative syntax for the most common one: trigger: string where we check to see if the count of the string has changed between the two.

We rarely do triggers and when we do, the above declarative method works most of the time. Don't think this is worth that much more effort, at least compared to the other autocomplete stuff we need to do

[Robert Clover]

Definitely wouldn't remove the ability to use a function, but making it simpler to do the most common things is good

Just checked in withfig/autocomplete and this covers almost every case where there's currently a function for trigger

[Federico Ciardi]

type Trigger =
  | string
  | ((newToken: string, oldToken: string) => boolean)
  | { on: "change" }
  | { on: "threshold"; length: number }
  | { on: "match"; string: string | string[] };

I think this is a better naming, and I like the idea of having a sugar on top of trigger.

[Robert Clover]

"match" is way better!