ผู้ดูแลระบบโซลิดัส
นี่เป็นช่วงก่อนอัลฟ่าและสามารถเปลี่ยนแปลงได้ในอนาคต
สิ่งนี้เริ่มต้นจากโปรเจ็กต์สนุกๆ สำหรับจุดประสงค์ภายในเพื่อสร้างแผงผู้ดูแลระบบ solidus_backend เวอร์ชันที่เชื่อถือได้มากขึ้น Solidus มีส่วนประกอบหลักที่ยอดเยี่ยมและอินเทอร์เฟซผู้ดูแลระบบที่มีแบตเตอรี่รวมอยู่ด้วย แต่ในความเห็นของเราและเนื่องจากการปรับแต่งของเรา อัญมณีผู้ดูแลระบบจึงขาดโครงสร้างการออกแบบสำหรับการเป็นโครงสร้างพื้นฐานด้านจริงสำหรับการสื่อสารกับโครงสร้าง solidus_core
คุณสมบัติ
- สวยงามและใช้งานง่าย (UX มีความสำคัญ)
- ขับเคลื่อนด้วย Hotwire Turbo ⚡️
- สิ่งกระตุ้นพร้อมแผนที่นำเข้าสำหรับประกายไฟขนาดเล็ก
- การกรองทำได้ง่ายด้วย Ransack
- การดำเนินการเป็นชุดเช่นการทำลาย
ทำไมต้องเขียนล้อใหม่?
ดังที่กล่าวไว้ ในความเห็นของเรา solidus_backend ถ่ายทอดคำเตือนหลายประการเกี่ยวกับการติดอยู่กับไลบรารีที่เลือกกลับไปที่ spree fork (Deface ฉันกำลังมองคุณอยู่!) และ stucure นี้เข้มงวดเกินไปสำหรับตัวเลือกเหล่านั้น:
- ตัวกรองจำนวนมากที่มีการรื้อค้นกำลังยุ่งอยู่กับการแยกย่อยพารามิเตอร์แบบกำหนดเอง
- Cancan การใช้งานด้วย 'มาโคร' (:manage, :admin) และไม่ใช่กับเส้นทาง CRUD จริง และไม่ติดแบบแผนของรูปแบบ MVC
- การแก้ไขผลิตภัณฑ์ คำสั่งซื้อ และโปรโมชันอาศัย Ajax ที่มีส่วนสำคัญ และไม่ใช่พฤติกรรม CRUD แบบเดิมๆ
- ไม่รองรับเทอร์โบ "จริงๆ": Turbolinks ได้รับการพัฒนาใน hotwire และการใช้งานในปัจจุบันเป็นเพียงตัวอย่างสำหรับการเรียกใช้สคริปต์ที่ถูกต้องของจาวาสคริปต์
- การใช้งานจาวาสคริปต์ระยะไกลอย่างหนักของ rails-ujs และ 'remote: true' แทนที่จะตอบสนอง html ที่สะอาดและคาดเดาได้มากขึ้นด้วยเทอร์โบ ฉันคิดว่าระยะไกลไม่ใช่แนวทางที่ดี เพราะมันแทรกโค้ดจาวาสคริปต์ในคอนโซลของเบราว์เซอร์โดยหวังว่าจะได้รับการดำเนินการ และสำหรับฉัน ถือเป็นภัยคุกคามความปลอดภัยที่อาจเกิดขึ้นจากการเขียนสคริปต์ข้าม
อย่างที่คุณเห็น solidus_admin นั้นค่อนข้างเก่า และสำหรับการปรับปรุง solidus_frontend ด้วย solidus_starter_frontend ก็ถึงเวลาสำหรับการทดลองหนักและการต่ออายุ!
คุณกำลังพยายามสร้าง solidus_backend gem ใหม่หรือไม่?
เรียงลำดับแต่ ไม่ใช่ ฉันเริ่มสิ่งนี้ในฐานะโปรเจ็กต์ทางเลือกก่อนอื่นเลยเพราะเป็นโปรเจ็กต์อัลฟ่าและมีวัตถุประสงค์ที่จะนำเสนอ พร้อมด้วยแบตเตอรี่ที่รวมแบ็กเอนด์ที่มีการเชื่อมต่อต่ำกับเฟรมเวิร์กราง แต่ยังรวมถึงเฟรมเวิร์กผู้ดูแลระบบที่มีโครงสร้างสวยสำหรับการขยายและการปรับแต่ง UI โดยไม่ต้อง headdacle . ฉันต้องการให้พึ่งพาไลบรารี่ที่เลือกจากเจ้าของโปรเจ็กต์โฮสต์มากขึ้น เนื่องจากการผสานรวมที่ง่ายดายโดยไม่ต้องเข้มงวดเกินไป
ตกลง แล้วคุณล่ะเลือกอะไร? ของคุณยังมีความเห็นไหม?
ฉันคิดว่าเราสามารถคิดถึงโครงสร้างโค้ดของผู้ดูแลระบบเพื่อเคารพพื้นฐานนี้:
- ง่ายต่อการแทนที่และขยายด้วยวิธี overrides/monkey-patch ที่น้อยลง เราเป็นคนไม่ใช่ลิง!
- การแบนก่อนหน้าสำหรับ Deface ฉันไม่เคยชอบแนวทาง deface และฉันคิดว่าเป็นการดีกว่าที่จะคิดว่า UI เป็นแบบโมดูลาร์ตั้งแต่เริ่มต้น ในมุมมองทางเลือกอื่นที่เอาชนะด้วยการคัดลอก แต่ไม่ใช่โดยแพทช์และการฉีด สำหรับความสามารถในการขยายของเครื่องมือช่วยเหลือรถเทียมอื่นๆ (ส่วนขยาย solidus ทั้งหมดที่มีส่วนผู้ดูแลระบบ) ฉันต้องการสร้างจุดเสริมที่ชัดเจนและเปิดเผยมากขึ้น
- เข้มงวดกับเส้นทาง CRUD Everithing ต้องอาศัยเส้นทาง CRUD ที่เข้มงวดที่สุดเท่าที่จะเป็นไปได้ เช่นเดียวกับแนวทางเส้นทางที่ซ้อนกัน เพื่อสนับสนุนการประชุมมากกว่าวิธีการกำหนดค่า
- เพิ่มทรัพยากรภายนอกจากแอปโฮสติ้ง Rails ควรมีเทมเพลตโครงเครื่องกำเนิดไฟฟ้า
ด้วยเหตุนี้ ฉันจึงได้เริ่มเลือกตัวเลือกสำหรับโครงการ solidus_adminland 'ใหม่' เช่น:
- hotwire เป็นค่าเริ่มต้นและสนับสนุนให้มากกว่าแนวทางการจัดการ js DOM
- สิ่งกระตุ้นสำหรับการเพิ่มเติมที่ง่ายและเชื่อถือได้ เช่น ตัวเลือก รูปแบบการป้อนข้อมูล และการตรวจสอบความถูกต้องของแบบฟอร์ม
- การใช้ view_component gem สำหรับวิธี incapsulate helper ด้วย HTML reasult (เช่น link_to หรือวิธีที่ซับซ้อนมากขึ้น) ง่ายกว่าสำหรับวัตถุประสงค์ในการแทนที่ เป็นทางเลือกแทนบางส่วนเพื่อความน่าเชื่อถือและคลาส PORO สำหรับตรรกะ UI
- การนำเข้าเนื้อหาทุกครั้งทำด้วย Rails-importmap สำหรับ 'ไม่มีแนวทางแอปจาวาสคริปต์เป็นศูนย์กลาง'
- การใช้การบริหาร gem เพื่อแบ่งข้อกังวลระหว่างการเป็นตัวแทน (ด้วยคลาส *Dashboard) และเส้นทาง CRUD เพื่อให้ข้อมูลที่จะแสดงหรือส่ง
- ทุกแบบฟอร์มได้รับการออกแบบโดย FormBuilder โดยที่ทุกฟิลด์จะถูกเรนเดอร์ด้วยคลาส Component ที่แยกจากกัน หากในฟีเจอร์ที่เราหรือบางคนต้องการใส่ฟิลด์แปลก ๆ เช่น Dropdown JS ก็สามารถสร้างด้วย new Admininstrate::Field, FormBuilder::Component และตัวกระตุ้นสำหรับ js Sparkle ?
- สำหรับลักษณะนโยบาย ฉันคิดว่าเราสามารถสร้างแนวทางแบบไฮบริดเพื่อให้เข้ากันได้กับ cancan แต่ใช้แนวทาง pudit ที่ง่ายกว่า ในกรณีของเรา เราใช้ action_policy gem มันขึ้นอยู่กับวัตถุ PORO ซึ่งเราสามารถกำหนดกฎเกณฑ์สำหรับการดำเนินการแต่ละอย่างสำหรับแต่ละการกระทำได้ มันเป็นส่วนตรงกลางที่แท้จริงสำหรับตัวควบคุมสำหรับนโยบายการควบคุมเหนือ 'ขอบเขตบันทึก', 'บันทึกพารามิเตอร์ที่อนุญาต' และ 'บันทึกเส้นทางที่เข้าถึงได้'
อย่างที่คุณเห็น สำหรับทุกทรัพยากรจะมี:
- คอนโทรลเลอร์ที่มีชื่อเดียวกันสำหรับการดำเนินการ CRUD มาตรฐาน
- แดชบอร์ดที่มีชื่อเดียวกันสำหรับดัชนี new_form, edit_form และแสดงพารามิเตอร์ที่จะแสดง
- นโยบายสำหรับขอบเขตที่ผู้ใช้ปัจจุบันที่ฉันสามารถเข้าถึงได้ พารามิเตอร์ใดที่ฉันสามารถส่งได้ และเส้นทางใดที่ฉันอนุญาตสำหรับทรัพยากรนั้น
... และในฐานะที่เป็นแนวทาง 'ทั่วไป' คุณสามารถสร้าง (หรือขยาย) ของคุณเอง (หรือขยาย) จากทั้งสามวิธีนี้แล้วใส่ตรรกะทางธุรกิจตามที่คุณต้องการ (หรือความต้องการของแอพของคุณ)!
การออกแบบเบื้องต้นทำด้วย bootstrap 5 พร้อม Tabler แต่คุณสามารถแทนที่มุมมองมาตรฐานจากผู้ดูแลระบบ/แอปพลิเคชันสำหรับ CRUD ได้อย่างง่ายดาย จำนวนการดูจะยังคงเข้มงวดจนถึงต่ำที่สุดเท่าที่จะเป็นไปได้
แผนการทำงาน
สิทธิ์ของโลโก้และสีทั้งหมดได้มาจาก solidus presskit ธีมผู้ดูแลระบบได้รับแรงบันดาลใจจากการจำลองเว็บไซต์ solidus และใช้ Tabler เวอร์ชัน Bootstrap 5
