Cos'è successobasso?!
Una proposta per un oggetto JavaScript
per la lingua chiamata Array.prototype.flatten risulta essere
Incompatibile con il web. La spedizione della funzionalità in Firefox Nightly ha generato almeno un sito web popolare
a rompere. Dato che il codice problematico fa parte della diffusa serie MooTools
di Google, è probabile che siano interessati molti altri siti web. (sebbene MooTools
non viene comunemente utilizzata per i nuovi siti web nel 2018, ma in passato era molto popolare e
è ancora presente su molti siti web di produzione).
L'autore della proposta ha scherzosamente suggerito di rinominare flatten in smoosh in
evitare il problema di compatibilità. La barzelletta non era chiara a tutti, alcuni
hanno iniziato a credere erroneamente che il nuovo nome fosse già
ha deciso, e le cose si sono moltiplicate rapidamente.
Che cosa fa Array.prototype.flatten?
Array.prototype.flat, originariamente proposto come Array.prototype.flatten,
unisce gli array in modo ricorsivo fino al valore depth specificato, valore predefinito
a 1.
// Flatten one level:
const array = [1, [2, [3]]];
array.flat();
// → [1, 2, [3]]
// Flatten recursively until the array contains no more nested arrays:
array.flat(Infinity);
// → [1, 2, 3]
La stessa proposta include Array.prototype.flatMap, che è come
Array.prototype.map tranne che per appiattire il risultato in un nuovo array.
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
Che cosa sta facendo MooTools che causa questo problema?
MooTools definisce la propria versione non standard di Array.prototype.flatten:
Array.prototype.flatten = /* non-standard implementation */;
L'implementazione di flatten di MooTools è diversa dallo standard proposto.
Tuttavia, questo non è il problema. Quando i browser vengono spediti
Array.prototype.flatten in modo nativo, MooTools sostituisce quello nativo
implementazione. Questo assicura che il codice basato sul comportamento MooTools
funziona come previsto a prescindere dalla disponibilità o meno di flatten nativo.
Finora stai andando bene.
Purtroppo, succede qualcosa di diverso. MooTools copia in tutti i suoi
metodi array personalizzati in Elements.prototype (dove Elements è un
API specifica di MooTools):
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
for-in esegue l'iterazione su proprietà "enumerabili", che non includono
metodi nativi come Array.prototype.sort, che però includono
proprietà assegnate regolarmente, come Array.prototype.foo = whatever. Ma...
ed ecco l'occhiello: se sovrascrivi una proprietà non enumerabile, ad esempio
Array.prototype.sort = whatever, rimane non enumerabile.
Attualmente, Array.prototype.flatten = mooToolsFlattenImplementation crea
una proprietà flatten enumerabile, quindi verrà copiata in un secondo momento in Elements. Ma se
i browser forniscono una versione nativa di flatten, che diventa non enumerabile e
non viene copiato in Elements. Qualsiasi codice che si basa su MooTools
Elements.prototype.flatten adesso non funziona.
Anche se sembra che modifichi il valore nativo Array.prototype.flatten
enumerabili risolverebbe il problema, probabilmente provocherebbe ulteriori
o problemi di compatibilità. Ogni sito web che si basa su for-in per eseguire l'iterazione
un array (che è una cattiva pratica, ma accade) improvvisamente riceve
un'ulteriore iterazione di loop per la proprietà flatten.
Il problema di fondo più grande qui è la modifica degli oggetti integrati. Estensione in corso... i prototipi nativi sono oggi generalmente una cattiva prassi, dato che non si integra bene con altre librerie e codice di terze parti. Non modificare oggetti che non possiedi.
Perché non manteniamo il nome esistente e abbassiamo il Web?
Nel 1996, prima che il CSS si diffondesse e molto prima che "HTML5" diventasse un è stato pubblicato il sito web di Space Jam. Oggi il sito web funziona ancora come 22 anni fa.
Come è successo? Qualcuno ha gestito il sito web per tutti questi anni? aggiornarla ogni volta che i fornitori di browser lanciano una nuova funzionalità?
È emerso che "non rompere il Web" è il principio principale della progettazione. per HTML, CSS, JavaScript e qualsiasi altro standard ampiamente utilizzato nella Sul web. Se la spedizione di una nuova funzionalità del browser causa l'interruzione dei siti web esistenti funziona, ma è un male per tutti:
- i visitatori dei siti web interessati subiscono improvvisamente un'esperienza utente non funzionante;
- proprietari di siti web sono passati da un sito perfettamente funzionante non funzionale senza che abbiano cambiato nulla;
- i fornitori di browser che offrono la nuova funzionalità perdono quota di mercato a causa degli utenti cambiare browser dopo aver notato "funziona nel browser X";
- una volta noto il problema di compatibilità, altri fornitori di browser si rifiutano di spedire li annotino. La specifica della funzionalità non corrisponde alla realtà ("nient'altro che un'opera di fantasia"), il che è negativo per il processo di standardizzazione.
Certo, con il senno di poi MooTools ha fatto la cosa sbagliata, ma ha rotto il web non li punisce, ma gli utenti. Questi utenti non sanno cosa sono lo strumento di authoring. In alternativa, possiamo trovare un'altra soluzione e gli utenti possono continuare per utilizzare il web. La scelta è facile.
Ciò significa che le API dannose non potranno mai essere rimosse dalla piattaforma web?
Dipende. In rari casi, funzionalità errate possono essere rimosse dal web. Anche solo per capire per capire se è possibile rimuovere una funzionalità è un'operazione molto difficile, Richiede una telemetria estesa per quantificare quante pagine web avrebbero comportamento è cambiato. Ma se la funzionalità non è sufficientemente sicura, è dannosa per o viene utilizzata molto raramente.
<applet>, <keygen> e
showModalDialog() sono tutti
esempi di API non valide rimosse dalla piattaforma web.
Perché non correggiamo solo MooTools?
L'applicazione di patch a MooTools in modo che non estenda più gli oggetti integrati è una buona dell'IA. Tuttavia, non risolve il problema in questione. Anche se MooTools per rilasciare una versione con patch, tutti i siti web esistenti che la utilizzano dovrebbero per risolvere il problema di compatibilità.
Non è possibile semplicemente aggiornare la propria copia di MooTools?
In un mondo perfetto, MooTools rilasciava una patch e ogni singolo sito web con MooTools sarebbe magicamente aggiornato il giorno successivo. Problema risolto, vero?!
Purtroppo, non è realistico. Anche se qualcuno dovesse identificare l'intero insieme di siti web interessati, trovare i dati di contatto per contattare tutti i proprietari di siti web, e convincerli a eseguire l'aggiornamento (il che potrebbe comportare il refactoring l'intera base di codice), l'intero processo richiederebbe, nella migliore delle ipotesi, anni.
Tieni presente che molti di questi siti web sono obsoleti e probabilmente non vengono mantenuti. Anche se l'operatore è ancora disponibile, è possibile che non sia un uno sviluppatore web altamente qualificato come te. Non possiamo aspettarci che vadano tutti e cambiare il proprio sito web di 8 anni a causa di un problema di compatibilità web.
Come funziona la procedura TC39?
TC39 è il comitato incaricato di sviluppare il linguaggio JavaScript mediante standard ECMAScript.
#SmooshGate ha indotto alcuni a credere che "TC39 vuole rinominare flatten in
smoosh", ma si trattava di uno scherzo che non era ben comunicato dall'esterno.
Decisioni importanti come la ridenominazione di una proposta non vengono prese con leggerezza,
da una sola persona e che non vengono sicuramente ripresi in un giorno sulla base di una
Commento GitHub.
TC39 adotta un chiaro processo di gestione temporanea per le proposte di funzionalità.
Proposte ECMAScript ed eventuali modifiche sostanziali apportate (incluso il metodo
altra denominazione) sono discussi durante le riunioni del TC39 e devono essere approvati dal
l'intero comitato prima che diventino ufficiali. Nel caso di
Array.prototype.flatten, la proposta è già stata oggetto di diverse
diverse fasi dell'accordo, fino alla Fase 3, a indicare che la funzionalità
pronte per essere implementate nei browser web. È comune trovare altre specifiche
che si possono presentare durante l'implementazione. In questo caso, la parte più importante
il feedback è arrivato dopo aver provato a distribuirla: la funzionalità, nel suo stato attuale,
rompe il web. Problemi difficili da prevedere come questi sono uno dei motivi per cui
il processo TC39 non termina solo una volta che i browser hanno fornito una funzionalità.
TC39 opera sul consenso, il che significa che il comitato deve concordare qualsiasi nuova
modifiche. Anche se smoosh fosse stato un suggerimento serio, sembra probabile che
un membro del comitato si oppone a favore di un nome più comune,
compact o chain.
Il ridenominazione da flatten a smoosh (anche se non fosse stato uno scherzo)
mai discussi a una riunione del TC39. Pertanto, la posizione ufficiale del TC39 su
questo argomento è attualmente sconosciuto. Nessun singolo individuo può parlare per conto di
tutti i TC39 finché non si raggiungerà
un consenso nella riunione successiva.
Le riunioni del TC39 di solito partecipano a persone con esigenze alcuni hanno anni di esperienza nella progettazione di linguaggio di programmazione, altri funzionano su un browser o motore JavaScript e un numero crescente di che rappresentano la community degli sviluppatori JavaScript.
Come è stato risolto SmooshGate, alla fine?
Durante la riunione del TC39 di maggio 2018, #SmooshGate
è stato ufficialmente risolto rinominando flatten in flat.
Array.prototype.flat e Array.prototype.flatMap disponibili con la versione V8 6.9 e
Chrome 69.