3.8 KiB
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:
Se il tuo progetto è già impostato così, possiamo procedere direttamente con questa struttura.