Lập kế hoạch chỉnh sửa tài liệu Slate-Trang trí

Trước đây chúng ta đã nói về thiết kế cấu trúc dữ liệu dựa trên trình soạn thảo tài liệu và hệ thống loại trình soạn thảo tài liệu được triển khai dựa trên phương tiện chặn. Bây giờ hãy nghiên cứu cách triển khai trình trang trí trong trình soạn thảo phương tiện chặn. Trình trang trí là một triển khai rất quan trọng trong phương tiện chặn, có thể xử lý việc hiển thị các phạm vi một cách thuận tiện trong quá trình lên lịch kết xuất của trình soạn thảo.

• Chỉnh sửa trực tuyến: https://windrunnermax.github.io/DocEditor
• Nguồn mở địa chỉ: https://github.com/WindRunnerMax/DocEditor

Các bài viết liên quan về dự án chỉnh sửa tài liệu phương tiện chặn

• Xây dựng trình soạn thảo tài liệu dựa trên Slate
• Chỉnh sửa tài liệu chặn phương tiện WrapNode cấu trúc dữ liệu và chuyển đổi hoạt động
• Trình chỉnh sửa tài liệu phương tiện chặn-mở rộng loại TS và kiểm tra nút loại
• Lập kế hoạch chỉnh sửa tài liệu Slate-Trang trí
• Chỉnh sửa tài liệu phương tiện chặn-Nút nút và đường dẫn chương trình

Trang trí

Trang trí là một chức năng thú vị trong phương tiện chặn. Hãy tưởng tượng một tình huống khi các khối mã cần được làm nổi bật, chúng ta có thể có một số tùy chọn để đạt được điều đó: Giải pháp đầu tiên là chúng ta có thể phân tích trực tiếp nội dung của khối mã và viết các danh mục từ khóa được phân tích cú pháp trực tiếp vào cấu trúc dữ liệu, để thông tin được đánh dấu có thể được hiển thị trực tiếp trong quá trình hiển thị. Nhược điểm là nó sẽ làm tăng kích thước dữ liệu. của dữ liệu được lưu trữ trong cấu trúc; thì trong phương pháp thứ hai, chúng tôi chỉ có thể lưu trữ thông tin mã khi cần đánh dấu dữ liệu, tức là trong quá trình hiển thị giao diện người dùng, chúng tôi sẽ phân tích dữ liệu đó thành Dấu để hiển thị. , nhưng trong trường hợp này, nếu có sự cộng tác, chúng ta cũng cần đánh dấu nó là hoạt động không cộng tác và Op máy khách thuần túy không yêu cầu lưu trữ phía máy chủ, điều này sẽ làm tăng độ phức tạp một chút thì phương pháp thứ ba là; Sử dụng trang trí Trên thực tế, có thể nói đây chỉ là Slate giúp chúng ta làm tốt phương pháp thứ 2, đồng thời có thể render thêm nội dung Marks mà không làm thay đổi cấu trúc dữ liệu.

Tất nhiên, các tình huống mà chúng tôi sử dụng trình trang trí đương nhiên không chỉ là làm nổi bật khối mã. Bất kỳ nội dung nào không muốn được thể hiện trong cấu trúc dữ liệu nhưng cần được thể hiện trong quá trình kết xuất thì cần phải được triển khai bằng cách trang trí. Một ví dụ rõ ràng khác là khả năng tìm kiếm. Nếu chức năng tìm kiếm được triển khai trong trình chỉnh sửa, thì chúng ta cần đánh dấu nội dung tìm thấy. Lúc này, chúng ta có thể sử dụng trang trí để đạt được nó. Nếu không, chúng ta cần vẽ một lớp ảo để hoàn thành. Nó. . Nếu chúng ta cần triển khai chức năng phân tích cú pháp siêu liên kết ở chế độ người dùng, tức là khi dán trực tiếp một liên kết, chúng ta muốn tự động chuyển đổi nó thành một nút siêu liên kết, chúng ta cũng có thể sử dụng một trình trang trí để đạt được điều này.

Khi tôi thử nghiệm ví dụ đánh dấu tìm kiếm trên trang web chính thức của phương tiện chặn cách đây một thời gian, khi tôi tìm kiếm các phần bổ sung, hiệu quả tìm kiếm rất tốt, nhưng khi tôi thực hiện tìm kiếm nhiều nút, nội dung không thể được làm nổi bật cho lắm. thông tin cụ thể, bạn có thể kiểm tra https://github.com/ianstormtaylor/slate/pull/5670. Điều này có nghĩa là có một số vấn đề khi trang trí thực hiện xử lý nút chéo. Ví dụ: trong ví dụ sau, khi chúng tôi tìm kiếm 123 hoặc 12345, chúng tôi có thể hiển thị trang trí được đánh dấu một cách bình thường. Tuy nhiên, khi chúng tôi tìm kiếm 123456, phạm vi chúng tôi xây dựng tại thời điểm này sẽ là path: [0], offset: [. 0- 6], lúc này chúng ta đã vượt qua nút [0] để đánh dấu và nội dung không thể được đánh dấu bình thường.

[ { văn bản: "12345" }, { văn bản: "67890" } ]

Bằng cách gọi mã liên quan đến tìm kiếm, chúng ta có thể thấy rằng kết quả trang trí của cấp trên sẽ được chuyển sang kết xuất tiếp theo. Sau đó, hàm trang trí đã truyền cũng sẽ được gửi ở cấp độ này để tạo ra các đồ trang trí mới và ở đây cần phải xác định xem có hay không. phần trang trí của nút cha giống với trang trí của nút cha. Nếu có sự giao nhau giữa các phạm vi của nút hiện tại thì nội dung sẽ tiếp tục được truyền đi. Vì vậy, điểm mấu chốt là ở đây. Hãy tưởng tượng kịch bản của chúng ta, vẫn lấy nội dung trong ví dụ trên làm ví dụ. Nếu chúng ta muốn lấy chỉ mục 123456 vào lúc này thì chắc chắn là không đủ trong văn bản nút: 12345. Chúng ta phải tìm thấy vị trí chỉ mục chính xác bằng cách nối nội dung của tất cả các nút văn bản ở mảng phía trên rồi tìm kiếm lại.

// https://github.com/ianstormtaylor/slate/blob/25be3b/packages/slate-react/src/hooks/use-children.tsx#L21 const useChildren = (props: { trang trí: Range[] // . .. }) => { // ... for (let i = 0; i < node.children.length; i++) { // ... const ds = trang trí([n, p]) for (const dec của đồ trang trí) { const d = Range.intersection(dec, range) if (d) { ds.push(d) } } // ... } // ... }

Sau đó, tại thời điểm này, rõ ràng chúng ta cần nút mà chúng ta gọi là trang trí làm phần tử cha và khi nút cha được chuyển đến nút văn bản mà chúng ta cần xử lý, Range.intersection là cần thiết để xác định xem có giao điểm hay không. Chiến lược xác định giao điểm ở đây rất đơn giản, dưới đây chúng tôi đưa ra hai ví dụ, một ví dụ có giao lộ và một ví dụ không có giao lộ. Chúng tôi thực sự chỉ cần xác định trạng thái cuối cùng của hai nút.

// https://github.com/ianstormtaylor/slate/blob/25be3b/packages/slate/src/interfaces/range.ts#L118 // start1 end1 start2 end2 // end1 start2 // end1 < start2 ===> Không có giao lộ // start1 start2 end1 end2 // start2 end1 // start2 < end1 ===> Có giao lộ [start2, end1]

Cụ thể khi các phần trang trí và các phần đó. Khác Loại bỏ nó Trên thực tế, khi phân tích ở trên, chúng tôi thấy rằng logic này không có vấn đề gì, tức là khi tìm kiếm 123456, chúng tôi hoàn toàn có thể hiển thị phần 12345. Theo phân tích trước đó, các nút của chúng ta trong vòng lặp này đều nằm ở đường dẫn: [0].

Vấn đề về nút chéo

Tuy nhiên, việc tiếp tục tìm kiếm 6 trong phạm vi văn bản tiếp theo không đơn giản như vậy, bởi vì phạm vi chúng tôi thực hiện đường dẫn: [1], độ lệch: [0-5] đường dẫn: [1], độ lệch: [0-5] đường dẫn: [1], độ lệch: [0-5]. điều kiện dự đoán ở trên, chúng tôi thấy rằng sẽ không có giao điểm. get phạm vi trước đó. nút này, chúng tôi không biết nút trước đó quá độ dài của nút riêng hay không. có thể gây ra sự cố về hiệu suất.

Do đó, chúng tôi vẫn bắt đầu bằng cách xây dựng phạm vi trong cú pháp phân tích quá trình. At the time điểm này, chúng tôi lấy dữ liệu làm ví dụ. trường hợp này, chúng tôi có thể xử lý một cách bình thường trong Range.intersection. chúng tôi được chỉnh sửa căn hộ ngay cả khi nội dung được kéo dài hoàn toàn, tức là khi nội dung tìm kiếm trải nghiệm dài trên nhiều nút , chúng tôi cũng có thể xử lý theo cách này.

// https://github.com/ianstormtaylor/slate/pull/5670 const text = node.children.map(it => it.text) const str = text.join('') const length = search.length let start = str.indexOf(search) let index = 0 let iterated = 0 while (start !== -1) { while (index < text.length && start >= iterated + text[index].length) { iterated = iterated + văn bản[index].length chỉ mục++ } let offset = start - lặp lại let còn lại = độ dài while (index < text.length && còn lại > 0) { const currentText = text[index] const currentPath = [.. .path, index] const đã được lấy = Math.min(còn lại, currentText.length - offset) range.push(/* .length offset = 0 index++ } } bắt đầu = str.indexOf(tìm kiếm, bắt đầu + search.length) }

Ngoài ra, khi gửi trang trí, chúng tôi cần chú ý đến giá trị của tham số renderLeaf RenderLeafProps, vì ở đây có hai loại nội dung văn bản bản là leaf: Text; và text: TextInterface; Ví dụ: kết quả dấu và kiểu in đậm trùng nhau Khi , cả hai loại nút cần phải dựa trên lá.

Lý do ở đây là các trang trí trong quá trình phát triển khai phương tiện ngăn chặn việc sử dụng nút văn bản làm cơ sở để chia nó thành nhiều lá, sau đó chuyển các lá đó tới renderLeaf để xuất. value ban đầu và lá thuộc tính là một nút chi tiết hơn. trang trí, điều này Các loại nút của cả hai thuộc tính đều tương đương nhau.

// https://github.com/ianstormtaylor/slate/blob/25be3b/packages/slate-react/src/comments/text.tsx#L39 const lá = SlateText.trang trí (văn bản, trang trí) const key = ReactEditor.findKey ( trình soạn thảo, văn bản bản) const Children = [] for (let i = 0; i < Leaves.length; i++) { const leaf = Leaves[i] Children.push(  ) }

cuối cùng

Ở đây chúng tôi tôi chủ yếu thảo luận về việc phát triển công cụ trang trí trang trí trong phương tiện ngăn chặn và các vấn đề có thể must in the use of performance. tiến trình xử lý riêng biệt. ta sẽ chủ yếu nói về biểu thức của Đường dẫn trong phương tiện chặn cũng như cách kiểm soát biểu thức nội dung của it và duy trì chính xác việc hiển thị nội dung Đường dẫn và Phần tử trong React.

Blog

https://github.com/WindRunnerMax/EveryDay

Cuối cùng, bài viết này về việc Lập kế hoạch xuất bản của Slate Document Editor-Decorator Decorator đã kết thúc ở đây. kế hoạch xuất của Slate Document Editor-Decorator Decorator, vui lòng tìm kiếm các bài viết CFSDN hoặc tiếp tục duyệt các bài viết liên quan, tôi hy vọng mong bạn sẽ ủng hộ blog của tôi trong tương lai .