알고리즘보다 데이터 구조와 디자인 패턴이 프런트엔드에 더 중요하다고 생각합니다. 세 가지 이유가 있습니다.
1)JS 기본 에너지가 제공하는 데이터 유형은 확실히 제한되어 있습니다. 객체와 배열을 사용하여 문제를 간단하고 난폭하게 해결하고 복잡한 비즈니스 코드 더미를 작성하여 논리를 지탱하는 경우가 많습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언)
예를 들어, 우리가 순환방송을 할 때, 당연히 배열로 순환방송 사진의 목록 데이터를 기록하는 것을 생각할 것이다. 우리는 vue 데이터 중심 뷰의 아이디어로 비교적 유행하고 있다. (윌리엄 셰익스피어, VUE 데이터 중심, 데이터 중심, 데이터 중심, 데이터 중심, 데이터 중심, 데이터 중심) 페이지를 넘길 때마다 배열에 있는 그림의 순서를 바꿔야 하는데, 문제없어 보입니다. 그러나 비즈니스가 복잡할 때, 예를 들어 루프 재생 및 양방향 재생을 지원해야 하는 경우 배열의 경계 값에 대한 특별한 판단이 필요하며 코드의 서비스 용이성이 떨어집니다.
그래서 만약 우리가 다른 각도에서 생각한다면, 처음에는 배열을 사용하지 않고 그림 목록을 정의하는 대신 체인리스트를 사용합니까? 문제는 훨씬 간단합니다. 그러나 연결된 목록의 데이터 구조는 js 의 기본 구현이 아니므로 우리 스스로 완성해야 한다.
따라서 일반적으로 사용되는 데이터 구조 및 관련 방법을 파악할 필요가 있습니다.
2) 디자인 패턴은 특정 상황에서 문제에 대한 우아한 해결책입니다. 나는 여기서 대담하고 우아하다. 네, 한 가지 질문에는 종종 한 가지 이상의 답이 있습니다.
예를 들어, click 이벤트를 페이지에 있는 일련의 버튼에 바인딩하고 버튼 내용이 클릭될 때 팝업되도록 요청하려고 합니다. 간단하고 난폭한 방법은 각 버튼에 onclick 이벤트를 추가하는 것입니다. 버튼 수가 매우 많거나 이 버튼에서 실행할 다른 클릭 이벤트가 있다고 가정하면 이 방안은 그다지 실현 가능하지 않다. 어떤 학생들은 사건 의뢰를 사용하는 것을 생각했는데, 네, 여기서 당신은 디자인 패턴, 프록시 패턴을 사용했습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 어느 쪽이 좋고 어느 쪽이 나쁜지 한눈에 알 수 있다.
각 비즈니스 시나리오에는 적절하고 우아한 솔루션이 있다고 생각합니다. 이것이 디자인 패턴입니다.
3) 일반적으로 프런트엔드에서 처리해야 할 데이터의 양과 계산의 복잡성은 높지 않다. 예를 들어, 배열의 최대값을 찾고 싶습니다. 일반적으로 버블 또는 빠른 행을 작성하는 것에 관계없이 배열의 정렬 방법을 직접 사용합니다. 만약 정말로 대량의 데이터를 처리해야 한다면, 이 처리 과정을 프런트엔드에 놓아야 하는지는 논의할 가치가 있을 것이다.
문제는 끊임없이 추상해야 하는 것이고, 추상화의 정도는 경험과 능력에 비례한다는 것이다.