ทุกเรื่องที่คุณต้องรู้เกี่ยวกับ LIFF URL แบบใหม่
สำหรับนักพัฒนา LINE ในปี 2020 นี้ ผมคิดว่าคงไม่มีใครไม่รู้จัก LINE Front-end Framework หรือ LIFF และถ้าถามว่า LIFF URL หน้าตาเป็นแบบไหนบ้าง?
- ส่วนใหญ่คงตอบ https://liff.line.me/xxx-xxx หรือที่เรียกว่า Universal Link
- รองลงมาคงตอบ line://app/xxx-xxx หรือที่เรียกว่า LINE Scheme
- ส่วนน้อยคงตอบ https://line.me/R/app/xxx-xxx
แต่หากผมถามต่อว่า LIFF URL มีการทำงานอย่างไร เชื่อว่าคำตอบที่ได้น่าจะหลากหลายเลยหละ โดยเฉพาะอย่างยิ่งเมื่อวันที่ 29 มิ.ย ที่ผ่านมา ทาง LINE ได้คลอด LIFF SDK v2.3.0 ที่มาพร้อมกับการทำงานของ LIFF URL ที่เปลี่ยนไปแบบมีนัยสำคัญ
อย่างไรก็ตามผู้ใช้งาน LIFF ทั้งหมดยังคงใช้งานได้ตามปกติ ถึงแม้นักพัฒนาจะอัพเดท LIFF SDK เป็นเวอร์ชันล่าสุดแล้วก็ตาม เนื่องจากทาง LINE ทำการบ้านข้อนี้มาดี เพราะถ้าเราเข้าไปในหน้า LIFF detail ใน Developers console วันนี้ จะพบว่ามันมีส่วนที่ให้ตั้งค่าเพิ่มเข้ามา
ส่วนของการตั้งค่าที่เพิ่มมาตรงนี้ เราสามารถเลือกได้ว่าจะให้ LIFF URL ทำงาน แบบเดิม(Replace) หรือ แบบใหม่(Concatenate) ซึ่งที่บอกว่า LINE ทำการบ้านมาดี ก็เพราะ LIFF ที่เคยสร้างไปแล้วทั้งหมด จะได้ค่าเริ่มต้นเป็น Replace จึงเป็นสาเหตุที่ทุกคนยังไม่ได้รับรู้ถึงการทำงานของ LIFF URL ที่เปลี่ยนไป แต่หากเป็นการสร้าง LIFF app ใหม่ค่าเริ่มต้นจะเป็น Concatenate แล้วนะ
บทความนี้จะบอกทุกเรื่องที่เกี่ยวกับกลไกการทำงานของ LIFF URL ให้คุณได้รู้ พร้อมเผยเคล็ดลับที่คุณอาจไม่รู้มาก่อน โดยเนื้อหาหลักของบทความนี้จะประกอบไปด้วย
- ปัจจัยที่ทำให้การทำงานของ LIFF URL เป็นแบบใหม่
- ทดลอง LIFF URL แบบไม่ปรับแต่งใดๆ
- ทดลอง LIFF URL แบบแนบ Path, Query Parameter และ URL Fragment
- เทคนิคการแนบ Path, Query Parameter และ URL Fragment ไปกับ LINE Scheme
1. ปัจจัยที่ทำให้การทำงานของ LIFF URL เป็นแบบใหม่
การที่จะทำให้ LIFF URL ทำงานเป็นแบบใหม่นั้น จะต้องประกอบไปด้วย 2 ปัจจัย โดยจะขาดปัจจัยใดปัจจัยหนึ่งไปไม่ได้
1. ต้องเลือก Mode สำหรับ LIFF URL เป็นแบบ Concatenate
2. ใช้ LIFF SDK v2.3.0 หรือ ใหม่กว่า
- https://static.line-scdn.net/liff/edge/versions/2.3.0/sdk.js
- https://static.line-scdn.net/liff/edge/2/sdk.js
- https://static.line-scdn.net/liff/edge/2.1/sdk.js
หมายเหตุ: โปรดทราบว่า LIFF SDK ทั้ง 3 รูปแบบด้านบนนี้ ล้วนเป็น v2.3.0 แล้วทั้งสิ้น(ถึงแม้บางตัวหน้าตาจะดูไม่ใช่ก็ตาม)
ทั้งนี้เพื่อให้ทุกคนเข้าใจถึงความแตกต่างในการทำงานของ LIFF URL ทั้ง แบบเดิม และ แบบใหม่ ได้ง่ายขึ้น รวมถึงสามารถนำไปทดลองเองได้ ผมจึงได้สร้าง LIFF app ขึ้นมา 2 ตัวสำหรับ use case ต่างๆในลำดับถัดไป
- แบบใหม่: ที่เกิดจาก LIFF SDK v2.3.0 + Concatenate mode https://liff.line.me/1653575653-e9vXldMN
- แบบเดิม: ที่เกิดจาก LIFF SDK v2.3.0 + Replace mode https://liff.line.me/1653575653-8WwXMavK
2. ทดลอง LIFF URL แบบไม่ปรับแต่งใดๆ
2.1 เปิด LIFF URL แบบ Universal Link ใน LINE app
กรณีนี้ Destination URL ที่ได้จะเป็น Endpoint URL ที่มาครบทั้ง Path และ Query param ต่อท้ายด้วยค่าต่างๆของ LIFF ในรูปแบบของ URL fragment
2.2 เปิด LIFF URL แบบ Universal Link ใน External Browser
กรณีนี้ Destination URL ที่ได้จะเป็น Endpoint URL ที่มาครบทั้ง Path และ Query param แต่จะมีจุดต่างระหว่าง LIFF URL แบบใหม่ กับ แบบเดิม ตรงที่
- แบบใหม่ Destination URL จะตรงกับ Endpoint URL เป๊ะๆ
- แบบเดิม Destination URL จะมี liff.state ซึ่งเป็น query param เพิ่มเข้ามา
2.3 เปิด LIFF URL แบบ LINE Scheme ใน LINE app
กรณีนี้กลไกการทำงานจะเหมือนกับข้อ 2.1 ทุกประการ
หมายเหตุ: LIFF URL แบบ LINE Scheme นั้นจะสามารถทำงานได้เฉพาะกับแอป LINE ใน Android, iOS และ iPad เท่านั้น
3. ทดลอง LIFF URL แบบแนบ Path, Query Parameter และ URL Fragment
3.1 เปิด LIFF URL แบบ Universal Link ใน LINE app
กรณีที่มี path, query param หรือ URL fragment มาต่อท้าย Universal Link เพิ่มเติม จะมีกลไกการ redirect ด้วยกัน 2 รอบ
- รอบที่ 1: จะ redirect ไปหน้า Endpoint URL ก่อน โดยจะมีการเอา path, query param หรือ URL fragment ที่ต่อท้ายมากับ Universal Link ทำการ URL encode จากนั้นจะนำค่าที่ได้จากการ encode ไปเป็น value ให้กับ liff.state พร้อมทั้งแนบค่าต่างๆของ LIFF ในรูปแบบของ URL fragment ต่อท้าย
- รอบที่ 2: จะ redirect ไป Destination URL โดยมีการเอา value ของ liff.state มาทำการ URL decode แล้วนำค่าที่ได้ไปต่อท้าย Endpoint URL
จุดต่างของ LIFF URL แบบใหม่ กับ แบบเดิม
- แบบใหม่ Destination URL จะได้ Endpoint URL เต็มๆ ซึ่งมีได้ทั้ง path และ query param ในที่นี้ก็คือ /liff1
- แบบเดิม Destination URL จะตัด path และ query param ที่มีอยู่ใน Endpoint URL ออกทั้งหมด ดังนั้นในตัวอย่างนี้ หากต้องการพา /liff2 มาด้วยก็จะต้องระบุ Universal Link เป็น https://liff.line.me/1653575653-8WwXMavK/liff2/path?param=9#hashtag
3.2 เปิด Universal Link ใน External Browser
กลไกการทำงานจะเหมือนข้อ 2.1 ทุกประการ ยกเว้น จะไม่มีการแนบค่าต่างๆของ LIFF ในรูปแบบของ URL fragment ต่อท้าย ในการ redirect รอบที่ 1
3.3 เปิด LINE Scheme ในแอป LINE
กรณีที่มี path, query param หรือ URL fragment มาต่อท้าย LIFF URL แบบ LINE Scheme เพิ่มเติม กลไกการ redirect ทั้ง แบบใหม่ และ แบบเดิม จะมีเพียงรอบเดียว โดยพรุ่งเป้าไปที่ Endpoint URL พร้อมทั้งตัด path และ URL fragment ทิ้งทั้งหมด คงเหลือเพียง query param ที่ส่งต่อมาได้
4. เทคนิคการแนบ Path, Query Parameter และ URL Fragment ไปกับ LINE Scheme
จากข้อที่ 3 เราจะทราบว่าการทำงานของ LIFF URL กับ LINE Scheme นั้นมันจะสามารถส่งต่อได้แค่ Query paramerer แต่จะไม่สนใจ Path และ URL fragment เลย ซึ่งการที่จะให้มันรองรับ Path และ URL fragment นั้นก็เป็นไปได้ 2 ทาง
4.1 Handle ตัว Query param ที่จะแนบเข้ามากับ Endpoint URL
วิธีนี้ก็จะบ้านๆหน่อย โดยเราต้องเขียนโค้ดเพื่อมาตรวจสอบ query param ที่เข้ามา ว่าตรงกับเคสไหน และจะให้ redirect ไปต่อที่ไหน ซึ่งผมว่า…มันเหนื่อยไป
4.2 liff.state ฮีโร่ของเรา
ถ้าใครสั่งเกตดีๆ เมื่อไรก็ตามที่มีการ redirect 2 รอบในข้อที่ 3 มันจะมีตัวแปรตัวหนึ่งที่ชื่อ liff.state ซึ่งเป็น query param แนบมากับ Endpoint URL โดย value ของมันคือค่าที่ได้จากการทำ URL encode ของ path, query param หรือ URL fragment ก็ให้เราใช้วิธีนี้หละ มันจะสามารถพาเราไปยัง path ปลายทางได้ มาดูตัวอย่างกัน
ของแถม
บทความนี้มี 3 เรื่องที่ผมยังไม่ได้พูดถึง แต่เก็บเอามาเป็นของแถมให้สำหรับคนที่อ่านมาถึงตรงนี้นะครับ ^^
- URL Fragment เป็นสิ่งต้องห้ามในการระบุ Endpoint URL นับตั้งแต่นี้ไป
- การเรียกใช้งาน LIFF ใน URL ลักษณะนี้ https://line.me/R/app/xxx-xxx จะมีความสามารถเหมือนกับการใช้ LINE Scheme line://app/xxx-xxx
- มั่นใจว่าคนที่อ่านบทความนี้แล้ว คงจะไปทดลองทำเพื่อเปรียบเทียบก่อนอัพเดทขึ้น Production กันเป็นแน่ ซึ่งช่วงทดลองนี่หละที่มักจะพลาดสลับ LIFF ID ในโค้ดกัน ดังนั้นถ้าจู่ๆเปิด LIFF ใน LINE app แล้วมันดันให้เรา Login ก็ให้เดาไว้ก่อนเลยว่า LIFF ID ที่เราเรียกกับที่เราผูกไว้ในเว็บไม่ตรงกัน…ตรงนี้เจ็บมาเยอะ 😂
สรุป
หวังว่าเนื้อหาในบทความนี้จะช่วยให้นักพัฒนาทุกคนเข้าใจ และเห็นความแตกต่างของกลไกการทำงานของ LIFF URL ในแต่ละวิธี ทั้ง แบบเดิม(Replace) และ แบบใหม่(Concatenate) ได้อย่างชัดเจนนะครับ
ท้ายนี้อยากบอกถึงใครที่กำลังพัฒนา LIFF app อยู่ ว่าไม่ช้าก็เร็ว LIFF URL แบบใหม่ก็จะมาแทนที่แบบเดิมแน่นอน ดังนั้นแนะนำว่า รู้ก่อน ปรับก่อน จะไม่เป็นภาระของลูกหลานในวันข้างหน้า…แล้วพบกันใหม่สวัสดีคร้าบ
