WeChat 개발을 위한 WXML, WXSS 및 JS에 대한 자세한 소개

이 글은 주로 WeChat 애플릿의 WXML, WXSS, JS 소개와 자세한 설명에 대한 관련 정보를 소개하고 있습니다. . 그런 다음 참고할 수 있도록 몇 가지 실험 결과를 나열하십시오.

개발 도구를 사용한 시뮬레이션과 실제 머신에는 큰 차이가 있습니다. 또한 실제 머신에서

디버깅

하는 것이 더 안정적이라고 제안합니다.

1. WXML(HTML)

1.1 미니 프로그램의 WXML은 HTML만큼 관대하지 않으며 단일 태그는 />로 끝나야 합니다. ;. 그렇지 않으면 오류가 보고됩니다.

1.2 공식적으로 권장하는 기본 태그인 는 블록 태그이고, 는 텍스트 태그로 사용되지만 p 등의 다른 태그도 사용할 수 있으며 모두 인라인 태그입니다. . 그리고 wxml 파서는 화이트리스트에 없는 태그의 모든 속성을 제거합니다. 클래스, ID 및 데이터는 모두 화이트리스트에 있어야 하지만 href 등은 없으므로 기존 html 태그를 사용하는 경우 이론적으로는 페이지를 만드는 것이 가능하지만 이는 인라인 태그이므로

표시

를 직접 설정해야 합니다. 1.3 스크롤뷰의 상단 스크롤과 좌측 스크롤은 스크롤뷰의 스크롤 위치를 수정할 수 있습니다. 그러나 사용자가 스크롤한 후에 애플릿은 스크롤 상단 및 왼쪽 스크롤의 할당을 변경하지 않습니다(양방향 동기화가 아님). 이때 setData를 사용하여 수정하면 스크롤 상단과 스크롤 왼쪽의 지정이 마지막 값과 동일해지며, 애플릿에서는 이 수정 사항을 적용하지 않으므로 설정이 적용되지 않는 성능이 됩니다. 이때 다른 값을 먼저 설정한 후 다시 설정하는 것만 가능합니다. (setData 메소드가 동기식이라는 것도 반영될 수 있습니다.) 스크롤 뷰는 바인드스크롤 콜백 함수를 통해서만 얻을 수 있는 스크롤 위치를 얻으므로, 스크롤 위치를 얻어야 하는 경우에는 직접 저장하시기 바랍니다. 스크롤 뷰에는 여전히 웹뷰 스크롤의 불쾌한 문제가 있습니다. 첫 번째 작업이 맨 위 위치에서 아래로 스크롤하는 것이라면 스크롤 상단을 0으로 설정하지 않아도 손이 스크롤할 수 없게 됩니다. 하지만 1. 알았어.

1.4 입력은 현재 왼쪽 텍스트만 지원하며 다른 텍스트는 불가능합니다(시뮬레이터에서는 가능). 양식을 만드는 경우 입력 및 기타 양식 요소를 양식에 넣는 것이 좋습니다. 트리거에서 제출하면 모든 내부 양식 요소의 이름-값이 반환됩니다. 그렇지 않으면 모든 양식 요소의 변경 이벤트를 바인딩해야만 얻을 수 있으므로 매우 번거롭습니다.

1.5 체크박스 그룹에만 변경 이벤트가 있고, 단일 체크박스에는 그렇지 않으며, 체크박스 그룹을 밖에 두는 것이 번거롭고 보기 흉하다고 생각되는 경우 스위치를 사용할 수 있습니다. 대신에 type="checkbox"를 선택하세요. (위챗 미니프로그램 신청계정 소통그룹 563752274)

1.6 지도 구축으로 인해 현재 앱 첫 페이지에서 직접 로딩 시 로딩 오류가 발생하고 있습니다. onLoad 이후에 추가해야 합니다. 먼저 wx:if="false"를 사용한 다음 onLoad 후에 true로 변경할 수 있습니다.

1.7 맵, 캔버스는 웹뷰의 기본 구성요소를 덮는 것과 같습니다.

overflow

와 요소로는 덮을 수 없습니다. 아무리 높게 써도 z-index는 그 위에 놓일 수 없다고 생각하시면 됩니다. 따라서 페이지에 탄성 레이어와 마스킹 레이어를 만드는 것은 권장되지 않습니다. 캔버스는 스크롤 뷰에 배치할 수 없으며 스크롤은 초기 위치에 위치하게 됩니다. 캔버스의 배경색을 설정하면 배경색 블록도 함께 스크롤되지만 이미지는 스크롤되지 않습니다.

2. WXSS(CSS)

2.1 WXSS는 CSS와 매우 유사하며 기본적으로 모든 CSS를 지원하며 미니 프로그램에서도 rpx 단위를 제공합니다. . 한 화면 너비는 750rpx입니다. 레이아웃으로 사용하는 것이 좋습니다. 그러나 아래에 나열할 몇 가지 사소한 차이점이 있습니다.

2.2 WXSS는 중첩된 중괄호({{}})를 지원하지 않습니다. 따라서 키프레임과 CSS 애니메이션은 사용할 수 없지만 전환은 가능합니다.

2.3 이번 테스트에 소개된 글꼴도 기존 WXML에서 언급한 내용을 SVG에서 사용할 수 없습니다. 따라서 아이콘은 현재 그림 형태로만 제작이 가능합니다.

2.4 WXSS에서는 로컬 리소스를 도입할 수 없고, 온라인 리소스만 사용할 수 있으며(시뮬레이터도 가능하지만 믿기지 않음), base64를 사용할 수 있습니다. (WeChat 애플릿 애플리케이션 계정 통신 그룹 563752274)

2.5 WXSS 규칙은 설정 연결을 지원하지 않습니다. 따라서 이와 같이 body .main {Background:#000;}을 작성할 수 없습니다. 그래서 글을 쓰는 것이 꽤 힘들다. 각 수업은 매우 길며, 그렇지 않으면 이름이 중복될 우려가 있습니다. 단, li.

current

{color: red;} 같은 쓰기는 지원되며, before pseudo-class는 지원되지만 first-child last- 자식 n번째는 지원되지 않습니다. 2.6 app.wxss와 각 페이지의 wxss 사이의 적용 관계는 다음과 같습니다. 동일한 이름의 규칙이 있는 경우 페이지는 병합이 아닌 앱을 덮어씁니다.

3. JS

3.1 JS의 실행 환경과 view의 실행 환경은 분리되어 있습니다. JS는 데이터 수정을 위해 이벤트 획득 타이밍과 setData 메소드를 통해서만 뷰를 변경할 수 있습니다.

3.2 JS 현재 페이지의 너비와 높이를 px 수준으로 얻을 수 없다는 큰 문제가 있습니다. 모든 이벤트 콜백의 단위는 rpx가 아닌 px 수준이지만 현재 rpx 간의 변환 관계는 다음과 같습니다. px는 알 수 없습니다. 예를 들어, 캔버스를 사용하여 그림을 그립니다. 경계가 어디인지조차 모르니 정말 짜증납니다.

3.3 위에서 언급했듯이 setData 메소드는 이전 값과 다음 값이 동일할 경우 뷰 수정을 트리거하지 않습니다(1.3 참조)

3.4 이동을 사용하여 점프할 때 사용할 수 있습니다. queryString 메소드는 상대 주소를 따르고 onLoad 이벤트는 입력 매개변수(객체로 변환됨)로 전달되지만 뒤로 탐색할 때 공식적인 데이터 통신 메커니즘은 없습니다. getApp()을 사용하여 전역 개체를 가져오고, 여기에 무언가를 추가하고, 직접 구현할 수 있습니다. 최대 5개의 탐색 수에 대해서는 이야기하지 않겠습니다.

3.5 Canvas getActions가 호출된 후 작업이 지워집니다. 즉, getActions가 연속으로 두 번 호출되고 두 번째는 빈 배열입니다.

3.6 개발자 도구는 nw가 작성했습니다. 개발자 도구의 WXML에는 파서 및 재조립 프로세스가 있습니다. 하지만 그렇다고 가젯이 네이티브라는 뜻은 아닙니다. CSS 지원부터 웹뷰의 몇몇 버그의 유사성까지 아직은 웹뷰처럼 보이지만 맵, 캔버스 등의 구성 요소는 네이티브 뷰를 사용한 다음 웹뷰에서 덮어줍니다. 감정. 하지만 어쨌든 자동 초점이 키보드를 자동으로 호출할 수 있다는 사실은 이미 큰 칭찬입니다.

[관련 추천]

1. 위챗 공개계정 플랫폼 소스코드 다운로드

2.위챗 투표 소스코드

3.

WeChat Lala Takeaway 2.2.4 WeChat 루빅스 큐브 소스 코드의 복호화된 오픈 소스 버전

위 내용은 WeChat 개발을 위한 WXML, WXSS 및 JS에 대한 자세한 소개의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!