การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ (2023)

สารบัญ

1 |รู้เบื้องต้นเกี่ยวกับโทเค็นการออกแบบ
2 |การจัดการและส่งออกโทเค็นการออกแบบด้วยพจนานุกรมสไตล์
3 |การส่งออกโทเค็นการออกแบบจาก Figma ด้วยพจนานุกรมสไตล์
4 | การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ข้ามแอปพลิเคชันเฉพาะแพลตฟอร์ม
5 |การสร้างเฉดสีธีมโทเค็นการออกแบบด้วยพจนานุกรมสไตล์
6 |จัดทำโทเค็นการออกแบบเอกสารด้วย Docusaurus
7 |การรวมโทเค็นการออกแบบเข้ากับ Tailwind
8 |การถ่ายโอนความเที่ยงตรงสูงจากไฟล์การออกแบบไปยังพจนานุกรมสไตล์
9 |การให้คะแนนโทเค็นการออกแบบด้วย OCLIF และ PostCSS
10 |ส่วนประกอบ Bootstrap UI พร้อมโทเค็นการออกแบบและ UI แบบไม่มีส่วนหัว
11 |โทเค็นการออกแบบ Linting ด้วย Stylelint
12 |การต่อสไตล์เข้ากับ UI แบบไม่มีหัวโดยใช้โทเค็นการออกแบบและ Twind

สิ่งที่คุณกำลังจะเข้าไป

ในบทความก่อนหน้านี้ฉันได้สาธิตวิธีที่เราสามารถสร้างกระบวนการอัตโนมัติเพื่อสร้างโทเค็นการออกแบบจากไฟล์การออกแบบโดยใช้ปลั๊กอินและส่งออกเป็นแพลตฟอร์มที่ส่งมอบได้โดยใช้ Style Dictionary และ GitHub Actions

ฉันได้กล่าวถึงสถานการณ์สมมติที่เราทำงานให้กับ ZapShoes ซึ่งเป็นแอปพลิเคชันอีคอมเมิร์ซที่จัดส่งรองเท้าใน zap และได้รับมอบหมายให้เปลี่ยนแปลงระบบการออกแบบของบริษัทโดยอัตโนมัติเพื่อสะท้อนถึงแอปพลิเคชันต่างๆ ภายในบริษัทที่อาจอยู่บนแพลตฟอร์มที่แตกต่างกันด้วย เทคโนโลยีที่ไม่เหมือนใคร

ด้วยการสร้างกระบวนการอัตโนมัติเพื่อสร้างการส่งมอบแพลตฟอร์มจากไฟล์การออกแบบในที่เก็บ GitHub เราได้แก้ปัญหาสมมติส่วนใหญ่ของฉัน

ตอนนี้เรามีพื้นที่เก็บข้อมูล GitHub ส่วนกลางพร้อมพจนานุกรมสไตล์ของเราที่จัดการและส่งออกโทเค็นการออกแบบเราจะต้องจบปัญหาด้วยการหาวิธีที่ดีที่สุดสำหรับแอปพลิเคชันต่างๆ เพื่อใช้การส่งมอบแพลตฟอร์ม โทเค็นการออกแบบที่ส่งออกสำหรับเทคโนโลยีเฉพาะ

กล่าวอีกนัยหนึ่ง เราจำเป็นต้องหาวิธีส่งมอบโทเค็นการออกแบบในหลายๆ แอปพลิเคชันภายในบริษัทสมมติ ด้วยวิธีนี้ จะมีกระบวนการอัตโนมัติเพื่อแสดงการเปลี่ยนแปลงในไฟล์การออกแบบทั่วทั้งบริษัท

บทความนี้จะไม่ใช่บทช่วยสอนเหมือนกับบทก่อนหน้า และเป็นการอภิปรายเพิ่มเติมเกี่ยวกับแนวทางปฏิบัติที่ดีที่สุด แม้ว่าฉันจะมีตัวอย่างโค้ดสำหรับแต่ละแบบฝึกหัดเพื่อให้การอภิปรายย่อยง่ายขึ้น

การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ด้วย GraphQL

เมื่อผมเจอระบบการออกแบบ Polaris ของ Shopifyสำหรับบทความที่แล้ว ผมสังเกตเห็นว่าพวกเขาเปิดโปงGraphQL API ที่ให้บริการโทเค็นการออกแบบ.

ในฐานะแฟนตัวยงของ GraphQL สิ่งนี้น่าสนใจมาก แต่ก็ฟังดูเหมือนมีค่าใช้จ่ายที่ไม่จำเป็นมากมายในการสร้าง API เพื่อส่งมอบรายละเอียดการออกแบบ

อย่างไรก็ตาม ฉันคิดว่าถ้าคุณมี style dictionary ในที่เก็บ GitHub ส่วนกลาง เราก็ไม่ต้องสร้าง GraphQL API ของเราเอง

แทนที่เราสามารถใช้GraphQL API ของ GitHubเพื่ออ่านการส่งมอบแพลตฟอร์มในเอาต์พุตโฟลเดอร์ของที่เก็บนั้น ในทางทฤษฎี การส่งมอบที่อ่านได้สามารถจัดเก็บได้โดยใช้ API ระบบไฟล์ของเทคโนโลยี

ตัวอย่างเช่น พื้นที่เก็บข้อมูลสำหรับแอปพลิเคชัน Vue อาจมีสคริปต์โหนดที่ดึงข้อมูลที่ส่งมอบได้ในพจนานุกรมสไตล์โดยใช้ GitHub GraphQL API และเขียนลงในไฟล์ในเครื่องโดยใช้API ระบบไฟล์โหนด.

ตอนนี้ คุณอาจคุ้นเคยกับการเรียก API เพื่อโหลดข้อมูลในขณะที่แอปพลิเคชันของคุณทำงานอยู่วิ่ง. อย่างไรก็ตาม สิ่งที่ฉันแนะนำคือการเรียก API ของคุณเมื่อแอปพลิเคชันของคุณสร้างก่อนที่มันจะทำงาน

แอปพลิเคชันสร้างขึ้นในขณะที่คุณพัฒนาในเครื่องและก่อนที่จะนำโค้ดใหม่ไปใช้ในการผลิต

ดังนั้นควรเรียกใช้ Node script ที่ฉันกล่าวถึงข้างต้นที่ไหนและเมื่อใด

(Video) Live demo: Design Tokens using Style-Dictionary & Figma

หากมีการเรียกใช้เฉพาะในกระบวนการปรับใช้ ก่อนที่โค้ดใหม่จะถูกปรับใช้กับไซต์ที่ใช้งานจริง จะไม่มีวิธีใดในการเข้าถึงโทเค็นในขณะที่พัฒนาในเครื่อง ซึ่งจะส่งผลให้โทเค็นการออกแบบไม่ถูกใช้งานซึ่งไม่สมเหตุสมผล

อย่างไรก็ตาม หากมีการดึงโทเค็นการออกแบบในขณะที่กำลังพัฒนาแบบโลคัลและขณะปรับใช้กับการผลิต แสดงว่ามีความเสี่ยงที่โทเค็นที่ปรับใช้ไม่ตรงกับที่นักพัฒนาเห็นในโลคัล นี่อาจเป็นปัญหาเรื่องเวลาที่หายาก แต่ก็มีความเสี่ยง

หากมีการดึงโทเค็นการออกแบบในขณะที่พัฒนาในเครื่อง สคริปต์จะเขียนโทเค็นลงในโฟลเดอร์ และโฟลเดอร์นั้นถูกผูกมัดกับต้นทางของที่เก็บ ก็จะไม่มีความเสี่ยงที่จะเกิดความแตกต่างระหว่างการพัฒนาในเครื่องและไซต์ที่ใช้งานจริง

ความเสี่ยงในแนวทางนี้คือการทำให้มั่นใจว่าแอปพลิเคชันทั้งหมดในบริษัทมีสคริปต์การทำงานที่อ่านและเขียนแพลตฟอร์มที่ส่งมอบได้ในพจนานุกรมรูปแบบส่วนกลาง นอกจากนี้ จะมีความรับผิดชอบในการเข้าถึงแต่ละแอปพลิเคชันเพื่อรวมเวิร์กโฟลว์นี้เข้ากับประสบการณ์การพัฒนา

ฉันไม่สามารถทำซ้ำตัวอย่างที่เป็นไปได้ทั้งหมดภายในแอปพลิเคชันเฉพาะแพลตฟอร์มเดียว ไม่ต้องพูดถึงแอปพลิเคชันและเทคโนโลยีเฉพาะแพลตฟอร์มต่างๆ ทั้งหมดที่มีอยู่

อย่างไรก็ตาม ให้ฉันใช้แอปพลิเคชัน React เป็นตัวอย่างในการรวมการใช้โทเค็นการออกแบบเข้ากับประสบการณ์การพัฒนา

ฉันมีสองวิธีแก้ปัญหาที่อยู่ในใจ

การดึงโทเค็นการออกแบบโดยใช้โหนดและฮัสกี้

ทางออกแรกคือการใช้ประโยชน์จากเริ่มต้นสคริปต์ NPM ล่วงหน้า.

ตามชื่อหมายถึงเริ่มต้นล่วงหน้าสคริปต์ NPM ถูกทริกเกอร์ก่อนที่จะรันเริ่มต้น npm.

NPM เรียกสิ่งนี้ว่าสคริปต์ "วงจรชีวิต" เนื่องจากเป็นสคริปต์ที่ดำเนินการตามวงจรชีวิตของสคริปต์ "เริ่มต้น"

เราสามารถมีเริ่มต้นล่วงหน้าเรียกใช้สคริปต์โหนดที่ดึงโทเค็นการออกแบบผ่าน GitHub GraphAQL API และเขียนโทเค็นไปยังโฟลเดอร์ในเครื่อง (ตามที่แนะนำก่อนหน้านี้)

เนื่องจาก Node script จะทำงานก่อนแต่ละอันเริ่มต้น npmเราสามารถรวมเวิร์กโฟลว์เพื่อดึงโทเค็นการออกแบบซึ่งเป็นส่วนหนึ่งของกระบวนการเริ่มต้นของแอปพลิเคชันของเรา

กระบวนการทำงานนี้เริ่มต้น npmเป็นเรื่องปกติอยู่แล้วสำหรับการพัฒนาในพื้นที่ในฐานะนักพัฒนา JavaScript อย่างไรก็ตาม อาจมีภาระเพิ่มเติมสำหรับนักพัฒนาในการรีสตาร์ทแอปพลิเคชันเมื่อสลับไปมาระหว่างสาขา (ทำงานกับคุณลักษณะใหม่)

ความเครียดเพิ่มเติมนี้สามารถแก้ไขได้โดยใช้ฮัสกี้ไลบรารีที่ให้คุณเชื่อมต่อกับเหตุการณ์ Git (push, pull ฯลฯ) และเรียกใช้สคริปต์ NPM

โดยเฉพาะอย่างยิ่ง Husky สามารถเชื่อมต่อได้เมื่อนักพัฒนาเปลี่ยนจากสาขาหนึ่งไปยังอีกสาขาหนึ่งในพื้นที่เก็บข้อมูล เมื่อเป็นเช่นนั้น สคริปต์โหนดสำหรับอ่านและเขียนโทเค็นการออกแบบจะถูกเรียกอีกครั้ง

(Video) How to create Design Tokens in Figma with Figma Tokens - Tutorial with Jan Six

ฉันรวบรวมตัวอย่างเพื่อให้คุณเห็นภาพสิ่งที่ฉันอธิบาย:https://github.com/michaelmang/consume-style-dictionary-node/commits/master

การจัดหาโทเค็นการออกแบบด้วย Gatsby

โซลูชันที่สองคือแหล่งที่มาจาก GitHub GraphQL API ในระบบนิเวศของ Jamstack เช่น Gatsby

คุณสามารถมีแหล่งที่มาของแอปพลิเคชัน Gatsby จาก GitHub API ซึ่งอ่านจากที่เก็บพจนานุกรมสไตล์ โทเค็นการออกแบบจะพร้อมใช้งานผ่านชั้นข้อมูล GraphQL ของ Gatsby

การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ (1)

ด้วยความช่วยเหลือของปลั๊กอินที่เรียกว่าgatsby-แหล่งที่มา-github-apiฉันสามารถอ่านเนื้อหาของไฟล์ที่ส่งมอบแพลตฟอร์มได้จากพจนานุกรมสไตล์ เช่น_variables.css

ดังที่คุณเห็นในกราฟิกด้านบนเนื้อหากลับมาเป็นข้อความธรรมดา.

ด้วยการกำหนดค่าเพิ่มเติมด้วย Gatsby เราจะสามารถแปลงข้อความธรรมดานี้เป็นรูปแบบที่ดีขึ้นได้

แกสบี้เผยกแกสบี้-node.jsไฟล์ไปที่ทำสิ่งต่างๆ ด้วยชั้นข้อมูล GraphQL ในระหว่างวงจรชีวิตการสร้าง.

มีสองวิธีในการทำความเข้าใจ "โหนด" ใน Gatsby ประการแรกแกสบี้-node.jsทำให้เราสามารถเขียนโค้ดเพื่อทำสิ่งต่างๆ กับชั้นข้อมูลโดยใช้ Node ประการที่สอง "โหนด" หมายถึง "แผนผังข้อมูล" แผนผังข้อมูลเป็นวิธีการแสดงภาพการจัดระเบียบข้อมูลในวิทยาการคอมพิวเตอร์:

การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ (2)

ใน Gatsby ชั้นข้อมูล (ซึ่งคุณสามารถสำรวจและค้นหาโดยใช้ GraphQL explorer ที่เปิดใช้งานเมื่อพัฒนาแอปพลิเคชัน Gatsby ในเครื่อง) ประกอบด้วย "โหนด"

ในกราฟิกของ GraphQL explorer ที่ฉันโพสต์ไว้ด้านบน มีโหนดที่แสดงผลลัพธ์แต่ละรายการจากการสืบค้น GraphQL ของ GitHub API:

{ allGithubData { โหนด { rawResult { ข้อมูล { ที่เก็บ { เนื้อหา { รายการ { วัตถุ { ข้อความ } } } } } } }}

ในแบบสอบถามข้างต้นข้อความเป็นข้อมูลภายในโหนด

Gatsby เปิดเผย API ที่สามารถใช้ในแกสบี้-node.jsไฟล์เพื่อแปลงข้อมูลในโหนด GitHub โดยเฉพาะอย่างยิ่ง เราสามารถใช้onCreateNode APIเพื่อแปลงร่างข้อความโหนดซึ่งเป็นแพลตฟอร์มที่ส่งมอบได้ซึ่งแสดงเป็นข้อความล้วน ในหลายโหนดที่แสดงถึงโทเค็นการออกแบบ:

การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ (3)

(Video) What are Design Tokens in Figma?

นี่คือวิธีที่ฉันนำไปใช้:https://github.com/michaelmang/consume-style-dictionary-gatsby/commits/master

ด้วยวิธีนี้ คุณไม่จำเป็นต้องคัดลอกโทเค็นการออกแบบในเครื่อง เนื่องจากโทเค็นการออกแบบควรจะพร้อมใช้งานเมื่อคุณสร้างแอปพลิเคชันทั้งแบบโลคัลและก่อนการปรับใช้ สิ่งนี้ไม่ได้ป้องกันปัญหาเรื่องเวลาที่ฉันพูดถึงก่อนหน้านี้ แต่เป็นการจับคู่ที่น่าพอใจ

โทเค็นการออกแบบสามารถสอบถามจากส่วนประกอบที่ใช้เครื่องมือในตัวของ Gatsby.

ความคิดเกี่ยวกับแนวทางนี้

อันดับแรก โปรดจำไว้ว่า GraphQL อาจไม่ใช่วิธีที่ดีที่สุดในการสื่อสารข้อมูลระหว่างแพลตฟอร์มและเทคโนโลยีต่างๆ ที่พจนานุกรมสไตล์รองรับ ด้วยเหตุนี้ คุณจึงสามารถใช้ REST API ของ GitHub ได้ ข้อดีและข้อเสียของวิธีนี้จะยังคงอยู่

ประการที่สอง หากการแปลงข้อความเป็นโหนดโทเค็นการออกแบบแต่ละโหนดนั้นมากเกินไป (และอาจดีมาก) คุณสามารถเขียนข้อความลงในไฟล์ CSS ได้ นอกจากนี้ยังจะทำในแกสบี้-node.jsโดยใช้ Node file system API

สุดท้าย แม้ว่าการสร้างตัวอย่างโค้ดสำหรับวิธีการเหล่านี้เป็นเรื่องสนุก (โดยเฉพาะปลั๊กอิน Gatsby transformer) ฉันคิดว่าแนวทางที่ดีกว่าเกิดขึ้นเมื่อคุณเปลี่ยนกระบวนทัศน์จากแอปพลิเคชันของคุณ "บริโภค" การส่งมอบในพจนานุกรมสไตล์เป็นพจนานุกรมสไตล์ "ส่งมอบ" ส่งมอบ

การส่งมอบโทเค็นการออกแบบ

ในบทความก่อนหน้านี้ฉันสร้างเวิร์กโฟลว์ GitHub Actions ในไฟล์พจนานุกรมสไตล์พื้นที่เก็บข้อมูล:

คุณสามารถดูเวิร์กโฟลว์ได้ที่นี่:https://github.com/michaelmang/style-dictionary/blob/exporting-design-tokens-from-figma-with-style-dictionary/.github/workflows/export-tokens-on-input.yml

เวิร์กโฟลว์นี้ถูกเรียกใช้เมื่อใดก็ตามที่ได้รับไฟล์โทเค็นการออกแบบใหม่จาก Figma

เวิร์กโฟลว์นี้สร้างไฟล์ JSON ที่แสดงโทเค็นการออกแบบจาก Figma โดยใช้ Style Dictionary และยอมรับการส่งมอบแพลตฟอร์มที่สร้างขึ้น

การส่งมอบแพลตฟอร์มที่สร้างขึ้นเหล่านี้ถูกจัดเก็บไว้ในเอาต์พุตโฟลเดอร์

เราสามารถโยงเวิร์กโฟลว์ใหม่ออกจากเวิร์กโฟลว์ก่อนหน้านี้ซึ่งถูกเรียกใช้เมื่อใดก็ตามที่เอาต์พุตโฟลเดอร์ได้รับการปรับปรุงด้วยเนื้อหาใหม่

เมื่อสิ่งนี้เกิดขึ้น เราจะดำเนินการบางอย่างที่คัดลอกไฟล์จากเอาต์พุตโฟลเดอร์และส่งไปยังที่เก็บข้อมูลของแอปพลิเคชันที่ใช้พจนานุกรมสไตล์ส่วนกลาง

เนื่องจากแต่ละแอปพลิเคชันจะสนใจรับเฉพาะประเภทของแพลตฟอร์มที่ส่งมอบซึ่งสร้างโดย Style Dictionary เราจึงสามารถสร้าง "งาน" แยกต่างหากสำหรับแต่ละแอปพลิเคชันได้

งานใน GitHub Actionsทำงานแบบขนานโดยค่าเริ่มต้น.

(Video) Customer กับ Client ต่างกันอย่างไร ? ศัพท์ภาษาอังกฤษ Business English และ โทอิค - TOEIC Kru Poom

ดังนั้น ในการผลักดันการส่งมอบแพลตฟอร์มใหม่ แต่ละแอปพลิเคชันที่ต้องใช้หนึ่งในการส่งมอบเหล่านี้จะมีงานในเวิร์กโฟลว์เพื่อคัดลอกการส่งมอบที่จำเป็นไปยังที่เก็บ

นี่หมายความว่าสำหรับทุกแอปพลิเคชันใหม่ที่ใช้พจนานุกรมสไตล์ เราจะต้องเพิ่มงานใหม่ในเวิร์กโฟลว์

อย่างไรก็ตาม เราต้องทำอยู่แล้วอัปเดตการกำหนดค่า Style Dictionary ทุกครั้งที่เราต้องการให้สร้างแพลตฟอร์มใหม่ที่ส่งมอบได้. เรากำลังเพิ่มขั้นตอนในการดำเนินการ

การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ (4)

การใช้โทเค็นการออกแบบจากพจนานุกรมสไตล์ (5)

นี่คือตัวอย่างของฉันที่คัดลอก_variables.scssการส่งมอบที่สร้างโดย Style Dictionary ไปยังแอปพลิเคชัน React:https://github.com/michaelmang/style-dictionary/pull/3

และที่เก็บแอ็พพลิเคชันตัวอย่างที่มีการคัดลอกการส่งมอบไปยัง:https://github.com/michaelmang/consume-style-dictionary-github-actions

ฉันใช้ประโยชน์จากขั้นตอนการดำเนินการที่กำหนดไว้ล่วงหน้าสำหรับการคัดลอกสิ่งที่ส่งมอบไปยังที่เก็บอื่น.

ความคิดเกี่ยวกับแนวทางนี้

ข้อแม้เพียงอย่างเดียวคือต้องใช้สภาพแวดล้อมเสมือนจริงของ Linux อย่างไรก็ตาม การเขียนขั้นตอนการดำเนินการของคุณเองอาจไม่ใช่เรื่องยากเกินไปหากเป็นปัญหา

ข้อแม้อีกประการหนึ่งคือใช้ HTTPS เพื่อโคลนและพุชไปยังที่เก็บของคุณคุณจะต้องตรวจสอบให้แน่ใจว่า URL ระยะไกลสำหรับการบริโภคคือ HTTPS ไม่ใช่ SSH.

โดยรวมแล้ว ฉันคิดว่ามันเป็นตัวเลือกที่ดีกว่ามากในการคิดที่จะส่งมอบ/จัดส่งแพลตฟอร์มที่ส่งมอบให้กับแอปพลิเคชันที่ใช้ทั้งหมด แทนที่จะให้แอปพลิเคชันทั้งหมดจัดการเพื่อใช้งานแพลตฟอร์มที่ส่งมอบ

วิธีนี้ยังทิ้งบันทึกของแอปพลิเคชันที่ใช้งานทั้งหมด เนื่องจากแต่ละแอปพลิเคชันมีงานของตัวเองที่บันทึกไว้ในเวิร์กโฟลว์

บทสรุป

ขอแสดงความยินดี คุณมีทักษะทั้งหมดที่จำเป็นในการทำให้กระบวนการรับไฟล์การออกแบบเป็นไปโดยอัตโนมัติและส่งมอบโทเค็นการออกแบบในแอปพลิเคชันจำนวนมาก ไม่ว่าจะเป็นแพลตฟอร์มใดและเทคโนโลยีใดก็ตาม 🎉

อาจมีวิธีอื่นในการแก้ปัญหาระบบอัตโนมัติ หรือคุณอาจมีแนวคิดที่ดีกว่าในการแจ้งแนวทางปฏิบัติที่ดีที่สุด โดยเฉพาะอย่างยิ่งเมื่อพิจารณาว่าปัญหาเหล่านี้มีขนาดที่ใหญ่กว่าบทความจะครอบคลุมได้

เพื่อนร่วมงานคนหนึ่งเคยบอกฉันว่าส่วนที่ดีที่สุดของการเขียนโค้ดคือเมื่อคุณทำการรีแฟคเตอร์ มีความจริงบางอย่างเกี่ยวกับสิ่งนั้น ฉันหวังว่าจะไม่ได้ให้วิธีแก้ปัญหาทั้งหมดในบทความนี้หรือแนวทางปฏิบัติที่ดีที่สุดสำหรับทุกสถานการณ์ แต่ให้ทักษะและแรงบันดาลใจบางอย่างเพื่อให้คุณสนุกกับการปรับโครงสร้างกระบวนการโทเค็นการออกแบบใหม่

(Video) กฎการเขียน Mind Map

ในบทความถัดไป เราจะเรียนรู้วิธีสร้างเฉดสีของธีมโทเค็นการออกแบบด้วย Style Dictionary

พาว แชร์ และพูดคุย

Videos

1. Figma Tokens first steps of collaboration with other plugin makers - Esther Cheran
(Into Design Systems)
2. Stratos Tokens & Style Dictionary - How to update an iOS app
(Sketch2React)
3. สิทธิศักดิ์ อาจารย์สอน ตัดต่อ
(สิทธิศักดิ์ โพธิ์ประสาท)
4. สายตรวจภาษา / 81 - ชอุ่ม
(ETV สื่อดิจิทัลเพื่อการศึกษา)
5. Design Tokens in Figma: How to get started, today. Jan Six - Live & Q&A- Into Design Systems
(Into Design Systems)
6. evaluation ออกเสียงว่า แปลว่า อะไร แปลภาษาอังกฤษเป็นไทย By ENCONCEPT Dictionary
(ENCONCEPT DICTIONARY L)

References

Top Articles
Latest Posts
Article information

Author: Van Hayes

Last Updated: 06/26/2023

Views: 5837

Rating: 4.6 / 5 (66 voted)

Reviews: 81% of readers found this page helpful

Author information

Name: Van Hayes

Birthday: 1994-06-07

Address: 2004 Kling Rapid, New Destiny, MT 64658-2367

Phone: +512425013758

Job: National Farming Director

Hobby: Reading, Polo, Genealogy, amateur radio, Scouting, Stand-up comedy, Cryptography

Introduction: My name is Van Hayes, I am a thankful, friendly, smiling, calm, powerful, fine, enthusiastic person who loves writing and wants to share my knowledge and understanding with you.