Date le vostre esigenze di:
- A) Basso utilizzo della RAM
- B) Limitazioni delle dimensioni dei file delle riunioni in Mongo
- C) Un'interfaccia utente reattiva
Prenderei in considerazione qualcosa sulla falsariga di quanto segue.
Prendi questa directory di esempio
C:\
C:\X\
C:\X\B\
C:\X\file.txt
C:\Y\
C:\Y\file.pdf
C:\Y\R\
C:\Y\R\file.js
In JSON potrebbe essere rappresentato come:
{
"C:": {
"X": {
"B": {},
"file.txt": "file information..."
},
"Y": {
"file.pdf": "file information...",
"R": {
"file.js": "file information..."
}
}
}
}
Quest'ultimo, come hai sottolineato, non si adatta bene con strutture di directory di grandi dimensioni (posso dirti in prima persona che i browser non apprezzeranno un BLOB JSON che rappresenta anche una directory modesta con poche migliaia di file/cartelle). Il primo, sebbene simile ad alcuni filesystem reali ed efficiente nel giusto contesto, è una seccatura lavorare con la conversione da e verso JSON.
La mia proposta è di suddividere ogni directory in un documento JSON separato, poiché ciò risolverà tutti e tre i problemi, tuttavia nulla è gratuito e ciò aumenterà la complessità del codice, il numero di richieste per sessione, ecc.
La struttura di cui sopra potrebbe essere suddivisa nei seguenti documenti:
[
{
"id": "00000000-0000-0000-0000-000000000000",
"type": "d",
"name": "C:",
"children": [
"11111111-1111-1111-1111-111111111111",
"22222222-2222-2222-2222-222222222222"
]
},
{
"id": "11111111-1111-1111-1111-111111111111",
"type": "d",
"name": "X",
"children": [
"33333333-3333-3333-3333-333333333333",
"55555555-5555-5555-5555-555555555555"
]
},
{
"id": "22222222-2222-2222-2222-222222222222",
"type": "d",
"name": "Y",
"children": [
"44444444-4444-4444-4444-444444444444",
"66666666-6666-6666-6666-666666666666"
]
},
{
"id": "33333333-3333-3333-3333-333333333333",
"type": "d",
"name": "B",
"children": []
},
{
"id": "44444444-4444-4444-4444-444444444444",
"type": "d",
"name": "R",
"children": [
"77777777-7777-7777-7777-777777777777"
]
},
{
"id": "55555555-5555-5555-5555-555555555555",
"type": "f",
"name": "file.txt",
"size": "1024"
},
{
"id": "66666666-6666-6666-6666-666666666666",
"type": "f",
"name": "file.pdf",
"size": "2048"
},
{
"id": "77777777-7777-7777-7777-777777777777",
"type": "f",
"name": "file.js",
"size": "2048"
}
]
Dove ogni documento rappresenta una directory o un file e (se directory) i suoi ID figlio immediati. Gli elementi figlio possono essere caricati in modo pigro utilizzando i loro ID e aggiunti al loro genitore nell'interfaccia utente. Il caricamento lento ben implementato può precaricare i nodi figlio alla profondità desiderata, creando un'interfaccia utente molto reattiva. L'utilizzo della RAM è minimo poiché il tuo server deve gestire solo piccoli payload per richiesta. Il numero di richieste aumenta considerevolmente rispetto a un approccio basato su un singolo documento, ma ancora una volta, alcuni intelligenti lazy loading possono raggruppare le richieste e ridurre il numero totale.
AGGIORNAMENTO 1 :In qualche modo ho trascurato il tuo penultimo paragrafo prima di rispondere, quindi questo è probabilmente più o meno quello che avevi in mente. Per affrontare il problema di troppi documenti, potrebbe essere necessario un certo livello di raggruppamento dei nodi all'interno dei documenti. Adesso devo partire ma ci penserò un po'.
AGGIORNAMENTO 2 :Ho creato una sintesi di una versione semplificata del concetto di clustering che ho menzionato. Non tiene conto dei file, solo delle cartelle e non include e non include il codice per aggiornare i documenti. Spero che ti dia qualche idea, continuerò ad aggiornarlo per i miei scopi.
Sommario:tree_docs_cluster.js
