You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
feat(es-lint-rule) eslint no-unused-param rule more strict (#3499)
* Modifying the eslint no-unused-param rule to be a bit more strict while still allowing unused parameters for handlers.
This allows us to catch a bit more cases when the parameter truly isn't used and shouldn't be part of the function signature.
* Standardized error handling between querying via WMS or via WFS and improved the error handling in general as well for the WMS layer type in particular
Copy file name to clipboardExpand all lines: .github/copilot-instructions.md
+37Lines changed: 37 additions & 0 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -325,6 +325,24 @@ See [time-dimension.md](../docs/programming/time-dimension.md) for the full arch
325
325
326
326
GeoView uses a lightweight typed delegate event system (see [event-helper.md](../docs/programming/event-helper.md)). Classes own private handler arrays (`#onXxxHandlers`) and expose `onXxx()`/`offXxx()` subscribe/unsubscribe methods. Events are emitted via `EventHelper.emitEvent()`. Controllers subscribe in `onHook()` and unsubscribe in `onUnhook()`.
327
327
328
+
**Handler parameter naming convention (required):** For EventHelper delegate handlers, always name parameters `sender` and `event`.
329
+
330
+
- Use `(sender, event)` even if one parameter is not used in the body.
331
+
-`sender` and `event` are exception names in the no-unused-parameter ESLint rule.
332
+
- Apply this convention in controllers, domains, APIs, and any callback wired to `onXxx()` EventHelper delegates.
333
+
334
+
```typescript
335
+
// ✅ Good
336
+
mapViewer.onMapMoveEnd((sender, event) => {
337
+
logger.logDebug(event.lonlat);
338
+
});
339
+
340
+
// ❌ Avoid
341
+
mapViewer.onMapMoveEnd((map, e) => {
342
+
logger.logDebug(e.lonlat);
343
+
});
344
+
```
345
+
328
346
## TypeScript Conventions
329
347
330
348
### Type Safety (Strict Enforcement)
@@ -352,6 +370,25 @@ const layers: string[] = [];
352
370
useState<TypeBasemapProps[]>([]);
353
371
```
354
372
373
+
-**Prefer optional property syntax for optional attributes/properties**: For class attributes and type/interface properties that may be absent, prefer `prop?: Type` over `prop?: Type | undefined`.
374
+
375
+
```typescript
376
+
// ✅ Good: concise optional property
377
+
interfaceLayerConfig {
378
+
layerName?:string;
379
+
}
380
+
381
+
// ❌ Avoid in most cases: redundant undefined union on optional property
382
+
interfaceLayerConfig {
383
+
layerName?:string|undefined;
384
+
}
385
+
386
+
// ✅ Exception: use this only when presence-vs-absence must be distinguished
387
+
interfaceLayerState {
388
+
layerName:string|undefined;
389
+
}
390
+
```
391
+
355
392
-**Avoid name collisions**: Use `GVLayer` not `Layer` when OpenLayers has a `Layer` class
Prefer optional property syntax (`?:`) for class attributes and type/interface properties that may be absent. In most cases, this is clearer than using an explicit `|undefined` union.
42
+
43
+
```ts
44
+
// Preferred in most cases
45
+
classLayerInfo {
46
+
layerName?:string;
47
+
}
48
+
49
+
typeTypeLayerConfig= {
50
+
sourceUrl?: string;
51
+
};
52
+
53
+
// Use only when presence-vs-absence must be distinguished
54
+
classLayerState {
55
+
// Property is always present, but value can be undefined
56
+
sourceUrl:string|undefined;
57
+
}
58
+
```
59
+
60
+
Use `property: Type|undefined` only when that distinction is intentional and required by behavior (for example: serialization differences, merge semantics, or APIs that depend on checking whether a key exists).
61
+
41
62
## 2- Avoid using variable names that are too short.
42
63
43
64
It is difficult to know what a variable with the name `e` refers to. Is it an `element`, an `event` or anything else whose name starts
@@ -249,7 +270,25 @@ In classes, functions should be ordered in the following way:
249
270
- static private
250
271
- event types
251
272
252
-
## 12- React Performance Patterns
273
+
## 12- EventHelper handler parameter naming
274
+
275
+
When subscribing to events emitted through our `EventHelper` delegates, handler methods should use the parameter names `sender` and `event`.
276
+
277
+
This naming is required for consistency and readability across the codebase. These names are also treated as exceptions in our no-unused-parameter ESLint rule, so they should be used even when one of the arguments is not consumed in the implementation.
Copy file name to clipboardExpand all lines: packages/geoview-core/src/core/components/layers/right-panel/layer-opacity-control/layer-opacity-control.tsx
0 commit comments