@cahyo-dimas/freeday 1.46.0 → 1.48.1
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/CHANGELOG.md +32 -0
- package/adapters/core/table-model.js +30 -3
- package/package.json +1 -1
package/CHANGELOG.md
CHANGED
|
@@ -3,6 +3,38 @@
|
|
|
3
3
|
Semua perubahan penting dicatat di sini. Format longgar mengikuti
|
|
4
4
|
[Keep a Changelog](https://keepachangelog.com/); tiap versi = git tag.
|
|
5
5
|
|
|
6
|
+
## [1.48.1] — 2026-08-20
|
|
7
|
+
### Fixed
|
|
8
|
+
- **A date column sorted correctly and filtered nothing** (#025). `FdyTable`'s client-mode date
|
|
9
|
+
filter read a cell with `dateOnly`, which **sliced** the string, while its date SORT reads the same
|
|
10
|
+
cell with `toTime`, which **parses**. A date column normally renders a formatted date — that is
|
|
11
|
+
what `value` is for — so `"18 Mar 2024"` sliced to `"18 Mar 202"` and compared as text against an
|
|
12
|
+
ISO bound: every row failed, silently. The working sort is what made the broken filter look
|
|
13
|
+
trustworthy.
|
|
14
|
+
- **A `Date` cell was read as its UTC day, not the reader's** (#025). `toISOString()` east of
|
|
15
|
+
Greenwich turns local midnight into the previous day, so at UTC+7 filtering from the 18th dropped
|
|
16
|
+
a row dated the 18th.
|
|
17
|
+
- Text that is not a date now yields `''` and is EXCLUDED by an active date filter, rather than
|
|
18
|
+
slicing to something that compares as less than every bound and matching everything.
|
|
19
|
+
### Added — guards
|
|
20
|
+
- Three tests in `test/table-model.test.mjs`, each verified to fail against the old body: a
|
|
21
|
+
formatted `value`, a `Date` cell at a positive UTC offset, and unparseable text. The existing date
|
|
22
|
+
test only ever filtered a column with no accessor holding an already-ISO string, which is the one
|
|
23
|
+
shape neither bug can affect.
|
|
24
|
+
|
|
25
|
+
## [1.48.0] — 2026-08-20
|
|
26
|
+
### Reverted
|
|
27
|
+
- **1.47.0's readonly focus ring (#024) is withdrawn.** The report was measured wrong. The control in
|
|
28
|
+
question — a `CflField`'s readonly display input — sits inside `.fdy-input-group`, and
|
|
29
|
+
`.fdy-input-group:focus-within` already carries the border and the 3px ring for the WHOLE control;
|
|
30
|
+
`.fdy-input-group .fdy-input:focus` clears the inner input deliberately so the two do not nest. The
|
|
31
|
+
audit measured the INPUT, found no shadow on it, and concluded there was no focus indicator.
|
|
32
|
+
Measured on the group, focus shows `--color-primary` at full strength — 6.56:1. 1.47.0 therefore
|
|
33
|
+
painted a muted ring INSIDE the blue one, which is a regression rather than a fix.
|
|
34
|
+
### Added — guards
|
|
35
|
+
- `test/css.test.mjs` pins the arrangement — the group rings, the inner input does not — so the next
|
|
36
|
+
reader finds the answer instead of repeating the conclusion.
|
|
37
|
+
|
|
6
38
|
## [1.46.0] — 2026-08-19
|
|
7
39
|
The docs site catches up with the components, and writing it out as a consumer found a defect in
|
|
8
40
|
#016's own contract.
|
|
@@ -23,10 +23,37 @@ function toTime(v) {
|
|
|
23
23
|
return Number.isNaN(t) ? 0 : t;
|
|
24
24
|
}
|
|
25
25
|
|
|
26
|
-
/**
|
|
26
|
+
/** Already an ISO calendar day, so it needs no parsing. */
|
|
27
|
+
const ISO_DAY = /^\d{4}-\d{2}-\d{2}/;
|
|
28
|
+
|
|
29
|
+
/** @param {Date} d @returns {string} the LOCAL calendar day, never UTC's */
|
|
30
|
+
function localDay(d) {
|
|
31
|
+
const month = d.getMonth() + 1;
|
|
32
|
+
const day = d.getDate();
|
|
33
|
+
return `${d.getFullYear()}-${month < 10 ? '0' : ''}${month}-${day < 10 ? '0' : ''}${day}`;
|
|
34
|
+
}
|
|
35
|
+
|
|
36
|
+
/**
|
|
37
|
+
* @param {unknown} v @returns {string} ISO calendar day (yyyy-mm-dd) — lexicographically comparable
|
|
38
|
+
*
|
|
39
|
+
* Two bugs lived here, both of which let a column SORT by date correctly and
|
|
40
|
+
* FILTER by date wrongly — the worst pairing, because a working sort is what
|
|
41
|
+
* persuades you the header understands dates.
|
|
42
|
+
*
|
|
43
|
+
* 1. It sliced instead of parsing, while `toTime` (which the date SORT uses)
|
|
44
|
+
* parses. A column whose `value` returns a formatted date — the normal way
|
|
45
|
+
* to render one — gave `"18 Mar 2024"`, sliced to `"18 Mar 202"`, and
|
|
46
|
+
* compared as text against `"2024-03-18"`: every row failed, silently.
|
|
47
|
+
* 2. A `Date` went through `toISOString`, which is UTC. At UTC+7 a date picked
|
|
48
|
+
* as the 18th is `2024-03-17T17:00Z`, so filtering from the 18th dropped it.
|
|
49
|
+
* The calendar day a person means is their own, not Greenwich's.
|
|
50
|
+
*/
|
|
27
51
|
function dateOnly(v) {
|
|
28
|
-
if (v instanceof Date) return Number.isNaN(v.getTime()) ? '' : v
|
|
29
|
-
|
|
52
|
+
if (v instanceof Date) return Number.isNaN(v.getTime()) ? '' : localDay(v);
|
|
53
|
+
const s = String(v == null ? '' : v);
|
|
54
|
+
if (ISO_DAY.test(s)) return s.slice(0, 10);
|
|
55
|
+
const t = Date.parse(s);
|
|
56
|
+
return Number.isNaN(t) ? '' : localDay(new Date(t));
|
|
30
57
|
}
|
|
31
58
|
|
|
32
59
|
/** Raw cell value for a column: the column accessor if present, else row[key]. */
|