부드럽게 무슨 일이 일어났어?
JavaScript용 제안서
Array.prototype.flatten라는 언어 기능이
웹과 호환되지 않습니다. Firefox Nightly의 기능으로 인해 하나 이상의 인기 웹사이트가 운영됨
있습니다. 문제가 있는 코드가 광범위한 MooTools의 일부라는 점을 고려하면
더 많은 웹사이트가 영향을 받을 가능성이 높습니다. (MooTools
2018년에는 새로운 웹사이트에 흔히 사용되지 않지만
여전히 많은 프로덕션 웹사이트에 있습니다.)
제안서 작성자가 농담으로 flatten의 이름을 smoosh(으)로 변경할 것을 제안했습니다.
호환성 문제를 방지할 수 있습니다. 이 농담은 모두에게 명확하지 않은 것 같았고
사람들은 새 이름이 이미 이름이
상황이 빠르게 악화되었습니다.
Array.prototype.flatten의 기능
원래 Array.prototype.flatten로 제안된 Array.prototype.flat
지정된 depth까지 배열을 재귀적으로 평면화합니다. 기본값은
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]
동일한 제안서에 다음과 같은 Array.prototype.flatMap가 포함됩니다.
Array.prototype.map: 결과를 새 배열로 평면화한다는 점만 다릅니다.
[2, 3, 4].flatMap((x) => [x, x * 2]);
// → [2, 4, 3, 6, 4, 8]
이 문제를 일으키는 MooTools는 어떤 작업을 하고 있나요?
MooTools는 다음과 같이 자체적으로 비표준 버전의 Array.prototype.flatten를 정의합니다.
Array.prototype.flatten = /* non-standard implementation */;
MooTools의 flatten 구현이 제안된 표준과 다릅니다.
하지만 이는 문제가 아닙니다. 브라우저 탑재 시
Array.prototype.flatten를 사용하면 MooTools가 네이티브 광고보다
있습니다. 이렇게 하면 MooTools 동작에 의존하는 코드가
네이티브 flatten를 사용할 수 있는지 여부와 관계없이 의도한 대로 작동합니다.
지금까지는 잘 하고 계십니다!
안타깝지만 그 후 다른 일이 발생합니다. MooTools는
Elements.prototype의 맞춤 배열 메서드 (여기서 Elements는
MooTools 관련 API):
for (var key in Array.prototype) {
Elements.prototype[key] = Array.prototype[key];
}
for-in는 다음을 포함하지 않는 'enumerable' 속성에 대해 반복됩니다.
네이티브 메서드(예: Array.prototype.sort)이지만
정기적으로 할당되는 속성(예: Array.prototype.foo = whatever) 하지만 —
키커는 다음과 같습니다. 열거 불가능한 속성을 덮어쓰는 경우(예:
Array.prototype.sort = whatever로 설정된 경우 열거 불가능 상태로 유지됩니다.
현재 Array.prototype.flatten = mooToolsFlattenImplementation에서는 다음을 만듭니다.
열거 가능한 flatten 속성이므로 나중에 Elements에 복사됩니다. 하지만
브라우저는 flatten의 네이티브 버전을 제공하고 열거 불가능해집니다.
Elements에 복사되지 않습니다. MooTools에 의존하는 모든 코드
이제 Elements.prototype.flatten가 손상되었습니다.
네이티브 Array.prototype.flatten를 다음과 같이 변경한 것 같지만
enumerable을 사용하면 문제가 해결될 수 있지만
호환성 문제가 발생할 수 있습니다. for~in의 값을 사용하여 반복되는 모든 웹사이트
배열 (좋지 않은 방식이지만 발생하는 경우)은 갑자기
flatten 속성의 추가 루프 반복입니다.
여기서 더 큰 근본적인 문제는 기본 제공 객체를 수정하는 것입니다. 연장 네이티브 프로토타입은 일반적으로 좋지 않은 관행으로 받아들여지고, 다른 라이브러리 및 서드 파티 코드와 잘 구성되지 않습니다. 수정 안함 객체도 찾을 수 있습니다.
기존 이름을 그대로 두고 웹을 깨지 않는 이유는 무엇일까요?
CSS가 널리 보급되기 전인 1996년, 그리고 'HTML5'가 그리고 스페이스 잼 웹사이트가 시작되었습니다. 오늘날에도 이 웹사이트는 22년 전처럼 말이죠.
어떻게 이런 일이 일어난 걸까요? 누군가가 수년간 그 웹사이트를 유지했습니까? 브라우저 공급업체가 새 기능을 제공할 때마다 업데이트하는 것이 좋습니까?
'웹을 중단하지 않기'가 가장 중요한 디자인 원칙인 것으로 드러난 바 있습니다. CSS, JavaScript 및 기타 플랫폼에서 널리 사용되는 표준의 경우 웹. 새로운 브라우저 기능을 출시하여 기존 웹사이트의 작동을 중지하는 경우 모두에게 좋지 않습니다.
- 영향을 받은 웹사이트의 방문자에게 갑자기 사용자 환경이 손상됩니다.
- 웹사이트 소유자는 완벽하게 작동하는 웹사이트를 아무것도 변경하지 않는 비기능적 작업
- 사용자들로 인해 새 기능을 출시하는 브라우저 공급업체는 시장점유율을 잃음 '브라우저 X에서 작동합니다'를 확인한 후 다른 브라우저로 전환하는 행위
- 호환성 문제가 알려진 경우 다른 브라우저 공급업체는 배송을 거부합니다. 있습니다. 기능 사양이 현실과 일치하지 않음 ('허구책') 이는 표준화 프로세스에 좋지 않습니다.
물론 과거의 관점에서 보면 MooTools는 잘못된 작업을 했지만 웹을 깨뜨렸습니다. 사용자가 처벌을 받는다는 것입니다. 이 사용자들은 도대체 뭐가 뭔지 모르나 봐 있습니다. 또는 다른 해결 방법을 찾아 계속 진행할 수 있습니다. 있습니다. 선택은 간단합니다.
이는 잘못된 API는 웹 플랫폼에서 절대 삭제할 수 없다는 의미인가요?
경우에 따라 다릅니다. 드물지만 웹에서 잘못된 기능이 삭제되는 경우도 있습니다. 상상할 수 없을 정도로 특성을 삭제할 수 있는지 여부를 판단하는 것은 매우 까다로운 작업입니다. 얼마나 많은 웹 페이지가 운영되고 있는지 정량화하기 위해 광범위한 원격 측정이 변경할 수 있습니다. 그러나 기능이 충분히 안전하지 않은 경우 매우 드물게 사용되는 경우 이러한 작업이 가능합니다
<applet>, <keygen> 외
showModalDialog() 모두
웹 플랫폼에서 성공적으로 삭제된 잘못된 API의 예
MooTools만 고치지 않는 이유는 무엇인가요?
더 이상 내장 객체를 확장하지 않도록 MooTools를 패치하는 것이 좋습니다. 아이디어를 얻었습니다 그러나 당면한 문제는 해결되지 않습니다. MooTools가 패치 버전을 출시하려면 이 버전을 사용하는 모든 기존 웹사이트는 업데이트하시기 바랍니다.
사람들이 MooTools 사본을 업데이트하면 안 되나요?
완벽한 세상에서 MooTools는 패치를 출시하고 모든 웹사이트를 MooTools를 사용하면 다음 날 업데이트되겠죠. 문제가 해결되었습니다. 그렇죠?!
이는 비현실적입니다. 누군가가 어떤 식으로든 영향을 받은 웹사이트를 모두 확인하여 모든 웹사이트 소유자에게 성공적으로 다가가고 모든 사람이 업데이트를 수행하도록 설득합니다. 이는 리팩터링을 의미할 수 있으며 전체 코드베이스)을 완전히 마치려면 수년이 걸릴 것입니다.
이러한 웹사이트는 대부분 오래되어 관리되지 않을 가능성이 높습니다. 유지관리 담당자가 아직 곁에 있다 할지라도 웹 개발자에 대해 알아보겠습니다. 모든 사용자가 웹 호환성 문제로 인해 8년 된 웹사이트를 변경할 수 있었습니다.
TC39 프로세스는 어떻게 진행되나요?
TC39는 TC3를 통해 JavaScript 언어 발전을 책임지고 있는 ECMAScript 표준에 따라 다릅니다.
#SmooshGate가 'TC39가 flatten의 이름을
smoosh”이었지만 대외적으로 잘 전달되지 않은 농담이었습니다.
제안서 이름 변경과 같은 중요한 결정은 신중하게 내려진 것이 아니며
한 사람 한 명의 동영상이 하루아침에 촬영되는 것은 아닙니다.
GitHub 주석
TC39는 기능 제안을 위한 명확한 준비 절차에 따라 운영됩니다.
ECMAScript 제안 및 주요 변경사항 (메서드 포함)
이름 변경)은 TC39 회의 중에 논의되며
위원회 전체를 대상으로 하지 않습니다. 만약
Array.prototype.flatten님, 제안서가 이미 여러 단계를 거쳤습니다
3단계에 이르는 단계를 거치며 이는 해당 기능이
웹브라우저에서 구현할 준비가 된 상태입니다. 추가 사양이나
살펴봤습니다 이 경우 가장 중요한
기능은 배송을 시도한 후에 나왔습니다.
웹이 깨집니다. 이와 같이 예측하기 어려운 문제가 원인 중 하나입니다.
TC39 프로세스는 브라우저에 기능이 제공된다고만 끝나지 않습니다.
TC39는 합의에 따라 운영되므로
있습니다. smoosh이(가) 심각한 제안이었더라도
위원회 위원은
compact 또는 chain입니다.
이름이 flatten에서 smoosh(으)로 변경됨(농담이 아니었더라도)
TC39 회의에서 논의된 적이 없는 것 같습니다. 따라서 TC39의 공식적인 입장에서도
현재 알 수 없는 주제입니다. 한 사람이 한 사람을 대표하여 발언할 수 없습니다.
TC39의 모든 팀과 협력할 수 있었습니다.
TC39 회의는 일반적으로 매우 다양한 특성을 가진 사람들이 참석합니다. 프로그래밍 언어 디자인 경력이 있는 사람도 있고 어떤 것들은 브라우저 또는 JavaScript 엔진에서 작동하며, 점점 더 많은 사람들이 응답자는 JavaScript 개발자 커뮤니티를 대표합니다.
SmooshGate는 결국 어떻게 해결되었나요?
2018년 5월 TC39 회의 중 #SmooshGate
flatten의 이름을 flat(으)로 변경하여 공식적으로 해결되었습니다.
Array.prototype.flat 및 Array.prototype.flatMap가 V8 v6.9 및
Chrome 69