Biến css nội tuyến

Thuộc tính tùy chỉnh CSS, hay còn gọi là biến CSS cho phép chúng tôi xác định các thuộc tính hoặc biến tùy chỉnh để sử dụng trong CSS của mình

Giả sử chúng ta muốn xác định màu tùy chỉnh cho một nút. Chúng ta có thể sử dụng CSS sau

Với HTML sau

Nó sản xuất

Nhấp vào đây

Bạn có thể cập nhật thuộc tính tùy chỉnh bằng cách sử dụng kiểu nội tuyến

Nhấp vào đây

Điều này có thể rất hữu ích trong một số trường hợp. Ví dụ: bạn có thể có một thành phần lưới và bạn có thể muốn chỉ định số lượng cột và hàng bằng các biến CSS

Đơn giản nhất, GraphQL là yêu cầu các trường cụ thể trên các đối tượng. Hãy bắt đầu bằng cách xem xét một truy vấn rất đơn giản và kết quả chúng tôi nhận được khi chạy truy vấn đó

Bạn có thể thấy ngay rằng truy vấn có hình dạng chính xác giống như kết quả. Đây là điều cần thiết đối với GraphQL, bởi vì bạn luôn nhận được những gì bạn mong đợi và máy chủ biết chính xác những trường mà máy khách đang yêu cầu

Trường name trả về loại String, trong trường hợp này là tên của nhân vật chính trong Chiến tranh giữa các vì sao, "R2-D2"

Ồ, một điều nữa - truy vấn ở trên mang tính tương tác. Điều đó có nghĩa là bạn có thể thay đổi nó theo ý muốn và xem kết quả mới. Thử thêm trường appearsIn vào đối tượng hero trong truy vấn và xem kết quả mới

Trong ví dụ trước, chúng tôi chỉ hỏi tên của anh hùng đã trả về Chuỗi, nhưng các trường cũng có thể tham chiếu đến Đối tượng. Trong trường hợp đó, bạn có thể thực hiện lựa chọn phụ các trường cho đối tượng đó. Các truy vấn GraphQL có thể duyệt qua các đối tượng liên quan và các trường của chúng, cho phép khách hàng tìm nạp nhiều dữ liệu liên quan trong một yêu cầu, thay vì thực hiện nhiều chuyến khứ hồi như một yêu cầu trong kiến ​​trúc REST cổ điển

Lưu ý rằng trong ví dụ này, trường friends trả về một mảng các mục. Các truy vấn GraphQL trông giống nhau đối với cả các mục đơn lẻ hoặc danh sách các mục;

Tranh luận

Nếu điều duy nhất chúng ta có thể làm là duyệt qua các đối tượng và trường của chúng, thì GraphQL đã là một ngôn ngữ rất hữu ích để tìm nạp dữ liệu. Nhưng khi bạn thêm khả năng truyền đối số cho các trường, mọi thứ sẽ thú vị hơn nhiều

Trong một hệ thống như REST, bạn chỉ có thể chuyển một nhóm đối số - tham số truy vấn và phân đoạn URL trong yêu cầu của bạn. Nhưng trong GraphQL, mọi trường và đối tượng lồng nhau đều có thể nhận tập hợp đối số riêng, khiến GraphQL trở thành một sự thay thế hoàn toàn cho việc thực hiện nhiều lần tìm nạp API. Bạn thậm chí có thể chuyển các đối số vào các trường vô hướng để thực hiện chuyển đổi dữ liệu một lần trên máy chủ, thay vì trên từng máy khách riêng biệt

Đối số có thể có nhiều loại khác nhau. Trong ví dụ trên, chúng tôi đã sử dụng kiểu liệt kê, đại diện cho một trong số các tùy chọn hữu hạn (trong trường hợp này là đơn vị độ dài, hoặc là METER hoặc là FOOT). GraphQL đi kèm với một tập hợp các loại mặc định, nhưng máy chủ GraphQL cũng có thể khai báo các loại tùy chỉnh của riêng nó, miễn là chúng có thể được tuần tự hóa thành định dạng truyền tải của bạn

Đọc thêm về hệ thống loại GraphQL tại đây

bí danh

Nếu tinh ý, bạn có thể nhận thấy rằng, vì các trường đối tượng kết quả khớp với tên của trường trong truy vấn nhưng không bao gồm các đối số, nên bạn không thể truy vấn trực tiếp cùng một trường bằng các đối số khác nhau. Đó là lý do tại sao bạn cần các bí danh - chúng cho phép bạn đổi tên kết quả của một trường thành bất cứ thứ gì bạn muốn

Trong ví dụ trên, hai trường hero sẽ xung đột, nhưng vì chúng tôi có thể đặt bí danh cho chúng theo các tên khác nhau nên chúng tôi có thể nhận được cả hai kết quả trong một yêu cầu

mảnh vỡ

Giả sử chúng ta có một trang tương đối phức tạp trong ứng dụng của mình, trang này cho phép chúng ta xem xét hai anh hùng cạnh nhau cùng với bạn bè của họ. Bạn có thể tưởng tượng rằng một truy vấn như vậy có thể nhanh chóng trở nên phức tạp, bởi vì chúng ta sẽ cần lặp lại các trường ít nhất một lần - một trường cho mỗi bên của phép so sánh

Đó là lý do tại sao GraphQL bao gồm các đơn vị có thể tái sử dụng được gọi là các phân đoạn. Các mảnh cho phép bạn xây dựng các tập hợp trường, sau đó đưa chúng vào các truy vấn mà bạn cần. Đây là một ví dụ về cách bạn có thể giải quyết tình huống trên bằng cách sử dụng các đoạn

Bạn có thể thấy truy vấn trên sẽ khá lặp lại nếu các trường được lặp lại. Khái niệm phân đoạn thường được sử dụng để phân chia các yêu cầu dữ liệu phức tạp của ứng dụng thành các phần nhỏ hơn, đặc biệt khi bạn cần kết hợp nhiều thành phần giao diện người dùng với các phân đoạn khác nhau vào một lần tìm nạp dữ liệu ban đầu

Sử dụng các biến bên trong các đoạn

Các đoạn có thể truy cập các biến được khai báo trong truy vấn hoặc đột biến. Nhìn thấy

tên hoạt động

Trong một số ví dụ ở trên, chúng tôi đã sử dụng cú pháp tốc ký trong đó chúng tôi bỏ qua cả từ khóa name0 và tên truy vấn, nhưng trong các ứng dụng sản xuất, sẽ rất hữu ích khi sử dụng những cú pháp này để làm cho mã của chúng tôi bớt mơ hồ hơn

Đây là một ví dụ bao gồm từ khóa name0 là loại hoạt động và name2 là tên hoạt động

Loại thao tác là truy vấn, đột biến hoặc đăng ký và mô tả loại thao tác bạn định thực hiện. Loại thao tác là bắt buộc trừ khi bạn đang sử dụng cú pháp tốc ký truy vấn, trong trường hợp đó, bạn không thể cung cấp tên hoặc định nghĩa biến cho thao tác của mình

Tên hoạt động là một tên có ý nghĩa và rõ ràng cho hoạt động của bạn. Nó chỉ được yêu cầu trong các tài liệu đa thao tác, nhưng việc sử dụng nó được khuyến khích vì nó rất hữu ích cho việc gỡ lỗi và ghi nhật ký phía máy chủ. Khi xảy ra sự cố (bạn thấy lỗi trong nhật ký mạng hoặc trong nhật ký của máy chủ GraphQL), việc xác định truy vấn trong cơ sở mã của bạn theo tên sẽ dễ dàng hơn thay vì cố gắng giải mã nội dung. Hãy coi điều này giống như một tên hàm trong ngôn ngữ lập trình yêu thích của bạn. Ví dụ: trong JavaScript, chúng ta chỉ có thể dễ dàng làm việc với các hàm ẩn danh, nhưng khi chúng ta đặt tên cho một hàm, việc theo dõi, gỡ lỗi mã của chúng ta và đăng nhập khi nó được gọi sẽ dễ dàng hơn. Theo cách tương tự, các tên đột biến và truy vấn GraphQL, cùng với các tên phân đoạn, có thể là một công cụ sửa lỗi hữu ích ở phía máy chủ để xác định các yêu cầu GraphQL khác nhau

Biến

Cho đến nay, chúng tôi đã viết tất cả các đối số của mình bên trong chuỗi truy vấn. Nhưng trong hầu hết các ứng dụng, các đối số cho các trường sẽ động. Ví dụ: có thể có một danh sách thả xuống cho phép bạn chọn tập Chiến tranh giữa các vì sao mà bạn quan tâm hoặc trường tìm kiếm hoặc một bộ bộ lọc

Không nên chuyển trực tiếp các đối số động này vào chuỗi truy vấn, vì khi đó mã phía máy khách của chúng ta sẽ cần thao tác động chuỗi truy vấn trong thời gian chạy và tuần tự hóa nó thành định dạng dành riêng cho GraphQL. Thay vào đó, GraphQL có một cách hạng nhất để đưa các giá trị động ra khỏi truy vấn và chuyển chúng thành một từ điển riêng biệt. Các giá trị này được gọi là các biến

Khi chúng ta bắt đầu làm việc với các biến, chúng ta cần làm ba việc

1. Thay thế giá trị tĩnh trong truy vấn bằng name3
2. Khai báo name3 là một trong các biến được truy vấn chấp nhận
3. Vượt qua name5 trong từ điển biến riêng biệt, dành riêng cho vận chuyển (thường là JSON)

Đây là những gì nó trông giống như tất cả cùng nhau

Bây giờ, trong mã máy khách của chúng tôi, chúng tôi chỉ cần chuyển một biến khác thay vì cần tạo một truy vấn hoàn toàn mới. Nói chung, đây cũng là một cách thực hành tốt để biểu thị đối số nào trong truy vấn của chúng ta được mong đợi là động - chúng ta không bao giờ nên thực hiện phép nội suy chuỗi để xây dựng truy vấn từ các giá trị do người dùng cung cấp

định nghĩa khác nhau

Các định nghĩa biến là phần trông giống như name6 trong truy vấn ở trên. Nó hoạt động giống như các định nghĩa đối số cho một hàm trong ngôn ngữ đã nhập. Nó liệt kê tất cả các biến, có tiền tố là name7, tiếp theo là loại của chúng, trong trường hợp này là name8

Tất cả các biến được khai báo phải là vô hướng, enum hoặc kiểu đối tượng đầu vào. Vì vậy, nếu bạn muốn chuyển một đối tượng phức tạp vào một trường, bạn cần biết loại đầu vào khớp với máy chủ. Tìm hiểu thêm về các loại đối tượng đầu vào trên trang Lược đồ

Định nghĩa biến có thể là tùy chọn hoặc bắt buộc. Trong trường hợp trên, vì không có name9 bên cạnh loại name8 nên đây là tùy chọn. Nhưng nếu trường bạn đang chuyển biến vào yêu cầu một đối số không null, thì biến đó cũng phải được yêu cầu

Để tìm hiểu thêm về cú pháp cho các định nghĩa biến này, bạn nên tìm hiểu ngôn ngữ lược đồ GraphQL. Ngôn ngữ lược đồ được giải thích chi tiết trên trang Lược đồ

biến mặc định

Giá trị mặc định cũng có thể được gán cho các biến trong truy vấn bằng cách thêm giá trị mặc định sau khai báo kiểu

String1

Khi các giá trị mặc định được cung cấp cho tất cả các biến, bạn có thể gọi truy vấn mà không cần chuyển bất kỳ biến nào. Nếu bất kỳ biến nào được chuyển thành một phần của từ điển biến, chúng sẽ ghi đè giá trị mặc định

chỉ thị

Chúng tôi đã thảo luận ở trên cách các biến cho phép chúng tôi tránh thực hiện phép nội suy chuỗi thủ công để xây dựng các truy vấn động. Việc truyền các biến trong các đối số giải quyết được một lớp khá lớn các vấn đề này, nhưng chúng ta cũng có thể cần một cách để tự động thay đổi cấu trúc và hình dạng của truy vấn bằng cách sử dụng các biến. Ví dụ: chúng ta có thể tưởng tượng một thành phần giao diện người dùng có chế độ xem tóm tắt và chi tiết, trong đó một thành phần bao gồm nhiều trường hơn thành phần kia

Hãy xây dựng một truy vấn cho một thành phần như vậy

Hãy thử chỉnh sửa các biến ở trên để chuyển String2 thay cho String3 và xem kết quả thay đổi như thế nào

Chúng tôi cần sử dụng một tính năng mới trong GraphQL được gọi là chỉ thị. Một lệnh có thể được đính kèm với một trường hoặc bao gồm đoạn và có thể ảnh hưởng đến việc thực hiện truy vấn theo bất kỳ cách nào mà máy chủ mong muốn. Thông số kỹ thuật cốt lõi của GraphQL bao gồm chính xác hai chỉ thị, phải được hỗ trợ bởi mọi triển khai máy chủ GraphQL tuân thủ thông số kỹ thuật

• String4 Chỉ bao gồm trường này trong kết quả nếu đối số là String2
• String6 Bỏ qua trường này nếu đối số là String2

Các chỉ thị có thể hữu ích để thoát khỏi các tình huống mà nếu không thì bạn sẽ cần thực hiện thao tác chuỗi để thêm và xóa các trường trong truy vấn của mình. Việc triển khai máy chủ cũng có thể thêm các tính năng thử nghiệm bằng cách xác định các chỉ thị hoàn toàn mới

đột biến

Hầu hết các cuộc thảo luận về GraphQL đều tập trung vào việc tìm nạp dữ liệu, nhưng bất kỳ nền tảng dữ liệu hoàn chỉnh nào cũng cần một cách để sửa đổi dữ liệu phía máy chủ

Trong REST, bất kỳ yêu cầu nào cũng có thể gây ra một số tác dụng phụ trên máy chủ, nhưng theo quy ước, người dùng không nên sử dụng yêu cầu String8 để sửa đổi dữ liệu. GraphQL cũng tương tự - về mặt kỹ thuật, bất kỳ truy vấn nào cũng có thể được triển khai để ghi dữ liệu. Tuy nhiên, thật hữu ích khi thiết lập một quy ước rằng bất kỳ thao tác nào gây ra ghi phải được gửi một cách rõ ràng thông qua một đột biến

Giống như trong các truy vấn, nếu trường đột biến trả về một loại đối tượng, bạn có thể yêu cầu các trường lồng nhau. Điều này có thể hữu ích để tìm nạp trạng thái mới của một đối tượng sau khi cập nhật. Hãy xem xét một đột biến ví dụ đơn giản

Lưu ý cách trường String9 trả về trường "R2-D2"0 và "R2-D2"1 của bài đánh giá mới được tạo. Điều này đặc biệt hữu ích khi thay đổi dữ liệu hiện có, chẳng hạn như khi tăng trường, vì chúng ta có thể thay đổi và truy vấn giá trị mới của trường bằng một yêu cầu

Bạn cũng có thể nhận thấy rằng, trong ví dụ này, biến "R2-D2"2 mà chúng ta đã truyền vào không phải là biến vô hướng. Đó là một loại đối tượng đầu vào, một loại đối tượng đặc biệt có thể được chuyển vào dưới dạng đối số. Tìm hiểu thêm về các loại đầu vào trên trang Schema

Nhiều trường trong đột biến

Một đột biến có thể chứa nhiều trường, giống như một truy vấn. Có một điểm khác biệt quan trọng giữa truy vấn và đột biến, ngoài tên

Trong khi các trường truy vấn được thực thi song song, các trường đột biến chạy theo chuỗi, lần lượt từng trường một

Điều này có nghĩa là nếu chúng tôi gửi hai đột biến "R2-D2"3 trong một yêu cầu, lần đầu tiên được đảm bảo hoàn thành trước khi lần thứ hai bắt đầu, đảm bảo rằng chúng tôi không kết thúc với điều kiện chạy đua với chính mình

Đoạn nội tuyến

Giống như nhiều hệ thống kiểu khác, lược đồ GraphQL bao gồm khả năng xác định giao diện và kiểu kết hợp.

Nếu bạn đang truy vấn một trường trả về giao diện hoặc loại kết hợp, bạn sẽ cần sử dụng các đoạn nội tuyến để truy cập dữ liệu trên loại cụ thể bên dưới. Dễ dàng nhất để xem với một ví dụ

Trong truy vấn này, trường hero trả về loại "R2-D2"5, có thể là "R2-D2"6 hoặc "R2-D2"7 tùy thuộc vào đối số "R2-D2"8. Trong lựa chọn trực tiếp, bạn chỉ có thể yêu cầu các trường tồn tại trên giao diện "R2-D2"5, chẳng hạn như name

Để yêu cầu một trường trên loại cụ thể, bạn cần sử dụng một đoạn nội tuyến với điều kiện loại. Bởi vì đoạn đầu tiên được gắn nhãn là appearsIn1, trường appearsIn2 sẽ chỉ được thực thi nếu "R2-D2"5 được trả về từ hero thuộc loại "R2-D2"7. Tương tự cho trường appearsIn6 cho loại "R2-D2"6

Các mảnh được đặt tên cũng có thể được sử dụng theo cách tương tự, vì một mảnh được đặt tên luôn có một loại được đính kèm.

trường meta

Do có một số tình huống mà bạn không biết mình sẽ nhận được loại dữ liệu nào từ dịch vụ GraphQL, nên bạn cần một số cách để xác định cách xử lý dữ liệu đó trên máy khách. GraphQL cho phép bạn yêu cầu appearsIn8, một trường meta, tại bất kỳ điểm nào trong truy vấn để lấy tên của loại đối tượng tại điểm đó

Trong truy vấn trên, appearsIn9 trả về một loại kết hợp có thể là một trong ba tùy chọn. Sẽ không thể phân biệt các loại khác nhau từ ứng dụng khách nếu không có trường appearsIn8

Các dịch vụ GraphQL cung cấp một số trường meta, phần còn lại được sử dụng để hiển thị hệ thống Introspection