@magicx-eng/ai-autocomplete-react 0.32.1 → 0.32.2
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +7 -13
- package/package.json +2 -2
package/README.md
CHANGED
|
@@ -16,7 +16,7 @@ A React/TypeScript SDK that provides a guided AI-powered autocomplete experience
|
|
|
16
16
|
- **Keyboard navigation** — arrow keys, enter to submit, tab to autocomplete, backspace to un-bold the last completed param
|
|
17
17
|
- **IME-safe** — composition events are buffered so input text is committed once, after composition ends
|
|
18
18
|
- **Client-side filtering** — instant substring filtering on every keystroke
|
|
19
|
-
- **Datepicker** — date parameters are answered with a calendar instead of an option list. Click a day or navigate with the arrow keys; the date is committed the way it would be written — `Tuesday` for a date inside the next week, `March 23` for one later this year, `March 23 2027` for another year. Tapping a committed date re-opens the calendar on the month that text names now — for a weekday name, that is the next such day, not the one originally picked. A
|
|
19
|
+
- **Datepicker** — date parameters are answered with a calendar instead of an option list. Click a day or navigate with the arrow keys; the date is committed the way it would be written — `Tuesday` for a date inside the next week, `March 23` for one later this year, `March 23 2027` for another year. Tapping a committed date re-opens the calendar on the month that text names now — for a weekday name, that is the next such day, not the one originally picked. A date-range parameter gets the same calendar answered in two clicks, committed as one range.
|
|
20
20
|
- **Option overrides** — supply the options for a parameter yourself: a fixed list, a computed one, or one fetched from your own search endpoint as the user types
|
|
21
21
|
- **Product strip** — the dropdown renders a horizontal row of product cards below the options, filled by default with the items the `/suggest` response reports as matching the query; plug in your own product search instead with `products`, or turn the strip off with `showProducts={false}`
|
|
22
22
|
- **Catalog report** — every response says which of the query's constraints the catalog applied, which it had to drop, and how many items are left, on `customFields` / `custom_fields`
|
|
@@ -136,11 +136,9 @@ After a completed param is added (by any means — option click, exact-match typ
|
|
|
136
136
|
### Datepicker
|
|
137
137
|
|
|
138
138
|
When the next parameter is a date, the dropdown shows a calendar instead of a
|
|
139
|
-
list of options.
|
|
140
|
-
|
|
141
|
-
|
|
142
|
-
relative phrases (`today`, `next week`) are not read as dates; a parameter
|
|
143
|
-
offering those needs a name that says date.
|
|
139
|
+
list of options. Which parameters are dates is the server's call: one whose
|
|
140
|
+
`type` is `date` gets a calendar, and one without a date type keeps its option
|
|
141
|
+
list, however date-like its name or options look.
|
|
144
142
|
|
|
145
143
|
Nothing is required to switch it on — a date parameter renders this way
|
|
146
144
|
automatically, and every other parameter is unaffected. Tier 1 and Tier 2
|
|
@@ -208,19 +206,15 @@ say which, and phrases like `next friday`. Those still open the calendar, just
|
|
|
208
206
|
on the current month with nothing marked, so the user picks rather than being
|
|
209
207
|
shown a guess that might be wrong.
|
|
210
208
|
|
|
211
|
-
**Date ranges.** A parameter whose
|
|
212
|
-
|
|
213
|
-
in two clicks: the first sets the start, the second the end, and the pair
|
|
209
|
+
**Date ranges.** A parameter whose `type` is `date_range` is answered by the
|
|
210
|
+
same calendar in two clicks: the first sets the start, the second the end, and the pair
|
|
214
211
|
commits as one answer. The days between them band as the user moves across the
|
|
215
212
|
calendar, so the span being chosen is visible before it is committed. Paging the
|
|
216
213
|
month between the two clicks is expected — that is how a span crosses months —
|
|
217
214
|
and <kbd>Esc</kbd> drops the start and lets them begin again. Clicking the end
|
|
218
215
|
before the start is fine; the two are ordered on the way in.
|
|
219
216
|
|
|
220
|
-
|
|
221
|
-
either separator (`-`, `–`, `—`, `to`, `through`, `until`), either half in any
|
|
222
|
-
date format the SDK reads, and a name that says so (`date_range`, `dateRange`)
|
|
223
|
-
counts too. It commits as one parameter, written the way it was offered —
|
|
217
|
+
It commits as one parameter, written as a span —
|
|
224
218
|
`September 11 - October 13`, with the year on whichever end needs it — and both
|
|
225
219
|
ends are also recorded on the completed parameter's `metadata` as `YYYY-MM-DD`,
|
|
226
220
|
under the `DATE_RANGE_META_START` / `DATE_RANGE_META_END` keys this package
|
package/package.json
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
{
|
|
2
2
|
"name": "@magicx-eng/ai-autocomplete-react",
|
|
3
|
-
"version": "0.32.
|
|
3
|
+
"version": "0.32.2",
|
|
4
4
|
"description": "AI Autocomplete React SDK — guided autocomplete with pill-based input and dropdown suggestions",
|
|
5
5
|
"main": "./dist/index.js",
|
|
6
6
|
"module": "./dist/index.mjs",
|
|
@@ -29,7 +29,7 @@
|
|
|
29
29
|
"react-dom": ">=17.0.0"
|
|
30
30
|
},
|
|
31
31
|
"dependencies": {
|
|
32
|
-
"@magicx-eng/ai-autocomplete-vanilla": "0.
|
|
32
|
+
"@magicx-eng/ai-autocomplete-vanilla": "0.37.0"
|
|
33
33
|
},
|
|
34
34
|
"devDependencies": {
|
|
35
35
|
"@figma/code-connect": "^1.4.7",
|