Questo deriva dall'idea che le librerie di terze parti siano in Script per scoraggiare gli sviluppatori dalla personalizzazione. Li incoraggerebbe a scrivere estensioni per rendere più semplice l'acquisizione di una nuova versione di entrambe le librerie.Hot Towel: Perché Durandal e Require nella cartella App anziché nella cartella Script?
Si fa un buon punto su altri sviluppatori che scambiano le librerie durandal per i file personalizzabili.
Tuttavia, non è necessario mantenere Durandal ovunque. La struttura delle cartelle può essere qualsiasi cosa il tuo cuore desideri. Perché durandal non impone alcuna struttura di cartelle .. ha solo una configurazione predefinita raccomandata. Ci sono dei vantaggi nel seguire il suo schema.
Mantenendo durandal come parte della cartella principale dell'applicazione. Mantiene tutti i file amd javascript in un'unica cartella radice. In questo modo quando si esegue il durandale optimizer è possibile eseguire la scansione di ogni sottocartella per comprimere/minify/uglify tutti i file html/css/js in 1 file. Questo è un vantaggio benevolo perché è un build in 1 clic dell'intera applicazione.
Inoltre, è una bella separazione perché è una buona idea conservare le librerie JavaScript non-amd di terze parti in una struttura di cartelle separata in questo modo se si utilizza un bundler per comprimere tutte le librerie di terze parti in un file separato. Il browser può memorizzare nella cache l'applicazione separata dalle librerie di terze parti. Perché le librerie di terze parti non cambiano molto spesso, mentre la tua applicazione probabilmente cambierà frequentemente.
Ma le convenzioni di durandal sono completamente configurabili e puoi inserire durandal in qualsiasi posizione desideri.
Questa è una convenzione che Durandal ha deciso di utilizzare per mantenere il codice cliente del cliente organizzato in una cartella App e lontano dalla cartella degli script di terze parti, che diventa piuttosto complicata abbastanza rapidamente. Inserisce require.js nella cartella App a causa del modo in cui si basa su require.js e sul suo pattern AMD. require.js è usato per aiutare a localizzare tutti i moduli e caricarli secondo necessità (nella cartella dell'app).
C'è qualcosa di specifico che è necessario che questo stia impedendo?
Accetto la tua risposta e ora comprendo la convenzione Durandal. Tuttavia, suppongo che ci siano parti di Durandal che sono fondamentali per la sua funzione. Se si dispone di una situazione multi-SPA, si desidera che tutte le ZPS condividano/memorizzino il codice core di Durandal. La mia prospettiva è di ExtJs, in cui tutto nella cartella dell'app è personalizzato per la tua app. Tutto ciò che poteva essere condiviso da altre app era nella cartella di script o in una CDN. Le cose nello script non sono mai state modificate direttamente - solo indirettamente attraverso i file di estensione. La convenzione ha reso molto chiaro cosa dovrebbe e non dovrebbe essere modificato. –