เคล็ดลับการย้ายข้อมูล Vue 3 5 ข้อ

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

Vue 3 นำการเปลี่ยนแปลงมากมายมาสู่โต๊ะ TypeScript เขียนใหม่, Composition API, แฟรกเมนต์, การรองรับ JSX ที่ได้รับการปรับปรุง — นั่นเป็นเพียงบางส่วนจากตัวเลือกอันดับต้นๆ ของฉัน ไม่น่าแปลกใจเลยว่าทำไมนักพัฒนาจำนวนมากถึงกระโดดขึ้นรถไฟอย่างเต็มกำลังแม้ว่าสถานะเบต้าจะคงอยู่ก็ตาม

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

ในฐานะคนที่ค่อนข้างจะอยู่ระหว่าง 2 คนนี้ ฉันมีเคล็ดลับสำหรับทั้งสองกลุ่ม ฉันเคยทำงานอย่างกว้างขวางกับ Vue 2 และระบบนิเวศของมันในอดีต และเพิ่งกลับมาใช้ Vue 3 เพื่อขับเคลื่อนเครื่องมือเขียนบล็อกโค้ด CodeWrite ของฉัน ประสบการณ์นี้ทำให้ฉันได้เห็นการโยกย้าย Vue 2 — Vue 3 เป็นพิเศษ ซึ่งวันนี้ฉันอยากจะแบ่งปันกับคุณในรูปแบบของ เคล็ดลับ ที่เป็นประโยชน์และแสดงความคิดเห็น!

1. คำนึงถึงระบบนิเวศ

ฉันคิดว่าเอกสาร "การโยกย้ายอย่างเป็นทางการ" ไม่ได้เน้นเรื่องนั้นเพียงพอ Vue 3 ยังคงรักษาส่วนสำคัญของ Vue 2 API ไว้เหมือนเดิม แต่ยังคงมีการเปลี่ยนแปลงที่สำคัญอยู่บ้าง และเนื่องจากการเปลี่ยนแปลงเหล่านี้ คุณจะไม่สามารถเข้าถึงระบบนิเวศ Vue 2 ทั้งหมดได้

ตอนนี้นั่นเป็นข้อเสียเปรียบร้ายแรง หากคุณพึ่งพาไลบรารี Vue 2-centric ของบริษัทอื่น คุณจะต้องรอให้อัปเดตหรือแก้ไขด้วยตนเอง เมื่อใช้ เช่น Vuetify (โดยที่ Vue 3 รองรับ ปัจจุบันอยู่ในเวอร์ชันอัลฟ่า) ตัวเลือกที่สองไม่ใช่ตัวเลือกจริงๆ และคุณจะต้องรอ จนกว่าจะได้รับการอัปเดต

เมื่อฉันเริ่มต้น CodeWrite แบบ "สดใหม่" ฉันไม่ได้มีความผูกพันกับระบบนิเวศใด ๆ ที่รั้งฉันไว้ ถึงกระนั้น ผลกระทบก็เห็นได้ชัดเจน และฉันก็ถูกจำกัดอย่างมากในการเลือกเครื่องมือ อย่างไรก็ตาม หลังจากใช้เวลาค้นหาทางเลือกที่ไม่ขึ้นอยู่กับเฟรมเวิร์กและใช้ Tailwind CSS เป็น “ทางเลือกไลบรารีส่วนประกอบ UI” ของฉัน ฉันสามารถได้รับประโยชน์จาก Vue 3 ความเป็นอิสระของเฟรมเวิร์ก และทุกสิ่งที่ฉัน จำเป็นต้องสร้าง CodeWrite ขึ้นมา

2. จัดการกับการเปลี่ยนแปลงที่ทำลายล้าง

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

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

คุณสามารถดูรายการ "การเปลี่ยนแปลงด่วนในเอกสารอย่างเป็นทางการ" ทั้งหมดได้ ที่ใหญ่ที่สุดคือ:

• การเปลี่ยนแปลง Global API และการปรับโครงสร้างใหม่แบบ Tree-Shakable
• การเปลี่ยนแปลงพฤติกรรม v-model (อาจเป็นปัญหาได้)
• destroyed และ beforeDestroy เปลี่ยนชื่อเป็น unmount และ beforeUnmount ตามลำดับ
• การเปลี่ยนแปลงทั่วไปใน API ภายในและ "ระดับล่าง" (เกี่ยวข้องเฉพาะเมื่อคุณใช้ฟังก์ชันแบบกำหนดเองบางอย่างที่โต้ตอบกับ API เหล่านี้ใน Vue 2)

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

3. นำคุณสมบัติใหม่มาใช้ทีละน้อย (แต่เร็ว)

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

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

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

สำหรับ Vue 3 ตัวอย่างของการเปลี่ยนแปลง "ทั่วทั้งโค้ด" จะเป็น Composition API ใหม่หรือ <script setup> syntax sugar แน่นอนว่าการแปลงจาก Options API ไปเป็น Composition API อาจดูเหมือนเป็นงานอัตโนมัติที่ "ไร้เหตุผล" แต่จะง่ายขึ้นมากขึ้นเมื่อคุณแปลงส่วนประกอบหนึ่งหรือสองชิ้น

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

4. วางแผนล่วงหน้าอย่างกล้าหาญ

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

ก่อนอื่น ฉันหมายถึงอะไรโดย "การเคลื่อนไหวที่กล้าหาญ"? ตัวอย่างเช่น การนำ TypeScript มาใช้ Vue 3 ได้รับการเขียนใหม่โดยใช้มัน และตอนนี้การรองรับก็ยอดเยี่ยมมาก เช่นเดียวกันอาจกล่าวได้สำหรับห้องสมุดอย่างเป็นทางการอื่นๆ และอาจนำไปใช้กับระบบนิเวศใหม่ส่วนใหญ่ที่กำลังสร้างหรืออัปเดตสำหรับ Vue 3

ตอนนี้การนำ Composition API มาใช้หรือแม้กระทั่งที่บ้าคลั่งกว่า - JSX (รองรับ "ดีขึ้นด้วย") - ก็เป็นการเคลื่อนไหวที่กล้าหาญเช่นกัน สำหรับฉัน - ไม่ นั่นเป็นเพราะว่าส่วนใหญ่แล้วเป็นเพียงการนำคุณลักษณะใหม่มาใช้ — สิ่งที่คาดหวังในระหว่างการอัปเกรด แต่ที่สำคัญที่สุด — เนื่องจากจะมีผลเฉพาะส่วน “มุมมอง” ของโครงการของคุณ

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

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

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

5. เริ่มเลย

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

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

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

บรรทัดล่าง

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

ฉันหวังว่าคุณจะพบว่าบทความนี้มีประโยชน์ หากเป็นเช่นนั้น ติดตามฉันบน Twitter, Facebook หรือทาง จดหมายข่าวของฉัน (ตอนนี้รีบูทแล้ว!) เพื่อดูเนื้อหา Vue และการพัฒนาเว็บเพิ่มเติม

นอกจากนี้ หากคุณเป็นบล็อกเกอร์ทางเทคนิคเช่นฉัน ลองลองใช้เครื่องมือ CodeWrite —“code-blogging”ฟรี ซึ่งจัดการตัวอย่างข้อมูลของคุณด้วยเครื่องมือแก้ไขและจัดรูปแบบที่เหมาะสม ซึ่งทำงานได้อย่างสวยงาม ด้วย ไวยากรณ์ และจัดการการโพสต์ข้ามไปยัง Dev.to, Hashnode, Medium และ Ghost blogs พร้อมฟีเจอร์ เติมอัตโนมัติ ที่ยอดเยี่ยม ( ฉันพูดถึงมันเป็นส่วนขยายของเบราว์เซอร์หรือเปล่า) ซึ่งจัดการ "edge-cases" ทั้งหมดสำหรับคุณ (เช่น การแปลงโค้ดใน Medium เป็น GitHub Gist หรือการปรับขนาดรูปภาพขนาดใหญ่)

ขอบคุณสำหรับการอ่านและขอให้มีความสุขในการเขียนโค้ด!

โพสต์นี้เขียนขึ้นอย่างง่ายดาย ปรับให้ถูกต้องตามหลักไวยากรณ์ และโพสต์ข้ามโพสต์ได้ที่นี่ภายใน 1 คลิก ต้องขอบคุณ CodeWrite พร้อมด้วยเครื่องมือแก้ไขที่ยอดเยี่ยม การผสานรวมไวยากรณ์ที่ราบรื่น และ "การเผยแพร่ด้วยคลิกเดียว" ทดลองใช้ฟรี และใช้รหัส first100 เพื่อรับส่วนลด 20% การสมัครของคุณ (เพียง $2.40/เดือน!)