단일 페이지 애플리케이션 경험에 대한 질문-HTML 튜토리얼-php.cn

---콘텐츠 복원 시작---

##단일 페이지 애플리케이션이란 무엇입니까? 단일 페이지 애플리케이션이란 전체 시스템이 단 하나의 페이지(하나의 html)만 있고 모든 비즈니스 기능이 하위 페이지에 통합되어 있음을 의미합니다. -모듈. 특정 방식으로 메인 인터페이스에 연결됩니다.

##단일 페이지 애플리케이션이 있는 이유는 무엇입니까? Ajax 기술이 만들어진 이유 중 하나는 웹 페이지를 방문하는 사용자가 페이지를 새로 고치지 않고도 페이지의 데이터 변경 사항을 볼 수 있도록 하기 위함이라는 것을 알고 있습니다. Ajax가 경험을 향상시킨다고 말할 수 있습니다.

인터넷이 발전하면서 브라우저가 제공하는 서비스는 점점 더 복잡해졌습니다. 웹 프런트 엔드는 더 이상 단순한 페이지, Ajax로 부분적으로 새로 고칠 수 있는 가젯이 아닙니다. 수십 개의 하위 페이지가 있는 애플리케이션은 시장 어디에서나 찾을 수 있습니다. 이러한 하위 페이지는 많은 공유 리소스(정적 및 동적)를 공유하므로 이러한 리소스를 반복적으로 로드하지 않으려면 확실한 방법이 있습니다. 하나의 HTML에 넣는 것입니다.

그래서 Ajax 기술을 더욱 승화시킨 것이며, Ajax의 새로 고침 없는 메커니즘을 최대한 활용하여 데스크톱 프로그램에 필적하는 원활한 사용자 경험을 만들 수 있습니다.

##단일 페이지 애플리케이션으로 인한 문제
HTML에 12~20개의 하위 페이지 프로그램을 넣는 것은 잘라내기+붙여넣기로는 해결할 수 없다는 것을 알고 있습니다. 원래 관련이 없는 프로그램을 합친 결과는 프로그래밍 세계의 질량-에너지 방정식입니다. Errors = (More Code)^2

##단일 페이지 애플리케이션의 경험
주제로 돌아가서 운영 경험을 향상시키는 방법 단일 페이지 애플리케이션을 최대한 많이 사용합니까?

그럼 먼저

1. 페이지의 초기 로딩 속도
2. 대화형 응답
3. 페이지 데이터의 정확성(특히 비정상적인 네트워크 조건에서)
을 포함하여 무엇이 사용자 경험에 영향을 미치는지 살펴보겠습니다.
--
사실 많은 기사에서 처음 두 가지 사항에 대해 더 많이 이야기했습니다. 여기서는 최선을 다해 간략하게 언급하고 세 번째 사항에 집중하겠습니다.

#### 페이지 초기 로딩 속도
- 온디맨드 정적 리소스 로딩(좋은 모듈화를 전제로 webpack 및 systemjs와 같은 모듈 번들러 도구 사용)
- 온디맨드 동적 리소스 획득(전면 필요) 최종 데이터 레이어 좋은 아키텍처)
- 서버 측 렌더링(페이지 로딩 프로세스 중에 프런트 엔드가 데이터를 "획득"하고 페이지를 "생성"하여 서버 측에서 완료합니다. 첫 번째 화면이 있는 애플리케이션에는 적합하지 않습니다. 너무 복잡함)

### #대화형 응답
- 속도: 백엔드 요청, 프런트엔드 캐시 및 후속 동기화에서 반환된 데이터입니다. 동일한 데이터에 대한 반복적인 요청을 피하세요.
- 예외 처리: 요즘 모바일 오피스가 인기를 끌고 있습니다. 네트워크 상태가 좋지 않을 때 사용자에게 충분한 대기 시간을 제공하거나 UI에 메시지를 표시하는 방법은 과소평가할 수 없습니다

####페이지 데이터의 정확성
이것은 더 이야기하고 싶은 것 예, 우리는 실제로 많은 문제에 직면했고 몇 가지 해결책을 시도했습니다.

저는 개인적으로 이 작업을 잘하려면 **"좋은 캐시 관리"**라는 단어만 있으면 된다고 생각합니다. 여기서 캐시는 프런트엔드 캐시 모델을 의미합니다.

이 몇 단어만 보지 마세요. 꽤 어렵습니다. 왜?

#### 먼저 메모리 소스에 대해 이야기해 보겠습니다. 다음과 같은 유형이 있습니다.

- 브라우저 캐시(indexDB, localStorage 등)
- http 요청
- webSocket 푸시

서로 다른 소스가 동일한 데이터에 영향을 미칩니다. 좋은 추상화를 통해 비즈니스 계층은 데이터 소스에 대한 인식을 보호할 수 있습니다. 이 문제를 해결하기 위해 널리 사용되는 기존 라이브러리에는 RxJs, CycleJS 등이 포함됩니다. MVI의 개념도 이 모든 목적을 위해 이전에 제안되었습니다.

#### 메모리의 변화에 대해 이야기해 보겠습니다

정상 상태의 변화 말할 필요도 없이 비정상 상태의 몇 가지 유형은 다음과 같습니다.

#####http 요청 실패

여기서 **"작업 보상"**이라는 단어를 언급해야 합니다.

작업 보상이란 무엇입니까?

논리적으로 말하면, 인터페이스를 조작하고 작업을 생성할 때 새 작업이 즉시 표시되어서는 안 되며 인터페이스에 추가하기 전에 서버가 성공을 확인할 때까지 기다려야 합니다. 하지만 우리 네트워크가 좋지 않아 사용자들이 이 단계를 거치는 데 오랜 시간을 기다려야 할 가능성이 매우 높습니다. 사용자 경험의 관점에서 볼 때 이는 좋지 않으므로 인터페이스를 먼저 배치한 다음 성공적인 생성 메시지가 돌아온 후 일부 고유 식별자 및 기타 항목을 메모리 데이터에 다시 채울 수 있습니다.

단일 단계 작업 보상은 그리 어렵지 않습니다. 여러 단계가 있으면 매우 번거롭습니다. 예를 들어 극단적인 경우 사용자가 새 작업을 추가했는데 서버가 아직 하위 작업을 즉시 생성하지 않았습니다. 하지만 이 단계를 보완하려면 하위 작업에 현재 상위 작업의 ID가 없습니다. 심지어 여러 차례 연속 작업을 수행한 후 이전 작업이 실패한 것으로 밝혀져 후속 처리가 매우 복잡해진다고 합니다.

저희 제품에도 이 문제가 발생합니다. 우리의 접근 방식은 - **"절충"**입니다. 중요한 데이터의 경우 단일 단계 보상 또는 2단계 보상을 수행합니다. 프런트엔드 모델의 종속관계가 복잡하여 상위 모델의 쓰기 작업이 실패하거나 보상 단계가 너무 많은 경우 사전에 사용자에게 알리고 UI에서 사용자의 상호 작용 입구를 잠급니다. 후속 쓰기 작업을 피하십시오.

여기에서 계속하면 오프라인 응용 프로그램과 유사하게 작업 결과가 클라이언트에 로컬로 기록됩니다. 그런 다음 데이터를 백그라운드와 동기화합니다. .

#####연결 끊김 및 재연결

네트워크 불안, 네트워크 전환, 컴퓨터 최대 절전 모드 및 다시 시작 등으로 인해 사용자가 인터넷에 다시 연결할 때 더 복잡한 네트워크 조건에 직면하게 됩니다. 다시 연결하세요.

이때 이상적인 단일 페이지 애플리케이션은 다시 연결할 때 모든 이전 이벤트의 최종 결과, 즉 최신 상태를 다시 동기화합니다.

우리 애플리케이션은 협업 비즈니스입니다. 동일한 기업의 사용자는 동일한 모델을 공유하고 webSocket을 통해 동기화하여 모델의 즉각성과 정확성을 보장합니다. 그래서 이것은 우리에게도 큰 도전입니다. 우리의 솔루션은 webSocket을 다시 보내는 것입니다.

#####핫 업데이트

앞서 언급했듯이 사용자는 애플리케이션을 오랫동안 열어두었다가 중간에 새로 고치지 않을 수 있습니다. 정상적인 상황에서는 모든 비즈니스 변경 사항이 푸시되어야 하며 인터페이스에서 피드백되는 상태는 항상 최신 상태이며 현재 상황에 부합합니다. 하지만 우리는 또 다른 문제를 고려해야 합니다. 시스템 업그레이드는 어떻습니까?

물론 푸시 알림도 가능합니다. 시스템이 업그레이드되었으니 새로고침을 클릭해 주세요. 하지만 더 잘할 수 있을까요? 이것이 가능합니다. 이 목표를 달성하려면 핫 업데이트를 사용하여 코드의 모듈화 및 변경 관리를 달성해야 합니다. 업데이트된 각 코드 모듈도 시스템의 현재 패치로 푸시되고 적용됩니다. 이 메커니즘에는 개발팀의 높은 기준이 필요합니다.

#####드디어
단일 페이지 제품의 기술 수준을 어떻게 판단할 수 있느냐는 말을 들은 적이 있습니다.
며칠 동안 켜져 있어도 페이지를 새로 고칠 필요가 없습니다. 애플리케이션은 정상적으로, 정확하고 원활하게 사용할 수 있습니다.

단일 지원서를 작성해 본 학생들은 이 의미를 이해할 것이라고 믿습니다.

##요약

말을 많이 했는데 요약해보겠습니다. 우리는 단일 페이지 애플리케이션 경험을 개선하기 위한 몇 가지 문제점과 방법을 언급했습니다. 구현되면 사용자는 분명히 매우 행복할 것이지만 이상과 현실 사이의 격차를 냉정하게 평가할 필요가 있습니다. 우리가 하는 일은 소프트웨어 엔지니어링이므로 미학을 적절하게 포기하고 제한된 인간 에너지를 핵심에 투자해야 합니다.