|
| 1 | +# data-sly-test: Redundant Constant Value Comparison |
| 2 | + |
| 3 | +Fixes for the AEM Cloud SDK HTL lint warning **"data-sly-test: redundant constant value comparison"**. |
| 4 | + |
| 5 | +**Rule:** In HTL, `data-sly-test` should always receive a variable or expression that evaluates to boolean — never a raw string literal, raw `true`/`false`, or a number directly. |
| 6 | + |
| 7 | +--- |
| 8 | + |
| 9 | +## Workflow |
| 10 | + |
| 11 | +When the user pastes **HTL lint warnings** or asks to fix **`data-sly-test`** issues: |
| 12 | + |
| 13 | +1. **Group warnings by file** (de-duplicate repeated lines from the build). |
| 14 | +2. **Classify** each warning using the flagged value (`true`/`false`, path string, number, split `${} || ${}`) — see patterns below. |
| 15 | +3. **Read the matching pattern section** before editing `.html` files. |
| 16 | +4. **Preserve logical intent** — only fix expression shape, not authoring behavior. |
| 17 | + |
| 18 | +## Proactive Discovery (find candidates without Maven) |
| 19 | + |
| 20 | +When the user wants to **find and fix** redundant `data-sly-test` issues but has **no build log yet**, run a **heuristic scan** on HTL templates, then fix hits using the patterns below. |
| 21 | + |
| 22 | +**Limits:** Grep is **not** the HTL compiler. It can **miss** issues (multiline attributes, unusual quoting) and **false-positive** on expressions that are fine. After edits, **`mvn … generate-sources`** (or the Cloud Manager build) is still the **authoritative** check. |
| 23 | + |
| 24 | +**Scope:** Prefer `ui.apps/**/jcr_root/**/*.html` and any other content packages that ship component HTL. |
| 25 | + |
| 26 | +From the **repository root**, use **ripgrep** (`rg`): |
| 27 | + |
| 28 | +| Pattern class | What to search | Example `rg` (run from repo root) | |
| 29 | +|---------------|----------------|-------------------------------------| |
| 30 | +| Boolean literal | `== true`, `== false`, `!= true`, `!= false` inside `data-sly-test` | `rg -n 'data-sly-test="[^"]*==\s*(true|false)' --glob '*.html' ui.apps` and `rg -n 'data-sly-test="[^"]*!=\s*(true|false)' --glob '*.html' ui.apps` | |
| 31 | +| Raw `/apps/…` string as test | HTL string literal starting with `/apps/` inside the attribute (common anti-pattern) | `rg -n "data-sly-test=.*'/apps/" --glob '*.html' ui.apps` (then confirm it is a useless string-as-test, not a legitimate comparison) | |
| 32 | +| Split `\|\|` / `&&` across `${}` | Literal `} || ${` or `} && ${` in one attribute | `rg -n 'data-sly-test="[^"]*\}\s*\|\|\s*\$\{' --glob '*.html' ui.apps` and the same pattern with `&&` instead of `\|\|` | |
| 33 | +| Numeric literal comparison | `== <digits>` inside a `data-sly-test` line (review each hit) | `rg -n 'data-sly-test="[^"]*==\s*[0-9]+\s*}' --glob '*.html' ui.apps` | |
| 34 | + |
| 35 | +**Agent workflow:** |
| 36 | + |
| 37 | +1. Run the `rg` lines above (adjust `ui.apps` to the user's module paths if different). |
| 38 | +2. Open each file at the reported lines; confirm the match is really a `data-sly-test` problem per the patterns below (skip unrelated `== 1` in other attributes if any). |
| 39 | +3. Apply fixes from the matching pattern section. |
| 40 | +4. Tell the user to run **HTL validate** / full module build so compiler warnings confirm nothing was missed. |
| 41 | + |
| 42 | +--- |
| 43 | + |
| 44 | +## Pattern 1: Boolean Constant Comparison (`== true` / `== false`) |
| 45 | + |
| 46 | +### What the linter flags |
| 47 | + |
| 48 | +The warning value is `true` or `false`. The HTL expression compares a variable against a boolean literal. |
| 49 | + |
| 50 | +### Before (warns) |
| 51 | + |
| 52 | +```html |
| 53 | +<div data-sly-test="${someVar == true}">visible when someVar is truthy</div> |
| 54 | +<div data-sly-test="${someVar == false}">visible when someVar is falsy</div> |
| 55 | +``` |
| 56 | + |
| 57 | +### After (clean) |
| 58 | + |
| 59 | +```html |
| 60 | +<div data-sly-test="${someVar}">visible when someVar is truthy</div> |
| 61 | +<div data-sly-test="${!someVar}">visible when someVar is falsy</div> |
| 62 | +``` |
| 63 | + |
| 64 | +### Rules |
| 65 | + |
| 66 | +- `== true` → remove the comparison; HTL treats the variable as boolean by default |
| 67 | +- `== false` → negate with `!` |
| 68 | +- If the original uses `data-sly-test.varName`, preserve the variable name: |
| 69 | + |
| 70 | +```html |
| 71 | +<!-- Before --> |
| 72 | +<div data-sly-test.isActive="${model.active == true}"> |
| 73 | + |
| 74 | +<!-- After --> |
| 75 | +<div data-sly-test.isActive="${model.active}"> |
| 76 | +``` |
| 77 | + |
| 78 | +### Edge case: `!= true` / `!= false` |
| 79 | + |
| 80 | +```html |
| 81 | +<!-- != true is the same as == false --> |
| 82 | +<div data-sly-test="${someVar != true}"> → <div data-sly-test="${!someVar}"> |
| 83 | + |
| 84 | +<!-- != false is the same as == true --> |
| 85 | +<div data-sly-test="${someVar != false}"> → <div data-sly-test="${someVar}"> |
| 86 | +``` |
| 87 | + |
| 88 | +--- |
| 89 | + |
| 90 | +## Pattern 2: Hardcoded String/Path as Test Value |
| 91 | + |
| 92 | +### What the linter flags |
| 93 | + |
| 94 | +The warning value is a string like `/apps/bcbsmgeneral/components/content/container`. A raw string literal inside `data-sly-test` is always truthy (non-empty string), so the condition is meaningless. |
| 95 | + |
| 96 | +### Diagnosis |
| 97 | + |
| 98 | +The author almost always **meant** to compare a variable against that string. Common cases: |
| 99 | + |
| 100 | +| Intent | Variable to compare | |
| 101 | +|--------|---------------------| |
| 102 | +| Check current resource type | `resource.resourceType` | |
| 103 | +| Check a child resource type | `childResource.resourceType` | |
| 104 | +| Check a property value | `properties.someProperty` | |
| 105 | +| Check a `data-sly-resource` path | a variable holding the resource type | |
| 106 | + |
| 107 | +### Before (warns) |
| 108 | + |
| 109 | +```html |
| 110 | +<!-- Always truthy — the string itself is the test --> |
| 111 | +<div data-sly-test="${'/apps/bcbsmgeneral/components/content/container'}"> |
| 112 | + ... |
| 113 | +</div> |
| 114 | +``` |
| 115 | + |
| 116 | +### After (clean) |
| 117 | + |
| 118 | +Determine **what variable** should be compared. The most common fix: |
| 119 | + |
| 120 | +```html |
| 121 | +<!-- Compare resource type (strip /apps/ prefix for sling:resourceType) --> |
| 122 | +<div data-sly-test="${resource.resourceType == 'bcbsmgeneral/components/content/container'}"> |
| 123 | + ... |
| 124 | +</div> |
| 125 | +``` |
| 126 | + |
| 127 | +Or if the path was being passed to `data-sly-resource`: |
| 128 | + |
| 129 | +```html |
| 130 | +<!-- The test was guarding a data-sly-resource include --> |
| 131 | +<sly data-sly-set.containerType="${'bcbsmgeneral/components/content/container'}"/> |
| 132 | +<div data-sly-test="${containerType}" |
| 133 | + data-sly-resource="${resource @ resourceType=containerType}"> |
| 134 | +</div> |
| 135 | +``` |
| 136 | + |
| 137 | +### Rules |
| 138 | + |
| 139 | +- **Never** leave a raw string as the sole `data-sly-test` value |
| 140 | +- Strip the `/apps/` prefix when comparing against `resource.resourceType` (Sling stores relative resource types) |
| 141 | +- If you cannot determine the intended variable, wrap in `data-sly-set` and add a `TODO` comment: |
| 142 | + |
| 143 | +```html |
| 144 | +<!-- TODO: verify the correct variable for this comparison --> |
| 145 | +<sly data-sly-set.expectedType="${'bcbsmgeneral/components/content/container'}"/> |
| 146 | +<div data-sly-test="${resource.resourceType == expectedType}"> |
| 147 | +``` |
| 148 | + |
| 149 | +### Nested resource iteration |
| 150 | + |
| 151 | +When iterating child resources (e.g. `data-sly-list`), the comparison often belongs on the child: |
| 152 | + |
| 153 | +```html |
| 154 | +<!-- Before (warns — raw path string) --> |
| 155 | +<sly data-sly-list.child="${resource.children}"> |
| 156 | + <div data-sly-test="${'/apps/bcbsmgeneral/components/content/container'}"> |
| 157 | + <sly data-sly-resource="${child}"/> |
| 158 | + </div> |
| 159 | +</sly> |
| 160 | + |
| 161 | +<!-- After --> |
| 162 | +<sly data-sly-list.child="${resource.children}"> |
| 163 | + <div data-sly-test="${child.resourceType == 'bcbsmgeneral/components/content/container'}"> |
| 164 | + <sly data-sly-resource="${child}"/> |
| 165 | + </div> |
| 166 | +</sly> |
| 167 | +``` |
| 168 | + |
| 169 | +--- |
| 170 | + |
| 171 | +## Pattern 3: Numeric Constant Comparison |
| 172 | + |
| 173 | +### What the linter flags |
| 174 | + |
| 175 | +The warning value is a number like `1` or `2`. HTL's linter flags numeric literals in comparisons even when the logic is correct. |
| 176 | + |
| 177 | +### Before (warns) |
| 178 | + |
| 179 | +```html |
| 180 | +<div data-sly-test="${properties.columnCount == 1}">one column</div> |
| 181 | +<div data-sly-test="${properties.columnCount == 2}">two columns</div> |
| 182 | +``` |
| 183 | + |
| 184 | +### After (clean) |
| 185 | + |
| 186 | +Extract the comparison into a `data-sly-set` variable: |
| 187 | + |
| 188 | +```html |
| 189 | +<sly data-sly-set.isOneColumn="${properties.columnCount == 1}"/> |
| 190 | +<sly data-sly-set.isTwoColumn="${properties.columnCount == 2}"/> |
| 191 | + |
| 192 | +<div data-sly-test="${isOneColumn}">one column</div> |
| 193 | +<div data-sly-test="${isTwoColumn}">two columns</div> |
| 194 | +``` |
| 195 | + |
| 196 | +### Rules |
| 197 | + |
| 198 | +- Move the numeric comparison into `data-sly-set` so `data-sly-test` only sees a boolean variable |
| 199 | +- Choose descriptive variable names (`isOneColumn`, `isTypeTwo`, etc.) |
| 200 | +- Place `data-sly-set` on a `<sly>` element **before** the element that uses `data-sly-test` |
| 201 | +- If many numeric comparisons exist (e.g. a switch-like block), group all `data-sly-set` declarations together at the top |
| 202 | + |
| 203 | +### Alternative: Use a Sling Model |
| 204 | + |
| 205 | +For complex switch logic, expose a method from the model: |
| 206 | + |
| 207 | +```java |
| 208 | +public boolean isOneColumn() { |
| 209 | + return getColumnCount() == 1; |
| 210 | +} |
| 211 | +``` |
| 212 | + |
| 213 | +```html |
| 214 | +<div data-sly-test="${model.oneColumn}">one column</div> |
| 215 | +``` |
| 216 | + |
| 217 | +--- |
| 218 | + |
| 219 | +## Pattern 4: Split-Expression Logical OR/AND |
| 220 | + |
| 221 | +### What the linter flags |
| 222 | + |
| 223 | +The warning value is something like `${properties.videoUrl} || ${properties.videoUrl1}`. HTL does **not** support `||` or `&&` operators **across** separate `${}` expression blocks. |
| 224 | + |
| 225 | +When you write: |
| 226 | + |
| 227 | +```html |
| 228 | +<div data-sly-test="${properties.videoUrl} || ${properties.videoUrl1}"> |
| 229 | +``` |
| 230 | + |
| 231 | +HTL evaluates `${properties.videoUrl}` as one expression and treats the literal string ` || ` and `${properties.videoUrl1}` as separate tokens. The result is unpredictable and always flagged. |
| 232 | + |
| 233 | +### Before (warns) |
| 234 | + |
| 235 | +```html |
| 236 | +<div data-sly-test="${properties.videoUrl} || ${properties.videoUrl1}"> |
| 237 | + video content |
| 238 | +</div> |
| 239 | +``` |
| 240 | + |
| 241 | +### After (clean) |
| 242 | + |
| 243 | +Combine into a **single** `${}` block: |
| 244 | + |
| 245 | +```html |
| 246 | +<sly data-sly-set.hasVideo="${properties.videoUrl || properties.videoUrl1}"/> |
| 247 | +<div data-sly-test="${hasVideo}"> |
| 248 | + video content |
| 249 | +</div> |
| 250 | +``` |
| 251 | + |
| 252 | +Or inline if the expression is short: |
| 253 | + |
| 254 | +```html |
| 255 | +<div data-sly-test="${properties.videoUrl || properties.videoUrl1}"> |
| 256 | + video content |
| 257 | +</div> |
| 258 | +``` |
| 259 | + |
| 260 | +### Rules |
| 261 | + |
| 262 | +- **All** logical operators (`||`, `&&`, ternary `? :`) must be inside a **single** `${}` block |
| 263 | +- If the combined expression is long, use `data-sly-set` for readability |
| 264 | +- The same applies to `&&`: |
| 265 | + |
| 266 | +```html |
| 267 | +<!-- BAD --> |
| 268 | +<div data-sly-test="${properties.a} && ${properties.b}"> |
| 269 | + |
| 270 | +<!-- GOOD --> |
| 271 | +<div data-sly-test="${properties.a && properties.b}"> |
| 272 | +``` |
| 273 | + |
| 274 | +--- |
| 275 | + |
| 276 | +## Validation Checklist |
| 277 | + |
| 278 | +After fixing all warnings in a file: |
| 279 | + |
| 280 | +- [ ] **Build passes** — re-run `mvn clean install` and confirm no `redundant constant value comparison` warnings remain for this file |
| 281 | +- [ ] **Logical intent preserved** — the element still shows/hides under the same conditions as before |
| 282 | +- [ ] **No broken references** — if `data-sly-test.varName` was changed, all downstream `${varName}` references still work |
| 283 | +- [ ] **No orphaned `data-sly-set`** — every `data-sly-set` variable is used by at least one `data-sly-test` |
| 284 | +- [ ] **Authoring still works** — component dialog values still drive the correct rendering in author and publish mode |
| 285 | + |
| 286 | +## Files That Cannot Be Auto-Fixed |
| 287 | + |
| 288 | +Some warnings require **human judgment**: |
| 289 | + |
| 290 | +- **Pattern 2** when the intended comparison variable is ambiguous (no obvious `resource.resourceType` or `properties.*` candidate) |
| 291 | +- **Expressions inside `data-sly-include` or `data-sly-template`** — the scope of variables may differ |
| 292 | +- **Third-party / ACS Commons overlays** — changing shared component HTL may break other sites on the same instance |
| 293 | + |
| 294 | +Flag these to the user with a `TODO` comment and move on. |
0 commit comments