Backbone: يجب أن يسمح History.navigate بتحديد كائن الحالة

أخشى أنني لا أوافق - لكن من فضلك حاول إقناعي بخلاف ذلك.

الهدف من History API هو توفير عناوين URL قابلة للإشارة وقابلة للمشاركة ، بحيث يمكنك الرجوع إليها. إذا قمت بإرفاق كائن محفوظات بواجهة برمجة التطبيقات ، فإن الصفحة التي تنتقل إليها مرة أخرى ليست هي نفس الصفحة التي قد تراها إذا قمت بلصق عنوان URL مطابق. يبدو هذا معطلاً ... وعلى الأقل زائدة عن الحاجة مع قدرتك على تخزين الحالة التعسفية في JS أثناء جلسة المتصفح.

تنبعث منه رائحة واجهة برمجة التطبيقات حيث يعتقد منفذو المتصفح ، "جي ، لن يكون أنيقًا إذا استطعت ..." ، ولم يأخذوا في الاعتبار العواقب الحقيقية.

أعتقد أنك تضع افتراضات حول سلوك التطبيق المرغوب وأيضًا دقة أحداث السجل التي تكون أكثر تقييدًا مما توفره واجهة برمجة تطبيقات المتصفح. على وجه التحديد ، لا يوجد سبب يجب أن يكون الأمر متروكًا لإطار العمل وليس التطبيق لإملاء السلوك عند الاستدعاء باستخدام URI. يبدو من المشروع تمامًا ومن الواضح أن هناك حالة (معطاة من خلال مسار التنقل) متعامدة مع المورد (والحالة المشفرة) التي تم تحديدها بواسطة URI ، وأن العرض مشروط بكليهما. من الواضح أن هذا الاختيار يجب أن يعود إلى التطبيق الفردي.

بصرف النظر عن هذه الحجة المجردة ، أخبرني كيف يمكنك تنفيذ نموذج إدخال قابل للإشارة على سبيل المثال يوفر حفظ / تجاهل التغييرات عند الانتقال بعيدًا عن (بما في ذلك الزر الخلفي) باستخدام History API؟

هذا تغيير خط واحد أو سطرين. إذا كنت لا ترغب في إضافة معلمة إلى History.navigate ، فيمكن أيضًا إجراؤها لاستخدام الحالة المعطاة عبر سمة أو وظيفة على سبيل المثال currentState .

أخبرني كيف ستنفذ على سبيل المثال نموذج إدخال قابل للإشارة المرجعية
يعرض حفظ / تجاهل التغييرات عند الانتقال بعيدًا عن (بما في ذلك
مع زر الرجوع) باستخدام History API؟

أود ببساطة تخزين تغييرات النموذج في مكان مختلف وأكثر أمانًا: في الجلسة ، في الخادم ، في التخزين المحلي ...

كنت أشعر بالفضول بشأن رأي الناس في هذا المنصب ، لذلك سألت:

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

وإليكم بعض الردود:

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 بشكل خاص مع حالة التطبيق المرتبطة بمسار التنقل ، والتي تختلف عن URI. أي "كيف وصلنا إلى هنا؟" ربما ينبغي أن يطلق عليه Hysterisis API. قد نشارك نفس عنوان URI ونكون على نفس "الصفحة" ولكن ليس نفس طريقة عرض / صفحة / حالة الإرجاع عندما أضغط على زر الرجوع بالماوس أو اسحب مرة أخرى على هاتفك المحمول. وقد يؤدي هذا الإجراء الخلفي إلى تغيير حالة / سجل التطبيق دون تغيير URI. ليست كل انتقالات التنقل هي انتقالات URI. لذلك عندما نشارك URI ، فقد يؤدي ذلك إلى تقديم نفس المورد أو "الصفحة" ولكن ليس نفس حالة التنقل.

بينما أقدر تجربة قطيعك ، أعتقد أنه يظهر فقط أن معظم المطورين لم يكتشفوا بعد كيفية استخدام واجهة برمجة التطبيقات على النحو الذي قصده المنشئون. هذا ليس سببًا جيدًا لإطار العمل لتمهيده.

أيضًا ، لم تعالج السؤال ، الذي لم يكن كيفية الاستمرار في قيم النموذج ، ولكن بدلاً من ذلك كيفية استخدام push / popState API لمطالبة المستخدم بحفظ التغييرات ، إن وجدت ، عند الضغط على زر الرجوع للتنقل بعيدًا عن النموذج الذي يحتوي على URI القابل للإشارة. يرجى النظر في معالجة ذلك.

أنا جديد جدًا على Backbone و WebDev بشكل عام ، لكنني أتفق مع القبائل.

أرغب في إنشاء تطبيق ويب استنادًا إلى واجهة برمجة تطبيقات الرسم البياني في Facebook واستخدام وظيفة التنقل في Backbone للسماح للمستخدم بالعودة إلى عناصر مختلفة لعرضها ، على غرار ما يفعله Facebook الآن. ومع ذلك ، بدون stateobject في pushState ، يتعين على المستخدم إعادة تحميل العنصر من واجهة برمجة التطبيقات ، وهو أمر مكلف بشكل واضح.

ربما لأنني لا أعرف ما هو النمط الشائع لهذه المشكلة ، لكنني أعتقد أن وجود كائن حالة لهذا سيكون مفيدًا للغاية.

وفقًا لوثائق MDN ، يتم حفظ كائن الحالة على القرص. لا أفهم كيف يختلف ذلك عن الحفظ في التخزين المحلي. أعتقد أن هذا يجب أن يعاد لبسه. يبدو استخدام التخزين المحلي أو طريقة أخرى لحفظ الحالة غريبًا عندما يكون لديك كائن الحالة متاحًا لك في سجل api.

صحيح ، لكنه مخالف: يجب أن يكون استخدام كائن الحالة غريبًا عندما يكون لديك تخزين محلي أو ملفات تعريف ارتباط أو أي طريقة أخرى لحفظ الحالة _لا _ مرتبطة ببساطة بعنوان URL الحالي.

لماذا لا يكون من الأفضل استخدام الأداة المتوفرة؟ يوفر كائن الحالة طريقة مباشرة للحفظ والوصول إلى الحالات السابقة. بدلاً من غربلة التخزين المحلي في كل مرة يصل فيها المستخدم إلى صفحة ، فإن توفر history.state سيسمح بالقدرة على تذكر ليس فقط الحالة العامة للعرض عبر مسار عنوان url ، ولكن أيضًا الحالة المحددة لطريقة العرض التي يستخدمها المستخدم قد ترغب في العودة إلى.

من وجهة نظري ، التطبيقات البسيطة التي تستخدم المسارات يجب أن تستخدمها ببساطة. انسخ والصق عنوان url للتجربة الكاملة. يجب أن تستخدم التطبيقات المعقدة المسارات فقط كنقاط دخول بسيطة إلى مناطق عامة من التطبيق ، أو سجلات معينة ، ثم تستخدم واجهات تخزين تمثل نوع الاستمرارية بشكل أفضل ، سواء كان مستخدمًا (خادمًا) أو جلسة أو محلية.

يؤدي استخدام كائن حالة السجل إلى التغلب على ما هو رائع حول الطريقة البسيطة التي يمكن بها لتطبيقات الصفحة الواحدة استخدام عناوين url كإشارات مرجعية دائمة.

لطالما كان العمود الفقري مرنًا جدًا وأقل رأيًا من الأطر الأخرى. لا أفهم سبب اختلاف هذا مع النافذة الأصلية window.history.pushState. أتفهم أن بعض الناس لا يحبون ذلك. ومع ذلك ، يجب ترك قرار استخدامه أو عدم استخدامه للمستخدم النهائي.

لذا من فضلك ، أعد التفكير في الأمر.

rafayepes أنا أتفق تمامًا مع حجتك. أنا أحب Backbone وبساطته ، لكن تغيير واجهة برمجة التطبيقات هذا يقدم مجموعة من المشكلات والحلول في الكود ، عندما يجب على التطبيق تخزين علاقة 1 إلى 1 بين عنوان url والحالة. الطريقة الأصلية للتفاعل مع History API ستكون أسهل بكثير.