server_photo_s85js/map.md
2026-08-11 08:45:04 +02:00

155 lines
3.8 KiB
Markdown

Sì. Ora che mi hai passato tutte e 3 le parti, possiamo dividerlo davvero in modo funzionale, senza cambiare il comportamento attuale.
Ti consiglio di non fare semplicemente 3 file da ~500 righe, perché tra poco avrai anche le attività e torneremmo allo stesso problema.
Struttura che farei
public/js/map/
├── mapboxMarkers.js ← ENTRY POINT / API pubblica
├── mapboxState.js ← stato condiviso della mappa
├── mapboxUtils.js ← funzioni comuni
├── photoMarkers.js ← marker foto singole + spiderfy
├── photoClusters.js ← cluster foto HTML + smart zoom
├── mapboxSources.js ← sources/layers Mapbox
└── activityMarkers.js ← attività, da sviluppare
In questo modo avremo una separazione molto più pulita:
File Responsabilità
mapboxMarkers.js Facciata/API pubblica
mapboxState.js mapboxMap, foto, attività, routes, Map dei marker
mapboxUtils.js distanza, placeholder, funzioni comuni
photoMarkers.js foto singole e spiderfy
photoClusters.js cluster fotografici, collage, smart zoom
mapboxSources.js addSource, addLayer, aggiornamento GeoJSON
activityMarkers.js nuova gestione attività
E soprattutto eliminiamo una cosa importante
Nel codice che mi hai mandato ci sono due sistemi di cluster HTML:
updatePhotoClusterMarkers()
e
updatePhotoClusterHtmlMarkers()
che fanno sostanzialmente la stessa cosa ma in modo leggermente diverso.
Questo è uno dei motivi per cui il codice sta diventando difficile da mantenere.
Inoltre nella seconda implementazione c'è questa chiamata:
handlePhotoClusterClick(clusterFeature);
mentre la funzione è definita come:
function handlePhotoClusterClick(clusterId, center)
Quindi abbiamo anche una piccola incoerenza che conviene sistemare durante la divisione.
Il pallino blu di Mapbox
La modifica che hai fatto:
"circle-opacity": id === "photos" ? 0 : 0.9,
"circle-stroke-opacity": id === "photos" ? 0 : 1,
la manterrei.
Quindi:
Mapbox continua a creare/renderizzare il cluster;
queryRenderedFeatures() continua a trovarlo;
il cerchio blu di Mapbox non viene mostrato;
sopra ci mettiamo il nostro cluster HTML con le miniature.
Questo è importante perché se rimuoviamo completamente il layer photos-clusters, il sistema di cluster HTML che hai costruito perde il riferimento ai cluster visibili.
---
Punto fondamentale per le attività
Non farei:
if (id === "photos") {
...
}
if (id === "activities") {
...
}
dappertutto.
Meglio avere un sistema generico:
Mapbox
├── Photos
│ ├── source
│ ├── clusters
│ ├── markers
│ └── spiderfy
└── Activities
├── source
├── clusters
└── markers
Così in futuro possiamo aggiungere, per esempio:
activityMarkers.js
activityClusters.js
senza toccare il sistema delle foto.
---
Quindi la versione finale sarà concettualmente così
// mapboxMarkers.js
import { setMap } from "./mapboxSources.js";
import {
setPhotos,
clearPhotos,
} from "./photoMarkers.js";
import {
setActivities,
clearActivities,
} from "./activityMarkers.js";
import {
setRoutes,
} from "./mapboxSources.js";
window.MapboxMarkers = {
setMap,
setPhotos,
setActivities,
setRoutes,
};
e tutti i dettagli rimangono nei rispettivi moduli.
Non cambierei per ora la logica dei cluster/spiderfy più del necessario. Prima facciamo una separazione 1:1 del comportamento attuale, così non rischiamo di perdere i cluster che finalmente funzionano; poi possiamo migliorare il codice internamente.
L'unica cosa da verificare nel progetto è che questi file vengano caricati come ES modules, cioè con:
<script type="module" src="/js/map/mapboxMarkers.js"></script>
Se il tuo progetto è già impostato così, possiamo procedere direttamente con questa struttura.