Backbone: History.navigate harus mengizinkan pengaturan objek status

Saya khawatir saya tidak setuju -- tetapi coba bujuk saya sebaliknya.

Inti dari History API adalah untuk menyediakan URL yang dapat di-bookmark dan dibagikan, yang dapat Anda navigasikan kembali. Jika Anda melampirkan objek riwayat dengan API, laman yang Anda navigasikan kembali _tidak_ sama dengan laman yang akan Anda lihat jika Anda tempel di URL yang sama. Ini tampaknya rusak ... dan setidaknya berlebihan dengan kemampuan Anda untuk menyimpan status arbitrer di JS selama sesi browser.

Baunya seperti API di mana pelaksana browser berpikir, "Wah, bukankah akan rapi jika Anda bisa...", dan tidak mempertimbangkan konsekuensi sebenarnya.

Saya pikir Anda membuat asumsi tentang perilaku aplikasi yang diinginkan dan juga perincian peristiwa riwayat yang lebih ketat daripada yang disediakan oleh API browser. Secara khusus, tidak ada alasan untuk kerangka kerja dan bukan aplikasi untuk mendikte perilaku saat dipanggil dengan URI. Tampaknya secara sempurna dan jelas sah bahwa ada status (diberikan oleh jalur navigasi) yang ortogonal terhadap sumber daya (dan status yang disandikan) yang diidentifikasi oleh URI, dan bahwa presentasi dikondisikan pada keduanya. Jelas pilihan itu harus tergantung pada masing-masing aplikasi.

Selain argumen abstrak itu, beri tahu saya bagaimana Anda akan menerapkan misalnya formulir entri yang dapat di-bookmark yang menawarkan untuk menyimpan/membuang perubahan saat dinavigasi keluar dari (termasuk dengan tombol kembali) menggunakan History API?

Ini adalah perubahan satu atau dua baris. Jika Anda tidak ingin menambahkan parameter ke History.navigate , parameter tersebut juga dapat dibuat menggunakan status yang diberikan melalui misalnya atribut atau fungsi currentState .

beri tahu saya bagaimana Anda menerapkan, misalnya, formulir entri yang dapat di-bookmark
yang menawarkan untuk menyimpan/membuang perubahan saat dinavigasi keluar dari (termasuk
dengan tombol kembali) menggunakan History API?

Saya hanya akan menyimpan perubahan formulir di tempat yang berbeda dan lebih aman: Di sesi, di server, di penyimpanan lokal...

Saya ingin tahu tentang pendapat orang tentang posisi ini, jadi saya bertanya:

https://twitter.com/jashkenas/status/142736117895151616

Dan inilah beberapa balasannya:

https://twitter.com/juandopazo/status/142737949178601472

https://twitter.com/yaypie/status/142737982879842304

https://twitter.com/fortes/status/142742305877659648

https://twitter.com/dyakovlev/status/142743995020349441

https://twitter.com/bassistance/status/142882410982420481

History API menangani secara khusus status aplikasi yang terkait dengan jalur navigasi, berbeda dari URI. Yaitu "Bagaimana kita bisa sampai di sini?" Mungkin itu harus disebut API Histerisis. Kami mungkin berbagi URI yang sama dan berada di 'halaman' yang sama tetapi tampilan/halaman/status pengembalian yang sama ketika saya menekan tombol kembali pada mouse atau menggesek kembali pada ponsel Anda. Dan tindakan balik itu dapat mengubah status/riwayat aplikasi tanpa mengubah URI. Tidak semua transisi nav adalah transisi URI. Jadi, ketika kami membagikan URI, hal itu dapat menyebabkan penyajian sumber daya atau 'halaman' yang sama tetapi tidak dengan status navigasi yang sama.

Sementara saya menghargai pengalaman kawanan Anda, saya pikir itu hanya menunjukkan bahwa sebagian besar pengembang belum menemukan cara menggunakan API seperti yang dimaksudkan oleh pembuatnya. Itu bukan alasan yang baik bagi kerangka kerja untuk membukanya.

Juga, Anda tidak menjawab pertanyaan, yang bukan bagaimana mempertahankan nilai formulir, melainkan bagaimana menggunakan API Push/popState untuk meminta pengguna menyimpan perubahan, jika ada, ketika mereka menekan tombol kembali untuk nav jauh dari formulir dengan URI yang dapat di-bookmark. Harap pertimbangkan untuk mengatasinya.

Saya sangat baru di Backbone dan WebDev secara umum, namun saya setuju dengan tribalvibes.

Saya ingin membuat aplikasi web berdasarkan API Grafik Facebook dan menggunakan fungsi navigasi Backbone untuk memungkinkan pengguna kembali ke item yang berbeda untuk dilihat, mirip dengan apa yang dilakukan Facebook sekarang. Namun, tanpa objek negara di pushState, pengguna harus memuat ulang item dari API, yang jelas mahal.

Mungkin karena saya tidak tahu apa pola umum untuk masalah ini, tetapi saya pikir memiliki objek status untuk ini akan sangat membantu.

Per dokumentasi MDN, objek status disimpan ke disk. Saya tidak mengerti apa bedanya dengan menyimpan ke penyimpanan lokal. Saya pikir ini harus diluruskan kembali. Menggunakan penyimpanan lokal atau metode lain untuk menyimpan status tampak asing ketika Anda memiliki objek status yang tersedia untuk Anda di api histori.

Benar, tetapi kontra: Menggunakan objek status harus tidak relevan ketika Anda memiliki penyimpanan lokal, cookie, atau metode penyimpanan status lainnya yang _tidak_ hanya terkait dengan URL saat ini.

Mengapa tidak lebih baik menggunakan alat yang disediakan? Objek status menyediakan metode langsung untuk menyimpan dan mengakses status sebelumnya. Daripada memilah-milah penyimpanan lokal setiap kali pengguna tiba di halaman, memiliki history.state yang tersedia akan memungkinkan kemampuan untuk mengingat tidak hanya status umum tampilan melalui rute url, tetapi juga status spesifik dari tampilan yang pengguna mungkin ingin kembali ke.

Dalam pandangan saya, aplikasi sederhana yang menggunakan rute harus menggunakannya dengan sederhana. Salin dan tempel url untuk pengalaman penuh. Aplikasi kompleks harus menggunakan rute hanya sebagai titik masuk sederhana ke area umum aplikasi, atau catatan tertentu, lalu menggunakan api penyimpanan yang lebih mewakili jenis persistensi, baik itu pengguna (server), sesi, atau lokal.

Menggunakan objek status riwayat mengalahkan apa yang hebat tentang cara sederhana aplikasi satu halaman dapat menggunakan url sebagai bookmark yang berpotensi permanen.

Backbone selalu sangat fleksibel dan kurang berpendirian dibandingkan dengan kerangka kerja lainnya. Saya tidak mengerti mengapa ini berbeda dengan window.history.pushState asli. Saya mengerti bahwa beberapa orang tidak akan menyukainya. Namun, keputusan untuk menggunakannya atau tidak harus diserahkan kepada pengguna akhir.

Jadi tolong, pikirkan kembali.

@rafayepes Saya sepenuhnya setuju dengan argumen Anda. Saya menyukai Backbone dan kesederhanaannya, tetapi perubahan API ini menimbulkan banyak masalah dan solusi dalam kode, ketika aplikasi harus menyimpan hubungan 1-ke-1 antara url dan status. Cara asli berinteraksi dengan History API akan jauh lebih mudah.