ส่วนที่ 3: กลยุทธ์โดยรวมและสถาปัตยกรรมพื้นฐาน

คุณสามารถอ่านบทความก่อนหน้าของซีรี่ส์นี้ได้ "ที่นี่"

ห้องสมุด

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

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

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

คอยติดตาม ;)

ข้อควรพิจารณาบางประการ

ฉันได้ชี้ไปที่ข้อเสียบางประการของแนวทาง Canvas:

  1. ไม่มีการเพิ่มประสิทธิภาพกลไกค้นหา (เนื่องจากข้อความเป็นรูปภาพ) จริง. บางทีเราอาจพบวิธีแก้ปัญหาในอนาคต
  2. ไม่มีการแปลภาษาโดยเบราว์เซอร์ จริง. แม้ว่า Google, Mozilla, Microsoft และ AWS จะไม่พึ่งพาการแปลเบราว์เซอร์ พวกเขาสร้างเวอร์ชันของแต่ละหน้าสำหรับแต่ละภาษาที่พวกเขากำหนดเป้าหมาย แต่โอเค เรามีเว็บไซต์เล็กๆ การแปลอัตโนมัติจะช่วยเราประหยัดเวลาและเงินได้มาก นอกจากนี้ Chrome เวอร์ชันปัจจุบัน (สำหรับเดสก์ท็อปของฉัน) จะไม่ยุ่งกับปุ่มเมนูของแอปเก่านั้นอีกต่อไป (ฉันไม่รู้เกี่ยวกับอุปกรณ์ X เบราว์เซอร์อื่น)
  3. เราต้องให้บริการแผ่นฟอนต์ มีปริมาณการรับส่งข้อมูลมากขึ้นและมีสิ่งอื่นๆ สำหรับแคชของลูกค้า จริง. แต่ก็ไม่มาก และเราให้บริการในแพ็คเกจเดียว
  4. ไม่มีโอกาสสำหรับโปรแกรมอ่านหน้าจอ จริง. แต่เรากำลังใช้ผืนผ้าใบสำหรับป้ายกำกับของปุ่มและส่วนควบคุมอื่นๆ ไม่ควรใช้กับข้อความ (ยาว) อย่างไรก็ตาม ZIM จะจัดการโปรแกรมอ่านหน้าจอโดยการวางข้อความ HTML ไว้ด้านหลังผืนผ้าใบ
  5. เราไม่สามารถซูมเข้าได้ มันไม่ดีต่อการเข้าถึง จริงๆ แล้ว เราสามารถซูมเข้าออกได้ โดยไม่ทำให้เลย์เอาต์หรือฟังก์ชันการทำงานใดๆ เสียหาย แค่ตัวละครก็จะดูไม่ดีเท่าไหร่
  6. มันหมายถึงงานมาก นั่นคือเหตุผลว่าทำไมฉันถึงจะปล่อยห้องสมุดเพื่อจัดการเรื่องทั้งหมดนี้
  7. หน้านี้จะไม่ปรับขนาดหน้าจอโดยอัตโนมัติ ขึ้นอยู่กับว่าเราตั้งโปรแกรมไว้อย่างไร

กลยุทธ์โดยรวม

กฎทองคือ ยึดติดกับ HTML/CSS ทุกครั้งที่เหมาะสมกับคุณ

ใช้แนวทาง Canvas เมื่อคุณต้องการ เมื่อคุณต้องการแน่ใจอย่างแน่นอนว่าแต่ละเบราว์เซอร์ในแต่ละอุปกรณ์จะแสดงสิ่งที่คุณวางแผนไว้อย่างแน่นอน เมื่อแอปของคุณมีความต้องการมากขึ้น ดูคำตอบนี้โดย Hans Garon:

ฉันใช้ Canvas เพื่อวาดภาพหน้าเว็บโดยสมบูรณ์ สาเหตุหลักมาจาก UI เลียนแบบ UI ของแอปพลิเคชันแบบเนทีฟ และต้องการอินสแตนซ์จำนวนมาก (หลายพัน) ของวิดเจ็ตเฉพาะที่มีคุณสมบัติพัฒนาอย่างต่อเนื่อง นี่เป็นสิ่งที่ไม่ใช่การเริ่มต้นสำหรับเบราว์เซอร์ แต่การใส่ลงในโครงสร้างข้อมูลนั้นค่อนข้างง่าย แม้จะส่งต่อไปยังโมดูล Wasm เพื่อรับการอัปเดต จากนั้นเพียงส่งไปที่ Canvas เพื่อลงสี

เราควรใช้ HTML/CSS สำหรับหน้าแรก: ไม่มีปัญหากับ SEO, ไม่มีปัญหากับการแปลอัตโนมัติ, ไม่มีปัญหากับโปรแกรมอ่านหน้าจอ

สำหรับแอปสไตล์ Canvas เราจะต้องมีเวอร์ชันที่แตกต่างกันอย่างน้อย 3 เวอร์ชัน (หน้าจอเล็ก ปานกลาง และใหญ่) วิธีที่มีประสิทธิภาพที่สุดคือการสร้างหน้าต่างๆ (หรือหน้าเดียวที่เลือกไฟล์ JavaScript ที่ถูกต้อง) ฉันจะไม่สร้างโค้ด JavaScript เดียวสำหรับทุกสถานการณ์ มันยุ่งเกินไป!

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

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

สถาปัตยกรรมพื้นฐาน

ไม่มีแล้ว บลา บลา บลา!

ร่างกาย

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

องค์ประกอบ

องค์ประกอบของเราคล้ายกับองค์ประกอบ HTML (แท็ก) ร่างกายไม่ถือว่าเป็นธาตุ แต่เป็นร่างกาย ภาชนะอันสูงสุด

เลเยอร์

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

องค์ประกอบภายในเลเยอร์ต้องไม่ทับซ้อนกัน

const allLayers = [ ]
function createLayer(id) {
    //
    const layer = new Layer(id)
    Object.seal(layer)
    //
    allLayers.push(layer)
    return layer
}
function Layer(id) {
    this.id = id
    this.visible = true
    this.left = 0
    this.top = 0
    this.width = 300
    this.height = 200
    this.opacity = 1
    this.background = null // "white"
    // more attributes here
    this.elements = [ ]
}

กลไกจะพิมพ์เลเยอร์ตามลำดับที่อยู่ในรายการ allLayers แต่ใช้เหตุการณ์ของเมาส์ในลำดับตรงกันข้าม

ใน CSS คุณสมบัติ z-index เทียบเท่ากับแนวคิดเรื่องเลเยอร์ของเรา

ฉันไม่ชอบคุณสมบัติ CSS z-index เนื่องจากเหตุผลสามประการ:

  1. เช่นเดียวกับทุกสิ่งใน CSS คำจำกัดความอาจกระจัดกระจายไปทุกที่ ฉันไม่สามารถมองเห็น "ภาพใหญ่" ได้ ดังนั้นฉันจึงไม่มั่นใจว่าทุกอย่างจะเรียบร้อย
  2. เมื่อฉันต้องการแทรกเลเยอร์ใหม่ ฉันอาจต้องจัดทำดัชนีองค์ประกอบอื่นๆ มากมายใหม่ มันไม่ใช่แค่งานเท่านั้น มันเป็นความเสี่ยงที่จะเกิดข้อผิดพลาด
  3. ดัชนี z ใช้ได้เฉพาะกับองค์ประกอบที่มีตำแหน่ง (ตำแหน่ง: สัมบูรณ์ ตำแหน่ง: สัมพันธ์ ตำแหน่ง: คงที่ หรือตำแหน่ง: เหนียว) และรายการดิ้น (องค์ประกอบที่เป็นลูกโดยตรงของ จอแสดงผล: องค์ประกอบดิ้น)

ใช่! CSS ซับซ้อนเกินไปสำหรับฉัน

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

เนื้อหาเพิ่มเติมได้ที่ PlainEnglish.io ลงทะเบียนเพื่อรับ จดหมายข่าวรายสัปดาห์ฟรี ของเรา ติดตามเราบน Twitter และ LinkedIn เข้าร่วม ความไม่ลงรอยกันของชุมชน ของเรา