ប្រហែល 15 ឆ្នាំមុន ខ្ញុំបានធ្វើការនៅក្រុមហ៊ុនមួយ ដែលយើងបានបង្កើតកម្មវិធីសម្រាប់ភ្នាក់ងារធ្វើដំណើរ បុគ្គលិកព្រលានយន្តហោះ និងក្រុមហ៊ុនអាកាសចរណ៍។ យើងក៏បានបង្កើតក្របខណ្ឌផ្ទៃក្នុងផ្ទាល់ខ្លួនរបស់យើងសម្រាប់សមាសធាតុ UI និងសមត្ថភាពកម្មវិធីតែមួយទំព័រ។ យើងមានសមាសធាតុសម្រាប់អ្វីៗគ្រប់យ៉ាង៖ វាល ប៊ូតុង ផ្ទាំង ជួរ តារាងទិន្នន័យ ម៉ឺនុយ ការជ្រើសរើសកាលបរិច្ឆេទ ការជ្រើសរើស និងការជ្រើសរើសច្រើន។ យើងថែមទាំងមានធាតុផ្សំ div ទៀតផង។ សមាសភាគ div របស់យើងគឺអស្ចារ្យណាស់ ដោយវិធីនេះ វាអនុញ្ញាតឱ្យយើងធ្វើជ្រុងមូលនៅលើកម្មវិធីរុករកទាំងអស់ ដែលជឿឬមិនជឿ វាមិនមែនជារឿងងាយស្រួលធ្វើនៅពេលនោះទេ។
ការងាររបស់យើងបានកើតឡើងនៅចំណុចមួយក្នុងប្រវត្តិសាស្ត្ររបស់យើង នៅពេលដែល JS, Ajax និង HTML ថាមវន្តត្រូវបានគេមើលឃើញថាជាបដិវត្តន៍ដែលនាំយើងទៅអនាគត។ រំពេចនោះ យើងអាចអាប់ដេតទំព័រមួយដោយថាមវន្ត ទទួលបានទិន្នន័យពីម៉ាស៊ីនមេ និងជៀសវាងការរុករកទៅទំព័រផ្សេងទៀត ដែលវាត្រូវបានគេមើលឃើញថាយឺត និងបង្ហាញរាងចតុកោណកែងពណ៌សធំមួយនៅលើអេក្រង់រវាងទំព័រទាំងពីរ។ មានឃ្លាមួយដែលពេញនិយមដោយ Jeff Atwood (ស្ថាបនិក StackOverflow) ដែលអានថា: "កម្មវិធីណាមួយដែលអាចសរសេរជា JavaScript នឹងត្រូវបានសរសេរជា JavaScript"។—Jeff Atwood
សម្រាប់ពួកយើងនៅពេលនោះ វាមានអារម្មណ៍ដូចជាហ៊ានទៅបង្កើតកម្មវិធីទាំងនោះ។ វាមានអារម្មណ៍ដូចជាការយល់ព្រមលើភួយដើម្បីធ្វើអ្វីគ្រប់យ៉ាងជាមួយ JS ។ ដូច្នេះយើងបានធ្វើអ្វីគ្រប់យ៉ាងជាមួយ JS ហើយយើងពិតជាមិនចំណាយពេលដើម្បីស្រាវជ្រាវវិធីផ្សេងទៀតក្នុងការធ្វើអ្វីនោះទេ។ យើងពិតជាមិនមានអារម្មណ៍ថាមានការលើកទឹកចិត្តក្នុងការរៀនឱ្យបានត្រឹមត្រូវនូវអ្វីដែល HTML និង CSS អាចធ្វើបាននោះទេ។ យើងពិតជាមិនយល់ឃើញថា គេហទំព័រជាវេទិកាកម្មវិធីវិវត្តន៍ទាំងស្រុងនោះទេ។ យើងភាគច្រើនបានមើលឃើញថាវាជាអ្វីមួយដែលយើងត្រូវធ្វើការជុំវិញ ជាពិសេសនៅពេលដែលវាមកដល់ការគាំទ្រកម្មវិធីរុករក។ យើងគ្រាន់តែអាចបោះ JS បន្ថែមទៀតទៅវា ដើម្បីសម្រេចកិច្ចការ។ តើការចំណាយពេលដើម្បីស្វែងយល់បន្ថែមអំពីរបៀបដែលគេហទំព័រដំណើរការ និងអ្វីដែលមាននៅលើវេទិកាបានជួយខ្ញុំ? ប្រាកដណាស់ ខ្ញុំប្រហែលជាបានកោរកូដមួយចំនួនដែលមិនត្រូវការពិតប្រាកដ។ ប៉ុន្តែនៅពេលនោះ ប្រហែលជាមិនច្រើនទេ។ អ្នកឃើញទេ ភាពខុសគ្នានៃកម្មវិធីរុករកតាមអ៊ីនធឺណិតគឺមានសារៈសំខាន់ណាស់កាលពីពេលនោះ។ នេះគឺជាពេលដែល Internet Explorer នៅតែជាកម្មវិធីរុករកដ៏លេចធ្លោ ដោយ Firefox គឺជាអ្នកទីពីរនៅជិត ប៉ុន្តែចាប់ផ្តើមបាត់បង់ចំណែកទីផ្សារដោយសារតែ Chrome ទទួលបានប្រជាប្រិយភាពយ៉ាងឆាប់រហ័ស។ ទោះបីជា Chrome និង Firefox ពិតជាល្អណាស់ក្នុងការយល់ព្រមលើស្តង់ដារគេហទំព័រក៏ដោយ បរិស្ថានដែលកម្មវិធីរបស់យើងកំពុងដំណើរការមានន័យថាយើងត្រូវគាំទ្រ IE6 រយៈពេលយូរ។ សូម្បីតែនៅពេលដែលយើងត្រូវបានអនុញ្ញាតឱ្យគាំទ្រ IE8 យើងនៅតែត្រូវដោះស្រាយជាមួយនឹងភាពខុសគ្នាជាច្រើនរវាងកម្មវិធីរុករក។ មិនត្រឹមតែប៉ុណ្ណឹងទេ បណ្តាញនៅសម័យនោះ ទើបតែមិនមានសមត្ថភាពច្រើននោះ ដែលត្រូវបានបង្កើតឡើងនៅក្នុងវេទិកា។
ឆ្ពោះទៅមុខថ្ងៃនេះ។ អ្វីៗបានផ្លាស់ប្តូរយ៉ាងខ្លាំង។ យើងមិនត្រឹមតែមានសមត្ថភាពទាំងនេះច្រើនជាងពេលមុនប៉ុណ្ណោះទេ ប៉ុន្តែអត្រាដែលពួកគេទទួលបានក៏បានកើនឡើងផងដែរ។ អនុញ្ញាតឱ្យខ្ញុំសួរសំណួរម្តងទៀត៖ តើចំណាយពេលដើម្បីស្វែងយល់បន្ថែមអំពីរបៀបដែលគេហទំព័រដំណើរការ និងអ្វីដែលមាននៅលើវេទិកាជួយអ្នកនៅថ្ងៃនេះ? ពិតជាមែន។ ការរៀនស្វែងយល់ និងប្រើប្រាស់វេទិកាគេហទំព័រថ្ងៃនេះ ធ្វើឱ្យអ្នកទទួលបានអត្ថប្រយោជន៍យ៉ាងច្រើនលើសអ្នកអភិវឌ្ឍន៍ផ្សេងទៀត។ មិនថាអ្នកធ្វើការលើការអនុវត្ត ភាពងាយស្រួល ការឆ្លើយតប ពួកវាទាំងអស់រួមគ្នា ឬគ្រាន់តែដឹកជញ្ជូនមុខងារ UI នោះទេ ប្រសិនបើអ្នកចង់ធ្វើវាក្នុងនាមជាវិស្វករដែលមានទំនួលខុសត្រូវ ការដឹងពីឧបករណ៍ដែលមានសម្រាប់អ្នកជួយឱ្យអ្នកសម្រេចបាននូវគោលដៅរបស់អ្នកបានលឿន និងប្រសើរជាងមុន។ របស់មួយចំនួនដែលអ្នកប្រហែលជាមិនត្រូវការបណ្ណាល័យសម្រាប់ទៀតទេ ដោយដឹងថាកម្មវិធីរុករកណាដែលគាំទ្រសព្វថ្ងៃនេះ សំណួរគឺ៖ តើយើងអាចបោះបង់ចោលអ្វីខ្លះ? តើយើងត្រូវការសមាសភាគ div ដើម្បីធ្វើជ្រុងមូលនៅឆ្នាំ 2025 ទេ? ជាការពិតណាស់ យើងមិនធ្វើទេ។ លក្ខណសម្បត្តិកាំព្រំដែនត្រូវបានគាំទ្រដោយកម្មវិធីរុករកទាំងអស់ដែលប្រើបច្ចុប្បន្នអស់រយៈពេលជាង 15 ឆ្នាំនៅចំណុចនេះ។ ហើយទម្រង់ជ្រុងក៏នឹងមកដល់ក្នុងពេលឆាប់ៗនេះផងដែរ សម្រាប់ជ្រុងដែលមើលទៅអស្ចារ្យជាងមុន។ សូមក្រឡេកមើលលក្ខណៈពិសេសថ្មីៗ ដែលឥឡូវនេះមាននៅក្នុងកម្មវិធីរុករកធំៗទាំងអស់ ហើយដែលអ្នកអាចប្រើដើម្បីជំនួសភាពអាស្រ័យដែលមានស្រាប់នៅក្នុងមូលដ្ឋានកូដរបស់អ្នក។ ចំណុចសំខាន់គឺមិនត្រូវបោះបង់បណ្ណាល័យទាំងអស់របស់អ្នកភ្លាមៗ ហើយសរសេរកូដមូលដ្ឋានរបស់អ្នកឡើងវិញនោះទេ។ ចំពោះអ្វីៗផ្សេងទៀត អ្នកនឹងត្រូវទទួលយកជំនួយពីកម្មវិធីរុករកតាមអ៊ីនធឺណិតជាមុនសិន ហើយសម្រេចចិត្តដោយផ្អែកលើកត្តាផ្សេងទៀតជាក់លាក់ចំពោះគម្រោងរបស់អ្នក។ លក្ខណៈពិសេសខាងក្រោមត្រូវបានអនុវត្តនៅក្នុងម៉ាស៊ីនកម្មវិធីរុករកមេចំនួនបី (Chromium, WebKit និង Gecko) ប៉ុន្តែអ្នកប្រហែលជាមានតម្រូវការគាំទ្រកម្មវិធីរុករកតាមអ៊ីនធឺណិតផ្សេងៗគ្នាដែលរារាំងអ្នកពីការប្រើប្រាស់ពួកវាភ្លាមៗ។ ឥឡូវនេះនៅតែជាពេលវេលាដ៏ល្អដើម្បីស្វែងយល់អំពីលក្ខណៈពិសេសទាំងនេះ ហើយប្រហែលជាមានគម្រោងប្រើពួកវានៅចំណុចណាមួយ។ Popovers និង Dialogs Popover API ធាតុ
ប្រាកដណាស់ ល្បឿននៃការភ្ជាប់អ៊ីនធឺណិតរបស់អ្នកប្រហែលជាកើនឡើងផងដែរ ប៉ុន្តែនោះមិនមែនជាករណីសម្រាប់មនុស្សគ្រប់គ្នានោះទេ។ ហើយមិនមែនគ្រប់គ្នាសុទ្ធតែមានសមត្ថភាពឧបករណ៍ដូចគ្នានោះទេ។ ការទាញកូដភាគីទីបីសម្រាប់អ្វីដែលអ្នកអាចធ្វើបានជាមួយវេទិកា ផ្ទុយទៅវិញ ភាគច្រើនប្រហែលជាមានន័យថាអ្នកដឹកជញ្ជូនកូដកាន់តែច្រើន ដូច្នេះហើយឈានដល់អតិថិជនតិចជាងអ្នកធម្មតា។ នៅលើគេហទំព័រ ដំណើរការផ្ទុកមិនល្អនាំឱ្យអត្រានៃការបោះបង់ចោលដ៏ធំ និងប៉ះពាល់ដល់កេរ្តិ៍ឈ្មោះម៉ាក។ ដំណើរការកូដតិចនៅលើឧបករណ៍ លើសពីនេះ លេខកូដដែលអ្នកដឹកជញ្ជូននៅលើឧបករណ៍របស់អតិថិជនរបស់អ្នកទំនងជាដំណើរការលឿនជាងនេះ ប្រសិនបើវាប្រើ JavaScript abstractions តិចជាងនៅលើវេទិកា។ វាក៏ប្រហែលជាមានការឆ្លើយតប និងអាចចូលប្រើបានច្រើនជាងមុនតាមលំនាំដើម។ ទាំងអស់នេះនាំឱ្យអតិថិជនកាន់តែច្រើន និងសប្បាយរីករាយ។ ពិនិត្យមើលប្លុកគម្លាតវិសមភាពនៃការអនុវត្តប្រចាំឆ្នាំរបស់មិត្តរួមការងាររបស់ខ្ញុំ Alex Russell ដែលបង្ហាញថាឧបករណ៍បុព្វលាភភាគច្រើនអវត្តមានពីទីផ្សារដែលមានអ្នកប្រើប្រាស់រាប់ពាន់លាននាក់ ដោយសារវិសមភាពទ្រព្យសម្បត្តិ។ ហើយគម្លាតនេះមានតែកើនឡើងតាមពេលវេលា។
ប្លង់កំរាលឥដ្ឋដែលភ្ជាប់មកជាមួយ លក្ខណៈពិសេសវេទិកាបណ្តាញមួយដែលនឹងមកដល់ក្នុងពេលឆាប់ៗនេះ ហើយដែលខ្ញុំរំភើបខ្លាំងគឺ CSS Masonry ។
ខ្ញុំសូមចាប់ផ្តើមដោយពន្យល់ពីអ្វីដែល Masonry ជាអ្វី។ តើអ្វីជា Masonry Masonry គឺជាប្រភេទប្លង់មួយដែលត្រូវបានធ្វើឱ្យពេញនិយមដោយ Pinterest កាលពីឆ្នាំមុន។ វាបង្កើតបទឯករាជ្យនៃមាតិកាដែលនៅក្នុងនោះធាតុដែលខ្ចប់ខ្លួនពួកគេឱ្យជិតដល់ការចាប់ផ្តើមនៃបទតាមដែលពួកគេអាចធ្វើបាន។
មនុស្សជាច្រើនមើលឃើញថា Masonry ជាជម្រើសដ៏ល្អសម្រាប់ផលប័ត្រ និងវិចិត្រសាលរូបថត ដែលវាពិតជាអាចធ្វើបាន។ ប៉ុន្តែ Masonry មានភាពបត់បែនជាងអ្វីដែលអ្នកឃើញនៅលើ Pinterest ហើយវាមិនត្រូវបានកំណត់ចំពោះតែប្លង់ដូចទឹកជ្រោះនោះទេ។ នៅក្នុងប្លង់កំរាលឥដ្ឋ៖
បទអាចជាជួរឈរ ឬជួរ៖
បទនៃមាតិកាមិនត្រូវមានទំហំដូចគ្នាទេ៖
ធាតុអាចលាតសន្ធឹងច្រើនបទ៖
ធាតុអាចត្រូវបានដាក់នៅលើបទជាក់លាក់; ពួកគេមិនចាំបាច់ធ្វើតាមក្បួនដោះស្រាយការដាក់ដោយស្វ័យប្រវត្តិជានិច្ចទេ៖
ការបង្ហាញ នេះគឺជាការបង្ហាញសាមញ្ញមួយចំនួនដែលខ្ញុំបានធ្វើដោយប្រើការអនុវត្តនាពេលខាងមុខនៃ CSS Masonry នៅក្នុង Chromium។ ការបង្ហាញវិចិត្រសាលរូបថត ដែលបង្ហាញពីរបៀបដែលធាតុ (ចំណងជើងក្នុងករណីនេះ) អាចលាតសន្ធឹងបទជាច្រើន៖
វិចិត្រសាលរូបថតមួយទៀតដែលបង្ហាញបទដែលមានទំហំខុសៗគ្នា៖
ប្លង់គេហទំព័រព័ត៌មានដែលមានបទមួយចំនួនធំជាងកន្លែងផ្សេងទៀត និងធាតុមួយចំនួនដែលលាតសន្ធឹងទទឹងទាំងមូលនៃប្លង់៖
បន្ទះ kanban បង្ហាញថាធាតុអាចត្រូវបានដាក់នៅលើផ្លូវជាក់លាក់:
ចំណាំ៖ បការបង្ហាញពីមុនត្រូវបានបង្កើតឡើងជាមួយនឹងកំណែរបស់ Chromium ដែលមិនទាន់មានសម្រាប់អ្នកប្រើប្រាស់បណ្ដាញភាគច្រើនទេ ដោយសារតែ CSS Masonry ទើបតែចាប់ផ្តើមអនុវត្តនៅក្នុងកម្មវិធីរុករកប៉ុណ្ណោះ។ ទោះជាយ៉ាងណាក៏ដោយ អ្នកអភិវឌ្ឍន៍គេហទំព័របានប្រើប្រាស់បណ្ណាល័យយ៉ាងសប្បាយរីករាយដើម្បីបង្កើតប្លង់ Masonry អស់ជាច្រើនឆ្នាំមកហើយ។ គេហទំព័រប្រើប្រាស់ Masonry ថ្ងៃនេះ ជាការពិតណាស់ Masonry គឺជារឿងធម្មតាណាស់នៅលើបណ្តាញនាពេលបច្ចុប្បន្ននេះ។ នេះគឺជាឧទាហរណ៍មួយចំនួនដែលខ្ញុំបានរកឃើញក្រៅពី Pinterest៖
និងឧទាហរណ៍មួយចំនួនទៀត មិនសូវច្បាស់ទេ៖
ដូច្នេះ តើប្លង់ទាំងនេះត្រូវបានបង្កើតឡើងដោយរបៀបណា? ដំណោះស្រាយ ល្បិចមួយដែលខ្ញុំបានឃើញគឺការប្រើប្លង់ Flexbox ជំនួសវិញ ដោយផ្លាស់ប្តូរទិសដៅរបស់វាទៅជាជួរឈរ ហើយកំណត់វាទៅជារុំ។ វិធីនេះ អ្នកអាចដាក់ធាតុដែលមានកម្ពស់ខុសៗគ្នាក្នុងជួរឈរឯករាជ្យជាច្រើន ដោយផ្តល់នូវចំណាប់អារម្មណ៍នៃប្លង់ Masonry មួយ៖
ទោះយ៉ាងណាក៏ដោយ មានដែនកំណត់ពីរជាមួយនឹងដំណោះស្រាយនេះ៖
លំដាប់នៃធាតុគឺខុសពីអ្វីដែលវានឹងមានជាមួយនឹងប្លង់ Masonry ពិតប្រាកដ។ ជាមួយ Flexbox ធាតុត្រូវបំពេញជួរទីមួយជាមុនសិន ហើយនៅពេលដែលវាពេញ បន្ទាប់មកចូលទៅកាន់ជួរឈរបន្ទាប់។ ជាមួយនឹង Masonry ធាតុនឹងជង់លើផ្លូវណាមួយ (ឬជួរឈរក្នុងករណីនេះ) មានកន្លែងទំនេរច្រើនជាង។ ប៉ុន្តែផងដែរ ហើយប្រហែលជាសំខាន់ជាងនេះទៅទៀត ដំណោះស្រាយនេះតម្រូវឱ្យអ្នកកំណត់កម្ពស់ថេរទៅធុង Flexbox ។ បើមិនដូច្នេះទេ នឹងមិនមានការរុំឡើយ។
បណ្ណាល័យ Masonry ភាគីទីបី សម្រាប់ករណីកម្រិតខ្ពស់ អ្នកអភិវឌ្ឍន៍បាននឹងកំពុងប្រើប្រាស់បណ្ណាល័យ។ បណ្ណាល័យដែលល្បី និងពេញនិយមបំផុតសម្រាប់វាត្រូវបានគេហៅថាសាមញ្ញ Masonry ហើយវាត្រូវបានទាញយកប្រហែល 200,000 ដងក្នុងមួយសប្តាហ៍យោងទៅតាម NPM ។ Squarespace ក៏ផ្តល់នូវសមាសធាតុប្លង់ដែលបង្ហាញប្លង់ Masonry សម្រាប់ជម្រើសដែលគ្មានលេខកូដ ហើយគេហទំព័រជាច្រើនប្រើវា។ ជម្រើសទាំងពីរនេះប្រើកូដ JavaScript ដើម្បីដាក់ធាតុនៅក្នុងប្លង់។ សាងសង់ក្នុង Masonry ខ្ញុំពិតជារំភើបណាស់ដែលឥឡូវនេះ Masonry ចាប់ផ្តើមបង្ហាញនៅក្នុងកម្មវិធីរុករកតាមអ៊ីនធឺណិតជាលក្ខណៈ CSS ដែលមានស្រាប់។ យូរៗទៅ អ្នកនឹងអាចប្រើ Masonry ដូចអ្នកធ្វើ Grid ឬ Flexbox ដែរ ពោលគឺដោយមិនចាំបាច់ត្រូវការដំណោះស្រាយ ឬកូដភាគីទីបីឡើយ។ ក្រុមរបស់ខ្ញុំនៅក្រុមហ៊ុន Microsoft បាននិងកំពុងអនុវត្តការគាំទ្រ Masonry ដែលមានស្រាប់នៅក្នុងគម្រោងប្រភពបើកចំហរបស់ Chromium ដែល Edge, Chrome និងកម្មវិធីរុករកផ្សេងទៀតត្រូវបានផ្អែកលើ។ Mozilla គឺជាអ្នកលក់កម្មវិធីរុករកដំបូងគេដែលស្នើឱ្យអនុវត្តការសាកល្បងនៃ Masonry ត្រឡប់មកវិញក្នុងឆ្នាំ 2020។ ហើយ Apple ក៏ចាប់អារម្មណ៍យ៉ាងខ្លាំងក្នុងការធ្វើឱ្យប្លង់គេហទំព័រថ្មីនេះកើតឡើងមុនគេ។ ការងារដើម្បីកំណត់លក្ខណៈស្តង់ដារក៏កំពុងដំណើរការទៅមុខផងដែរ ដោយមានកិច្ចព្រមព្រៀងនៅក្នុងក្រុមការងារ CSS អំពីទិសដៅទូទៅ និងសូម្បីតែការបង្ហាញប្រភេទអេក្រង់ថ្មី៖ grid-lanes ។ ប្រសិនបើអ្នកចង់ស្វែងយល់បន្ថែមអំពី Masonry និងតាមដានវឌ្ឍនភាព សូមពិនិត្យមើលទំព័រធនធាន CSS Masonry របស់ខ្ញុំ។ យូរៗទៅ នៅពេលដែល Masonry ក្លាយជាមុខងារ Baseline ដូចជា Grid ឬ Flexbox យើងនឹងអាចប្រើវាបានយ៉ាងសាមញ្ញ ហើយទទួលបានអត្ថប្រយោជន៍ពី៖
ការអនុវត្តកាន់តែប្រសើរ, ការឆ្លើយតបកាន់តែប្រសើរ, ភាពងាយស្រួលនៃការប្រើប្រាស់ និងលេខកូដកាន់តែងាយស្រួល។
សូមពិនិត្យមើលឲ្យកាន់តែច្បាស់អំពីចំណុចទាំងនេះ។ ការអនុវត្តកាន់តែប្រសើរ ការបង្កើតប្រព័ន្ធប្លង់ដូច Masonry ផ្ទាល់ខ្លួនរបស់អ្នក ឬប្រើបណ្ណាល័យភាគីទីបីជំនួសវិញ មានន័យថាអ្នកនឹងត្រូវដំណើរការកូដ JavaScript ដើម្បីដាក់ធាតុនៅលើអេក្រង់។ នេះក៏មានន័យថាលេខកូដនេះនឹងត្រូវបានរារាំង។ ជាការពិតណាស់ គ្មានអ្វីនឹងលេចឡើង ឬអ្វីៗនឹងមិនស្ថិតនៅកន្លែងត្រឹមត្រូវ ឬទំហំត្រឹមត្រូវនោះទេ រហូតដល់កូដ JavaScript នោះដំណើរការ។ ប្លង់ Masonry ត្រូវបានគេប្រើជាញឹកញាប់សម្រាប់ផ្នែកសំខាន់នៃទំព័របណ្តាញ ដែលមានន័យថាកូដនឹងធ្វើឱ្យមាតិកាសំខាន់របស់អ្នកលេចឡើងនៅពេលក្រោយជាងដែលវាអាចមាន ធ្វើឱ្យខូចគុណភាព LCP របស់អ្នក ឬខ្នាតធំបំផុតនៃថ្នាំលាបខ្លឹមសារ ដែលដើរតួនាទីយ៉ាងធំក្នុងដំណើរការយល់ឃើញ និងការបង្កើនប្រសិទ្ធភាពម៉ាស៊ីនស្វែងរក។ ខ្ញុំបានសាកល្បងបណ្ណាល័យ Masonry JS ជាមួយនឹងប្លង់សាមញ្ញ និងដោយការក្លែងធ្វើការតភ្ជាប់ 4G យឺតនៅក្នុង DevTools ។ បណ្ណាល័យមិនធំទេ (24KB, 7.8KB gzipped) ប៉ុន្តែវាត្រូវចំណាយពេល 600ms ដើម្បីផ្ទុកនៅក្រោមលក្ខខណ្ឌសាកល្បងរបស់ខ្ញុំ។ នេះគឺជាការថតសកម្មភាពដែលបង្ហាញថារយៈពេលផ្ទុក 600ms យូរសម្រាប់បណ្ណាល័យ Masonry ហើយមិនមានសកម្មភាពបង្ហាញផ្សេងទៀតបានកើតឡើងខណៈពេលដែលវាកំពុងកើតឡើង៖
លើសពីនេះទៀតបន្ទាប់ពីរយៈពេលផ្ទុកដំបូង ស្គ្រីបដែលបានទាញយកបន្ទាប់មកចាំបាច់ត្រូវញែក ចងក្រង និងបន្ទាប់មកដំណើរការ។ អ្វីទាំងអស់ដូចដែលបានលើកឡើងមុនគឺរារាំងការបង្ហាញទំព័រ។ ជាមួយនឹងការអនុវត្ត Masonry ដែលភ្ជាប់មកជាមួយនៅក្នុងកម្មវិធីរុករក យើងនឹងមិនមានស្គ្រីបសម្រាប់ផ្ទុក និងដំណើរការទេ។ ម៉ាស៊ីនកម្មវិធីរុករកនឹងគ្រាន់តែធ្វើរឿងរបស់វាក្នុងអំឡុងពេលជំហានបង្ហាញទំព័រដំបូង។ ការឆ្លើយតបកាន់តែប្រសើរ ស្រដៀងនឹងពេលទំព័រមួយផ្ទុកដំបូង ការប្ដូរទំហំបង្អួចកម្មវិធីរុករកនាំឱ្យការបង្ហាញប្លង់ក្នុងទំព័រនោះម្ដងទៀត។ នៅចំណុចនេះ ប្រសិនបើទំព័រកំពុងប្រើបណ្ណាល័យ Masonry JS នោះ មិនចាំបាច់ផ្ទុកស្គ្រីបម្តងទៀតទេ ព្រោះវាមានរួចហើយនៅទីនេះ ទោះយ៉ាងណាក៏ដោយ កូដដែលផ្លាស់ទីធាតុនៅកន្លែងត្រឹមត្រូវត្រូវដំណើរការ។ ឥឡូវនេះបណ្ណាល័យពិសេសនេះហាក់ដូចជាលឿនណាស់ក្នុងការធ្វើវានៅពេលដែលទំព័រផ្ទុក។ ទោះជាយ៉ាងណាក៏ដោយ វាធ្វើឱ្យធាតុមានចលនានៅពេលដែលពួកគេត្រូវការផ្លាស់ទីទៅកន្លែងផ្សេងនៅលើការប្តូរទំហំបង្អួច ហើយនេះធ្វើឱ្យមានភាពខុសគ្នាខ្លាំង។ ជាការពិតណាស់ អ្នកប្រើប្រាស់មិនចំណាយពេលផ្លាស់ប្តូរទំហំបង្អួចកម្មវិធីរុករកតាមអ៊ីនធឺណិតរបស់ពួកគេច្រើនដូចដែលយើងអ្នកអភិវឌ្ឍន៍ធ្វើនោះទេ។ ប៉ុន្តែបទពិសោធន៍ផ្លាស់ប្តូរទំហំដែលមានចលនានេះ អាចមានភាពច្របូកច្របល់ និងបន្ថែមពេលវេលាដែលយល់ឃើញថាវាត្រូវការសម្រាប់ទំព័រដើម្បីសម្របទៅនឹងទំហំថ្មីរបស់វា។ ភាពងាយស្រួលនៃការប្រើប្រាស់ និងលេខកូដសាមញ្ញ ភាពងាយស្រួលក្នុងការប្រើប្រាស់មុខងារគេហទំព័រ និងរបៀបដែលរូបរាងកូដសាមញ្ញ គឺជាកត្តាសំខាន់ដែលអាចធ្វើឱ្យមានភាពខុសគ្នាខ្លាំងសម្រាប់ក្រុមរបស់អ្នក។ ពួកវាមិនអាចមានសារៈសំខាន់ដូចបទពិសោធន៍អ្នកប្រើប្រាស់ចុងក្រោយនោះទេ ប៉ុន្តែបទពិសោធន៍របស់អ្នកអភិវឌ្ឍន៍ប៉ះពាល់ដល់ការរក្សា។ ការប្រើប្រាស់មុខងារគេហទំព័រដែលភ្ជាប់មកជាមួយមកជាមួយអត្ថប្រយោជន៍សំខាន់ៗនៅផ្នែកខាងមុខនោះ៖
អ្នកអភិវឌ្ឍន៍ដែលស្គាល់ HTML, CSS និង JS រួចហើយទំនងជានឹងអាចប្រើមុខងារនោះបានយ៉ាងងាយស្រួល ព្រោះវាត្រូវបានរចនាឡើងដើម្បីរួមបញ្ចូលយ៉ាងល្អ និងត្រូវគ្នាជាមួយនឹងវេទិកាគេហទំព័រដែលនៅសល់។ មិនមានហានិភ័យនៃការបំបែកការផ្លាស់ប្តូរដែលត្រូវបានណែនាំនៅក្នុងរបៀបដែលមុខងារនេះត្រូវបានប្រើប្រាស់នោះទេ។ វាមានហានិភ័យស្ទើរតែសូន្យដែលមុខងារនោះត្រូវបានបដិសេធ ឬមិនត្រូវបានថែរក្សា។
ក្នុងករណីដែលសាងសង់ឡើងនៅក្នុង Masonry ដោយសារតែវាជាប្លង់បឋម អ្នកប្រើវាពី CSS ដូចជា Grid ឬ Flexbox មិនមាន JS ពាក់ព័ន្ធទេ។ ផងដែរ លក្ខណៈសម្បត្តិ CSS ដែលទាក់ទងនឹងប្លង់ផ្សេងទៀត ដូចជាគម្លាត ដំណើរការដូចដែលអ្នកចង់បាន។ មិនមានល្បិច ឬដំណោះស្រាយដែលត្រូវដឹងទេ ហើយអ្វីដែលអ្នករៀនត្រូវបានចងក្រងជាឯកសារនៅលើ MDN ។ សម្រាប់ lib Masonry JS ការចាប់ផ្តើមគឺស្មុគស្មាញបន្តិច៖ វាទាមទារគុណលក្ខណៈទិន្នន័យដែលមានវាក្យសម្ព័ន្ធជាក់លាក់ រួមជាមួយនឹងធាតុ HTML ដែលលាក់ដើម្បីកំណត់ទំហំជួរឈរ និងគម្លាត។ លើសពីនេះ ប្រសិនបើអ្នកចង់ពង្រីកជួរឈរ អ្នកត្រូវបញ្ចូលទំហំគម្លាតដោយខ្លួនឯង ដើម្បីជៀសវាងបញ្ហា៖
<រចនាប័ទ្ម> .track-sizer, .ធាតុ { ទទឹង: 20%; } .gutter-sizer { ទទឹង: 1rem; } .ធាតុ { កម្ពស់: 100px; margin-block-end: 1rem; } .item:nth-child(សេស) { កម្ពស់: 200px; } .item--width2 { ទទឹង៖ calc(40% + 1rem); }
ចូរយើងប្រៀបធៀបនេះទៅនឹងអ្វីដែលការអនុវត្ត Masonry សាងសង់ឡើងនឹងមើលទៅដូច: <រចនាប័ទ្ម> .កុងតឺន័រ { ការបង្ហាញ៖ ផ្លូវក្រឡាចត្រង្គ; ផ្លូវក្រឡាចត្រង្គ៖ ធ្វើម្តងទៀត(4, 20%) គម្លាត: 1rem; } .ធាតុ { កម្ពស់: 100px; } .item:nth-child(សេស) { កម្ពស់: 200px; } .item--width2 { grid-column: span 2; }
កូដបង្រួមកាន់តែសាមញ្ញ ដែលគ្រាន់តែអាចប្រើអ្វីៗដូចជាគម្លាត និងកន្លែងដែលការលាតសន្ធឹងត្រូវបានធ្វើដោយវិសាលភាព 2 ដូចនៅក្នុងក្រឡាចត្រង្គ ហើយមិនតម្រូវឱ្យអ្នកគណនាទទឹងត្រឹមត្រូវដែលរួមបញ្ចូលទំហំគម្លាតនោះទេ។ ធ្វើដូចម្តេចដើម្បីដឹងថាអ្វីដែលមានហើយនៅពេលដែលវាមាន? សរុបមក សំណួរគឺមិនមែនថាតើអ្នកគួរតែប្រើ Masonry ដែលមានស្រាប់នៅលើបណ្ណាល័យ JS នោះទេ ប៉ុន្តែផ្ទុយទៅវិញនៅពេលណា។ បណ្ណាល័យ Masonry JS គឺអស្ចារ្យណាស់ ហើយបានបំពេញចន្លោះមួយនៅក្នុងវេទិកាបណ្តាញអស់រយៈពេលជាច្រើនឆ្នាំ ហើយសម្រាប់អ្នកអភិវឌ្ឍន៍ និងអ្នកប្រើប្រាស់ដែលសប្បាយរីករាយជាច្រើន។ វាមានគុណវិបត្តិមួយចំនួន ប្រសិនបើអ្នកប្រៀបធៀបវាទៅនឹងការអនុវត្ត Masonry ដែលមានស្រាប់ ប៉ុន្តែវាមិនសំខាន់ទេ ប្រសិនបើការអនុវត្តនោះមិនទាន់រួចរាល់។ វាងាយស្រួលសម្រាប់ខ្ញុំក្នុងការរាយបញ្ជីលក្ខណៈពិសេសវេទិកាបណ្តាញថ្មីទាំងនេះ ដោយសារតែខ្ញុំធ្វើការនៅអ្នកលក់កម្មវិធីរុករក ហើយដូច្នេះខ្ញុំមានទំនោរចង់ដឹងថាអ្វីដែលនឹងមកដល់។ ប៉ុន្តែអ្នកអភិវឌ្ឍន៍ជាញឹកញាប់ចែករំលែក ការស្ទង់មតិបន្ទាប់ពីការស្ទង់មតិ ថាការតាមដានរបស់ថ្មីគឺពិបាកណាស់។ ការរក្សាព័ត៌មានគឺពិបាក ហើយក្រុមហ៊ុនមិនតែងតែផ្តល់អាទិភាពដល់ការរៀនសូត្រនោះទេ។ ដើម្បីជួយក្នុងបញ្ហានេះ ខាងក្រោមនេះជាធនធានមួយចំនួនដែលផ្តល់ព័ត៌មានថ្មីៗតាមវិធីសាមញ្ញ និងបង្រួម ដូច្នេះអ្នកអាចទទួលបានព័ត៌មានដែលអ្នកត្រូវការយ៉ាងឆាប់រហ័ស៖
វេទិកាគេហទំព័រមានលក្ខណៈពិសេសរបស់គេហទំព័រអ្នករុករក៖ អ្នកប្រហែលជាចាប់អារម្មណ៍លើទំព័រកំណត់ចំណាំចេញផ្សាយរបស់វា។ ហើយប្រសិនបើអ្នកចូលចិត្ត RSS សូមពិនិត្យមើលព័ត៌មានកំណត់ចំណាំចេញផ្សាយ ក៏ដូចជាព័ត៌មានមូលដ្ឋានដែលមានស្រាប់ថ្មី និងទូលំទូលាយ។
គេហទំព័រផ្ទាំងគ្រប់គ្រងស្ថានភាពវេទិកា៖ អ្នកប្រហែលជាចូលចិត្តទំព័រឆ្នាំមូលដ្ឋានផ្សេងៗរបស់វា។
ទំព័រផែនទីបង្ហាញផ្លូវរបស់ Chrome Platform Status ។
ប្រសិនបើអ្នកមានពេលបន្តិចទៀត អ្នកក៏អាចចាប់អារម្មណ៍លើកំណត់ចំណាំចេញផ្សាយរបស់អ្នកលក់កម្មវិធីរុករកដែរ៖
Chrome គែម Firefox សាហ្វារី
សម្រាប់ធនធានកាន់តែច្រើន សូមពិនិត្យមើលការរុករកគេហទំព័រ សន្លឹកបន្លំគេហទំព័ររបស់ខ្ញុំ។ រឿងរបស់ខ្ញុំនៅតែមិនត្រូវបានអនុវត្ត នោះជាផ្នែកម្ខាងទៀតនៃបញ្ហា។ ទោះបីជាអ្នកស្វែងរកពេលវេលា ថាមពល និងវិធីដើម្បីតាមដានក៏ដោយ ក៏នៅតែមានការខកចិត្តជាមួយនឹងការទទួលសំឡេងរបស់អ្នក និងមុខងារដែលអ្នកចូលចិត្តត្រូវបានអនុវត្ត។ ប្រហែលជាអ្នកបានរង់ចាំអស់ជាច្រើនឆ្នាំសម្រាប់បញ្ហាជាក់លាក់មួយដែលត្រូវបានដោះស្រាយ ឬមុខងារជាក់លាក់មួយដើម្បីដឹកជញ្ជូននៅក្នុងកម្មវិធីរុករកដែលវានៅតែបាត់។ អ្វីដែលខ្ញុំនឹងនិយាយគឺអ្នកលក់ browser ស្តាប់។ ខ្ញុំជាផ្នែកមួយនៃក្រុមឆ្លងស្ថាប័នជាច្រើន ដែលយើងពិភាក្សាអំពីសញ្ញារបស់អ្នកអភិវឌ្ឍន៍ និងមតិកែលម្អគ្រប់ពេលវេលា។ យើងពិនិត្យមើលប្រភពផ្សេងៗគ្នាជាច្រើននៃមតិកែលម្អ ទាំងផ្នែកខាងក្នុងនៅអ្នកលក់កម្មវិធីរុករកនីមួយៗ និងខាងក្រៅ/សាធារណៈនៅលើវេទិកា គម្រោងប្រភពបើកចំហ ប្លុក និងការស្ទង់មតិ។ ហើយយើងតែងតែព្យាយាមបង្កើតវិធីល្អប្រសើរជាងមុនសម្រាប់អ្នកអភិវឌ្ឍន៍ដើម្បីចែករំលែកតម្រូវការជាក់លាក់ និងករណីប្រើប្រាស់របស់ពួកគេ។ ដូច្នេះ ប្រសិនបើអ្នកអាច សូមទាមទារបន្ថែមពីអ្នកលក់កម្មវិធីរុករក ហើយដាក់សម្ពាធឱ្យយើងអនុវត្តមុខងារដែលអ្នកត្រូវការ។ ខ្ញុំយល់ថាវាត្រូវការពេលវេលា ហើយក៏អាចជាការបំភិតបំភ័យផងដែរ (មិននិយាយពីរបាំងខ្ពស់ក្នុងការចូល) ប៉ុន្តែវាក៏ដំណើរការផងដែរ។ នេះគឺជាវិធីមួយចំនួនដែលអ្នកអាចទទួលបានសំឡេងរបស់អ្នក (ឬក្រុមហ៊ុនរបស់អ្នក) ឮ៖ យកស្ថានភាពប្រចាំឆ្នាំរបស់ JS, រដ្ឋ CSS និងស្ថានភាពនៃការស្ទង់មតិ HTML ។ ពួកគេដើរតួនាទីយ៉ាងធំនៅក្នុងរបៀបដែលអ្នកលក់កម្មវិធីរុករកតាមអ៊ីនធឺណិតផ្តល់អាទិភាពដល់ការងាររបស់ពួកគេ។ ប្រសិនបើអ្នកត្រូវការ API ដែលមានមូលដ្ឋានលើស្តង់ដារជាក់លាក់ ដើម្បីត្រូវបានអនុវត្តជាប់លាប់នៅលើកម្មវិធីរុករកតាមអ៊ីនធឺណិត សូមពិចារណាដាក់សំណើនៅការបន្តគម្រោង Interop បន្ទាប់។ វាទាមទារពេលវេលាបន្ថែមទៀត ប៉ុន្តែពិចារណាពីរបៀបដែល Shopify និង RUMvision ចែករំលែកបញ្ជីប្រាថ្នារបស់ពួកគេសម្រាប់ Interop 2026។ ព័ត៌មានលម្អិតដូចនេះអាចមានប្រយោជន៍ខ្លាំងណាស់សម្រាប់អ្នកលក់កម្មវិធីរុករកតាមអ៊ីនធឺណិតក្នុងការកំណត់អាទិភាព។ សម្រាប់តំណភ្ជាប់ដែលមានប្រយោជន៍បន្ថែមទៀតដើម្បីជះឥទ្ធិពលលើអ្នកលក់កម្មវិធីរុករក សូមពិនិត្យមើលការរុករកគេហទំព័ររបស់ខ្ញុំ សន្លឹកឆ្នោត។ សេចក្តីសន្និដ្ឋាន ដើម្បីបិទ ខ្ញុំសង្ឃឹមថាអត្ថបទនេះបានបន្សល់ទុកអោយអ្នកនូវរឿងមួយចំនួនដែលត្រូវគិត៖
ភាពរំភើបសម្រាប់ Masonry និងមុខងារគេហទំព័រនាពេលខាងមុខផ្សេងទៀត។ មុខងារគេហទំព័រមួយចំនួនដែលអ្នកប្រហែលជាចង់ចាប់ផ្តើមប្រើប្រាស់។ បំណែកមួយចំនួននៃកូដផ្ទាល់ខ្លួន ឬភាគីទី 3 ដែលអ្នកប្រហែលជាអាចដកចេញបាន ដើម្បីពេញចិត្តនឹងមុខងារដែលមានស្រាប់។ វិធីមួយចំនួនដើម្បីតាមដានអ្វីដែលនឹងមកដល់ និងមានឥទ្ធិពលលើអ្នកលក់កម្មវិធីរុករក។
សំខាន់ជាងនេះទៅទៀត ខ្ញុំសង្ឃឹមថា ខ្ញុំបានបញ្ចុះបញ្ចូលអ្នកអំពីអត្ថប្រយោជន៍នៃការប្រើប្រាស់វេទិកាបណ្តាញឱ្យអស់ពីសក្តានុពលរបស់វា។
