Get best of the week

Arsitektur Modern Front End (Bagian 2)

gambar

Bagian kedua dari artikel " Arsitektur Front-end Kontemporer ", yang membahas arsitektur ujung depan dalam hal distribusi aliran data. Mulai dari sini

Penerapan


Algoritma yang dihasilkan oleh DOM (algoritma DOM-infused)


Teknik, diperkenalkan dan dikuasai oleh perpustakaan jQuery , benar-benar adalah awal dari penulisan aplikasi klien skala besar, meskipun pada kenyataannya jQuery tidak menyelesaikan masalah arsitektur. Itu dirancang untuk membuatnya lebih mudah untuk memanipulasi pohon DOM ketika ada terlalu banyak ketidakkonsistenan dalam perilaku browser. Ini menyediakan API independen browser.

Saya tidak berpikir ini disengaja, tetapi jQuery telah menyederhanakan DOM API sedemikian rupa sehingga sulit untuk membedakannya dari API bahasa pemrograman biasa. Ini, pada gilirannya, memungkinkan pengembang untuk benar-benar mencampur tingkat DOM API ( Lihat ) dengan logika bisnis ( Model ).

Sekali lagi, kita masih dalam konteks MVC sisi server yang sama. Ini hanya sekuel. Tidak ada inversi kontrol yang nyata. Kontrol umum atas tampilan / halaman masih ditentukan oleh kode sisi server.





Dalam cuplikan kode di atas, Model, Presentasi, dan Presenter / Pengendali dalam beberapa cara digabungkan menjadi satu struktur kode monolitik. Ini adalah kasus ketika Model hanya terdiri dari satu properti. Bayangkan mencoba membuat aplikasi web tanpa siklus penelusuran server (seperti SPA). Tidak mungkin untuk menangani semua ini dengan cara yang nyaman. Kode untuk berinteraksi dengan DOM ditembus oleh sisa logika aplikasi, dan oleh karena itu dikenal sebagai algoritma DOM-infused (Saya tidak yakin bahwa ada istilah seperti itu secara resmi)

Backbone.js - MV *


Seperti yang telah kita lihat, di jQuery, ketika mengembangkan aplikasi, cara untuk menyusun dan mengatur kode kita jelas tidak ada. Di sinilah Backbone.js muncul sebagai solusi evolusi berikutnya. Itu adalah salah satu perpustakaan pertama yang membawa manfaat gaya MVC sisi klien.



Jika kita melihat diagram alir data Backbone, kita akan dengan jelas melihat model dan tampilan, tetapi tidak ada objek yang setara dengan controller. Template berkembang, dan sisi klien MVC hanyalah sebuah evolusi dari arsitektur MVC sebelumnya. Selama evolusi ini, banyak komunitas JavaScript setuju dengan definisi model dan tampilan, tetapi tidak ada konsensus tentang pengontrol. Mengingat lingkungan klien, gagasan Pengendali tidak begitu cocok. Pengontrol dibiarkan terbuka untuk interpretasi.

Sedangkan untuk Backbone, tidak ada controller di dalamnya. Jadi apa ini? Apakah itu MVC, MVP atau MVVM? Meminjam dari definisi server MVC, controller memiliki dua tanggung jawab, yaitu: untuk merespons tindakan pengguna dalam bentuk permintaan HTTP yang masuk dan mengontrol model untuk membuat tampilan (halaman HTML). Dalam kasus Backbone, tanggung jawab ini dibagi antara View dan Router . Tetapi gagasan independen tentang Pengendali atau Presenter tidak ada.
, Backbone — MVP, View Presenter, Template — View, Model Collection Model.

, Backbone - . , Backbone MVC, MVP. , .

Ini adalah bagaimana MV * atau Model-View-Apapun ("apa pun") lahir. Untuk pembahasan terperinci, sangat disarankan agar Anda memeriksa blog Addi Osmani.

Dibandingkan dengan jQuery sebelumnya, Backbone membantu membuat kode yang lebih terstruktur.









Sebelumnya di artikel ini, saya menyebut Backbone solusi evolusi berikutnya. Alasannya adalah bahwa ia hanya memperpanjang sisi server MVC untuk melengkapinya. Misalnya, jika server kami tenang dan menyiratkan bahwa kode front-end hanyalah sarana untuk mewakili model di sisi server, maka Backbone sudah dikonfigurasi untuk disinkronkan dengan API:



Dan selain itu, ada banyak konvensi kecil lainnya yang dibangun di dalam Backbone yang hanya terasa seperti perpanjangan. Sebagai kesimpulan, saya mengatakan bahwa Backbone mungkin bukan satu-satunya solusi pada saat itu, tetapi itu benar-benar merupakan terobosan dalam hal struktur kode dan organisasi. Seperti jQuery, ini telah digunakan oleh banyak produk.

Knockout.js - data mengikat untuk ujung depan


Knockout.js adalah contoh terbaru kami menggunakan templat dasar. Ini bertujuan untuk mengimplementasikan MVVM - Model-View-ViewModel untuk JavaScript. Begitulah. Sementara Backbone berurusan dengan masalah struktur organisasi dan kode, Knockout adalah implementasi tingkat tampilan yang efisien menggunakan Binding Data Deklaratif . Keuntungan dari binding deklaratif sama dengan konstruksi pemrograman deklaratif lainnya:

  1. Mudah dibaca: kode deklaratif membantu pemrograman
  2. Memperpendek templat standar: binding memungkinkan kami untuk memperbarui DOM secara otomatis setiap kali ViewModel berubah, dan juga memperbarui ViewModel setiap kali View berubah melalui input pengguna.
  3. Dapat diamati: Knockout memberikan tingkat abstraksi yang lebih tinggi untuk acara. Ini memungkinkan Knockout untuk secara otomatis melacak dependensi antara properti ViewModel. Jika perlu, kami dapat berlangganan properti yang Dapat Diobservasi.





Sementara Knockout menyediakan konstruksi yang didefinisikan dengan baik untuk View dan ViewModel, itu tidak mengatakan apa-apa tentang model aplikasi yang seharusnya. Ini membuat Knockout sangat fokus dan serbaguna, karena dapat digunakan sebagai pustaka alih-alih kerangka kerja. Dari pengalaman saya sendiri, saya melihat bahwa itu digunakan untuk membuat aplikasi mini SPA, di mana aplikasi web terdiri dari beberapa halaman dan setiap halaman adalah aplikasi Knockout kecil. Ini jawaban StackOverflow jelas mendefinisikan ruang lingkup MVVM di Knockout.
Sering diasumsikan bahwa dengan model, Knockout ada di sisi server. ViewModel hanya meminta model sisi server menggunakan Ajax atau yang setara.

Knockout menggantikan jQuery dan solusi templat seperti Setang untuk pembaruan DOM, tetapi masih menggunakan jQuery untuk animasi, Ajax, dan utilitas lainnya. Dalam kombinasi dengan Backbone, itu dapat berfungsi sebagai implementasi penuh dari template MVVM. Secara teoritis, ini bisa terjadi, tetapi sebelum ini bisa terjadi, konsep-konsep ini sudah dikembangkan dalam perangkat generasi berikutnya.
Di sini dimulai gerakan revolusioner Angular 1, Aurelia, Ember.js, dll.

Karena hubungannya yang dekat dengan dunia .NET, Knockout telah banyak digunakan dalam aplikasi ASP.NET MVC. Seperti Backbone, itu adalah solusi evolusi lain untuk masalah yang sedikit berbeda. Dan lagi, asumsi bahwa kode sisi klien hanyalah perpanjangan ke pola MVC sisi server tidak berubah. Sisi server masih merupakan arsitektur yang dominan.

Baik Knockout maupun Backbone adalah pustaka JavaScript. Dengan satu atau lain cara, Backbone dipandang sebagai kerangka kerja. Mengapa? Tidak ada jawaban yang pasti, tetapi mungkin dalam perspektif. Backbone selalu ditangani dengan abstraksi level yang lebih tinggi karena penekanannya pada struktur kode. Selain itu, Backbone tidak pernah dimaksudkan untuk menggantikan jQuery di mana-mana (bahkan pada tahun 2019, 70% dari 10.000.000 situs web teratas menggunakan jQuery), sementara Knockout tumpang tindih dengan inti jQuery, mis., Manipulasi DOM, yang secara alami mempersulit Knockout. Dengan demikian, adaptasi Knockout terbatas dibandingkan dengan Backbone. Tapi itu masih salah satu implementasi pertama dari ikatan data deklaratif untuk komunitas front-end, dan itu layak mendapat perhatian khusus.

Sudut 1 - beri saya kontrol


Apa jQuery lakukan dengan DOM, Angular 1 lakukan dengan ekosistem front-end secara keseluruhan. Ini selamanya mengubah ide membuat aplikasi klien skala besar. Dia mempresentasikan banyak konsep sebagai dasar - sistem modular, injeksi ketergantungan, inversi kontrol, pengikatan data yang lebih mudah, dll.

Saat itu dan sekarang tetap tugas yang sulit untuk memilih perpustakaan JavaScript yang tepat dan membuat tumpukan teknologi yang sempurna untuk frontend. Angular 1 hanya menyediakan alternatif yang lebih sederhana namun lebih kohesif. Hal yang sama dapat dikatakan tentang Ember.js dan sistem serupa lainnya, tetapi penerapan Angular 1 berada pada tingkat kualitatif yang berbeda dari alternatifnya pada waktu itu.
Angular 1 adalah solusi revolusioner dalam arti bahwa itu jelas menandai pindah dari gagasan ekstensi MVC sisi server sederhana dengan kode sisi klien yang tersebar di halaman. Angular 1 telah menjadikan SPA solusi kelas satu, hampir secara de facto untuk menciptakan pengalaman pengguna generasi berikutnya.

Kerangka kerja atau perpustakaan?


Solusi sebelumnya adalah lebih banyak perpustakaan daripada kerangka kerja. Angular 1 tidak diragukan lagi merupakan struktur yang terdefinisi dengan baik. Faktor pembeda yang diperlukan antara platform dan perpustakaan adalah IOC - Inversion of Control. Selanjutnya, untuk memenuhi syarat Angular 1 sebagai kerangka kerja, kami dapat mencatat:

  1. MVVM yang terdefinisi dengan baik: Angular 1 memiliki objek Model, View, dan ViewModel yang jelas.
  2. (DI): Angular 1 DI, Model. Angular 1 (Service). , .
  3. (data binding) : , . , MVVM. . (Angular 1 ). . . MVC. , .
  4. Sistem modular: Angular 1 memperkenalkan sistem modular khusus untuk kerangka kerja. Modul adalah dasar untuk mengatur kode untuk hampir setiap bahasa. JavaScript tidak memiliki sistem modular hingga 2015 (browser tidak mendukungnya hingga 2018). Angular jauh lebih maju dari waktunya dalam hal organisasi.

Pada saat yang sama, Angular 1 juga dikritik karena kompleksitas yang diperkenalkannya. Kritik yang paling penting adalah bahwa itu dimodelkan pada desain sisi server. Ini tidak khas untuk pengembang frontend. Beberapa hal terus terang buruk:

  1. Tabrakan Namespace: Meskipun DI hebat, itu diimplementasikan menggunakan pola Service Locator yang menggunakan namespace global. Ini membuat awalan layanan hampir wajib.
  2. . , , , . React . -, .
  3. . , Angular 1, . , Angular 1 $scope, ViewModel, Controller, $scope. , VMFactory . , Angular 1 , .

Ada banyak masalah kecil lainnya. Angular 2, atau hanya Angular, adalah terobosan total sejauh itu tampak seperti kerangka kerja yang sama sekali baru. Saya tidak menemukan kesamaan di antara mereka, kecuali untuk nama dan beberapa konsep.



Selama bertahun-tahun, telah ada rilis kecil Angular 1, di mana banyak dari kompleksitas kecil penggunaannya telah diperbaiki. Yang paling penting dari ini adalah penambahan Model Komponen , di mana sebagian besar tren pembangunan front-end bertemu.

Angular 1 hidup lama dan terus hidup di antara komunitas front-end. Dengan semua pro dan kontra, itu membantu masyarakat memahami pentingnya arsitektur perangkat lunak dan memberikan dasar untuk menulis aplikasi yang dapat diukur. Kontra dan kelemahannya menjadi dasar untuk memecahkan masalah arsitektur masa depan.

More articles:


All Articles