Knex: كيف يتم التهيئة لاستخدام معيار ES6 Promise؟

فضولي: هل تريد استبدال مكتبة أسرع بمكتبة مدمجة أبطأ؟ لا يهم العميل ولكن في سرعة العقدة عامل. ما هو سبب ذلك؟

johanneslumpe إنه عامل في بعض التطبيقات ، مع knex أشك بشدة في أن استخدام مكتبة Promise له أي تأثير كبير على الأداء. لقد تمت مناقشة أنه يجب علينا كتابة كل كود Promise لاستخدام واجهات برمجة تطبيقات A + فقط حتى لا تكون هناك حاجة إلى bluebird .

بعد ذلك يجب أن يكون من السهل تجاوز مكتبة Promise المستخدمة.

أوافق على أنه لا معنى له في مكتبة مثل knex. بالنظر إلى أن مصدر الكود الخاص بـ knex يستورد بالفعل ملف promal.js الخاص به داخليًا ، فسيظل من السهل جدًا تنفيذه من الناحية الفنية ، بشرط أن تكون واجهة برمجة التطبيقات هي نفسها _ (وهو ما لست متأكدًا منه؟) _. في هذا الملف ، يمكن للمرء أن يتقيد بالوعود العالمية بشكل افتراضي ، أو يتطلب مكتبة مهيأة ، أو شيء من هذا القبيل.

يتعلق الأمر كله بمنح المستخدمين خيارًا ؛ بالنسبة لمستخدمي Node V6 + ، امنحهم خيار إدارة تبعيات الطرف الثالث بأدنى حد ممكن.

فضولي: هل تريد استبدال مكتبة أسرع بمكتبة مدمجة أبطأ؟

ما تقوله قد يكون صحيحًا في الماضي ، لكن ماذا عن الآن أو بعد 6 أشهر؟ (لقد أجريت بعض البحث ولا يمكنني العثور إلا على بعض المعايير القياسية لعام 2015 ، إذا كانت لديك مقارنة أحدث ، فيرجى نشر بعض الروابط)
أعتقد أن الهدف الأساسي من جعل معيار Promise هو ES6 هو أن يستخدم الأشخاص Promise بسهولة ، دون الاضطرار إلى الاعتماد على مكتبة تابعة لجهات خارجية ، ولا يمكن للفريق الأساسي لـ Node أو V8 أن يتجاهل اختلاف الأداء إلى الأبد ، طالما تراخيص المصدر المفتوح للمشروعين متوافقة ، ويمكنهما حتى استعارة بعض التعليمات البرمجية ؛ أو امنحهم بعض الوقت فقط أعتقد أن الوعد المدمج يمكن أن يكون أسرع وأفضل.

راجع AWS-SDK من Amazon: من الافتراضي أيضًا استخدام أي وعد متاح عالميًا ؛ مع منح المستخدم خيارًا لتهيئة مكتبة Promise المفضلة أيضًا

http://docs.aws.amazon.com/AWSJavaScriptSDK/guide/node-making-requests.html#Support_for_Promises

الأمر كله يتعلق بالاختيارات

في التفكير الثاني ، لن يكون الأمر سهلاً مثل تغيير ملف واحد. تعتمد Knex حاليًا كثيرًا على وظائف الأداة المساعدة Bluebird مثل .timeout ، .tap ، .reduce ، .map وما إلى ذلك ، والتي تفترض وتتوقع عدم وجودها في وعود ES6.

أنا مهتم بدعم وعود ES6. من الناحية المثالية ، سنطلب وسيطة ثانية لمُنشئ Knex الذي يأخذ مُنشئ Promise . يمكن تحقيق التوافق الخلفي على النحو التالي:

const Promise = require('bluebird');
const knex = Knex(myKnexConfig, Promise);

ربما يمكننا الحصول على الاسم المستعار المشروط map ، filter وما إلى ذلك بناءً على وجودهم على Promise.prototype ؟

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

سأكون أكثر ميلًا للانتظار حتى الانتظار غير المتزامن / الانتظار في عقدة مستقرة للنظر في معالجة هذا الأمر.

بالنسبة للأشخاص الذين يريدون الحد الأدنى من تبعيات الطرف الثالث ، يمكن أن يكون الوعد الأصلي أفضل ،

مثل @google-cloud والعديد من المكتبات الأخرى ، يمكنك جعله افتراضيًا لاستخدام Promise الأصلي وقبول معلمة الوعد لمن يريد استخدام مكتبات الطرف الثالث

https://googlecloudplatform.github.io/google-cloud-node/#/docs/google -cloud /

var gcloud = require('google-cloud')({
  promise: require('bluebird')
});

tgriesser أعلم أن هذه مشكلة قديمة ، لكن لدينا الآن async / await في كل من المستقر والكربون.

بالنظر إلى أنه من المفضل عدم التزامن / انتظار العمل مع الوعود الأصلية ( وفقًا للمواصفات ، يجب أن تعيد الوظائف async وعدًا محليًا ) هل هذه أولوية أعلى؟

إذا كان دعم الوعد المحلي شيئًا تود Knex حدوثه ، لكنه ليس على الرادار حاليًا ، فهل سيكون العلاقات العامة موضع ترحيب؟

شكرا على وقتك.

وظائفmalexdev async تُعيد وعودًا محلية ، لا علاقة لها كثيرًا بـ knex حاليًا. هذا لا يعني أن await يحتاج إلى وعود محلية للعمل بشكل صحيح. هل يمكنك أن توضح في هذه الحالة هذه مشكلة / فائدة (باستثناء إسقاط تبعية واحدة)؟

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

elhigu الفائدة الرئيسية بالنسبة لي شخصيًا هي أنني أستخدم TypeScript مع قاعدة TSLint التي تفرض وعودًا محلية يتم استخدامها مقابل await ، لذلك يجب أن أغلق جميع مكالمات Knex داخل Promise.resolve() . أدرك أن هذا لا يتعلق بأي شيء مع Knex على وجه التحديد ، ومن المحتمل أن تكون مشكلة فريدة بالنسبة لي.

بخلاف ذلك ، في رأيي ، من الأفضل وجود تبعيات أقل للجهات الخارجية ، وكما ذكر @ c0b ، فإن المزيد من الخيارات ليس بالأمر السيئ أبدًا.

أدرك أنه سيكون هناك الكثير من العمل ، وهذا أحد الأسباب التي تجعلني أكثر من سعيد لقضاء بعض الوقت في هذا ، إذا كان ذلك شيئًا تهتم Knex بالتحرك نحوه.

نعم ، لقد جئت إلى هنا قادمًا من مشكلة مطبوعة - أنا أستخدم Knex كمحرك SQL لمكتبة مخزن البيانات متعددة التخزين الخاصة بي ، وعلى الرغم من أنني متناقض مع الوعود الأصلية مقابل وعود بلوبيرد ، لا يمكنني استخدامها بسهولة مطبوعة على كنكس لهذا السبب. أتعامل مع عناصر knex على أنها تتبع المواصفات الأصلية (لا أستخدم أيًا من امتدادات بلوبيرد) ، لكن الكتابة المطبوعة تزعجني بشأن إرجاع Bluebirdعندما يكون إعلان الطريقة عبارة عن وعد.

هذا نوع من مستويين عميقين هنا ، حيث نتعامل مع كل من تنفيذ الوعد وطباعة knex (التي يتم التعامل معها بواسطة مطورين مختلفين) ، لكنني عالق هنا بشكل أساسي - أنا أقوم من الناحية الفنية بخرق نوع العقد من خلال إعادة بلوبيرد عندما أعلنت وعدًا (أعتقد أن هناك أشياء في واجهة الوعد لا يدعمها بلوبيرد؟) لكنني حقًا لا أشعر برغبة في وضع مجموعة من return Promise.resolve(bluebirdthing) في كل مكان أيضًا.

لقد أمضيت وقتًا كافيًا في البحث في شجاعة knex خلال العام الماضي والعمل مع الوعود بشكل عام بأنني سأكون على استعداد لاتخاذ شيء ما هنا والعمل على العلاقات العامة لتكوين وحدات تنفيذ الوعد إذا أراد الناس - هل ستكون كذلك منفتحة على العلاقات العامة؟ سينتهي الأمر بشيء مثل ما ذكره elhigu - إعادة تنفيذ بعض وظائف الأداة المساعدة لاستخدام أي مُنشئ Promise تم تمريره عند إنشاء مثيل لذلك لتجنب احتياجات إعادة كتابة التعليمات البرمجية. لست متأكدًا من الأداء بالطبع ، لكن هذا شيء يمكن قياسه.

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

ericeslinger لا أفهم سبب تسبب تطبيق Promise الحقيقي الذي يتم استخدامه في حدوث مشكلات مع TypeScript ، لقد كنت أمزج بين Bluebird والوعود الأصلية لمدة عام ونصف دون أي مشاكل ...

أنا فقط لم أستخدم أي كتابة من شأنها أن تقدم أنواعًا لـ Bluebird ، أنا فقط أخبر الكتابة المطبوعة على أنها وعود عادية ولا ترى أي فرق (ofc. ستشتكي إذا حاولت استخدام أساليب Bluebird الخاصة).

ما هي نسخة مطبوعة وهل هناك أي مثال لمشروع إعادة إنتاجه ... على سبيل المثال github repo مع npm start script.

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

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

أحصل على كتاباتي من ريبو DefinitelyTyped عن طريق تثبيت @types/knex . هذا التعريف يسحب معه @types/bluebird ، ويتم كتابة جميع طرق knex على أنها كائنات Bluebird عائدة.

كشيء محدد ، لا يمكنني القيام بذلك:

function mungeData(v: any): DataItem {} 
function foo(): Promise<DataItem[]> {
  return knex('data').select()
  .then((rows) => rows.map(row => mungeData(row)))
} // error, cannot return Bluebird<DataItem[]> as Promise<DataItem[]>

باستخدام هذه الأنواع. هذا لأن knex.select (). ثم () يُكتب لإرجاع Bluebird في DefinitelyTyped repo ، وتلك السلسلة معًا لصنع المزيد من Bluebirds ، وقول شيء مثل return foo as Promise<any>() عندما يكون foo هو Bluebirdسيفشل (على الأقل يفشل في الكتابة المطبوعة 2.4) ، لأن Bluebirds غير قابل للتخصيص إلى Promises (يفتقرون إلى [Symbol.toStringTag] وفقًا لذلك ، لذا فإن إجبار أحدهما على الآخر سيكون خطأ ، وإن كان خطأ بسيطًا).

بدلا من ذلك يمكنني التغيير إلى

function bar(): Promise<DataItem[]> {
  return Promise.resolve<DataItem[]>(foo())
}

أو قم بحيل أخرى لإغلاق جميع المكالمات إلى knex داخل مكالمة محلية Promise.resolve (). سيؤدي ذلك إلى توقف الكتابة المطبوعة عن الشكوى من وظائف المكتبة الخاصة بي ، مع السماح لي باستخدام كتابات knex داخل وظائف مكتبتي.

قبل الأمس ، لم أستخدم @types/knex على الإطلاق - كنت أكتب knex كـ any . يعمل الكود بشكل جيد في كلتا الحالتين في وقت التشغيل (لحالة الاستخدام الخاصة بي على الأقل) ، إنه فقط

elhigu : المشكلة ليست معطلة تطبيقات الكتابة.
يعيّن TypeScript نوع وظائف async كـ Promise<[type]> ، وهو صحيح وفقًا لمواصفات JS.
تقوم Knex بإرجاع Bluebird<[type]> ، والتي تعكسها الكتابة بدقة.

أنا فقط لم أستخدم أي كتابة من شأنها أن تقدم أنواعًا لـ Bluebird ، أنا فقط أخبر الكتابة المطبوعة على أنها وعود عادية ولا ترى أي فرق

هذا كذب على المترجم ، حيث تقوم وظائف Knex بالفعل بإرجاع Bluebird s. غير مهتم.
أنت محق في أن Bluebirds متوافق مع Promises ، لكن جزءًا من الصفقة مع TypeScript هو أنك تعيد بالفعل ما تقول أنك ستعود إليه.

عند إرجاع Bluebird من دالة تمت كتابتها لإرجاع Promise ، يشكو TypeScript لأن النوع Bluebird ليس هو نفسه النوع Promise .
هناك العديد من الحيل التي يمكننا القيام بها (مثل ما ذكره ericeslinger حول استخدام any ، أو التغليف بـ Promise.resolve() ) ولكن في نهاية اليوم ، تجعلنا حيل كهذه نخسر الكثير من ما يوفره TypeScript.

في نهاية اليوم ، الحقيقة هي أن هناك الآن ما لا يقل عن مستخدمين اثنين يقولان "استخدام الوعود الأصلية أمر مهم بالنسبة لنا ، ونحن على استعداد لبذل جهد لجعل وظيفة الوعد أكثر عمومية".

أدرك أنك تحاول فقط المساعدة ، ولكن بصراحة بدلاً من سماع "يمكنك فعل ذلك بهذه الطريقة" ، أود معرفة ما إذا كانت تغييرات الوعد التي اقترحتها / ericeslinger / @ c0b مقبولة حتى يمكنني البدء على العلاقات العامة أم ماذا.

malexdevericeslinger شكرا لمزيد من المعلومات! يبدو أنه ليس من الممكن في الواقع أن ترث فصلك الدراسي من Promise لذلك قد يكون هذا هو السبب وراء فشل إرجاع Bluebirds من الوظيفة التي تمت كتابتها لتكون Promise <>:

ericeslinger على أي حال ، هذه ليست مشكلة عند إنشاء وظائف async ، حيث إنها تلتف تلقائيًا بالنتائج إلى الوعود المحلية داخليًا. يتوافق ما يلي دون مشكلة ، مع كتابة من @ أنواع / بلوبيرد وترجمة إما إلى ES2015 أو ESNEXT.

import * as Bluebird from 'bluebird';

// declaring function async converts bluebird implicitly to native Promise
async function asyncReturningPromise(): Promise<string> {
    const blueBirdPromise = new Bluebird<string>((resolve, reject) => { 
        resolve('yay asyncReturningPromise');    
    });
    return blueBirdPromise;
}

// main func to run the code using async / await
Bluebird.resolve().then(async () => {
    console.log("await function returning promise (bluebird)", await asyncReturningPromise());

    const blueBird = new Bluebird((resolve, reject) => { resolve(); });
    const returnedFromAsync = asyncReturningPromise();

    console.log("Bluebird instanceof Promise:", blueBird instanceof Promise);
    console.log("async retval instanceof Promise:", returnedFromAsync instanceof Promise);
});

انتاج:

await function returning promise (bluebird) yay asyncReturningPromise
Bluebird instanceof Promise: false
async retval instanceof Promise: true

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

تضمين التغريدة

هذا كذب على المترجم ، حيث تقوم وظائف Knex بالفعل بإرجاع Bluebirds. غير مهتم.
أنت محق في أن Bluebirds متوافق مع Promises ، لكن جزءًا من الصفقة مع TypeScript هو أنك تعيد بالفعل ما تقول أنك ستعود إليه.

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

class FakePromise<T> implements Promise<T>  {
    [Symbol.toStringTag]: "Promise";
    then<TResult1, TResult2>(onfulfilled?: (value: T) => TResult1 | PromiseLike<TResult1> | null | undefined, onrejected?: (reason: any) => TResult2 | PromiseLike<TResult2> | null | undefined): Promise<TResult1 | TResult2> {
        return new Promise((resolve, reject) => { resolve('Im totally broken and fake!); });
    }
    catch<TResult>(onrejected?: (reason: any) => TResult | PromiseLike<TResult> | null | undefined): Promise<T | TResult> {
        throw new Error("Method not implemented.");
    }
}

// this works and  fake promise instance has nothing to do with native promise
function returningPromiseInterface(): Promise<string> {
    const fakePromise = new FakePromise<string>();
    return fakePromise;
}

// compiling this fails, because looks like Bluebird actually doesn't implement Promise interface correctly
function asyncReturningPromise(): Promise<string> {
    const blueBirdPromise = new Bluebird<string>((resolve, reject) => { 
        resolve('yay asyncReturningPromise');    
    });
    return blueBirdPromise;
}

إنه يعبث بمثيل ، لكن الكتابة المطبوعة في الواقع لم تعد حتى بإرجاع مثيل الوعد الأصلي ، فقط الواجهة.

عند إرجاع Bluebird من وظيفة تمت كتابتها لإرجاع Promise ، يشكو TypeScript لأن نوع Bluebird ليس مطابقًا لنوع Promise.
هناك العديد من الحيل التي يمكننا القيام بها (مثل ما ذكره ericeslinger حول استخدام أي منها ، أو الالتفاف في Promise.resolve ()) ولكن في نهاية اليوم حيل كهذه تجعلنا نخسر الكثير مما توفره TypeScript.

أنا أكره أن أرى الناس يضطرون إلى القيام بهذا النوع من الحيل / تغيير تطبيقات JS فقط لإرضاء الكتابة السيئة.

في نهاية اليوم ، الحقيقة هي أن هناك الآن ما لا يقل عن مستخدمين اثنين يقولان "استخدام الوعود الأصلية أمر مهم بالنسبة لنا ، ونحن على استعداد لبذل جهد لجعل وظيفة الوعد أكثر عمومية".

أدرك أنك تحاول فقط المساعدة ، ولكن بصراحة بدلاً من سماع "يمكنك فعل ذلك بهذه الطريقة" ، أود معرفة ما إذا كانت تغييرات الوعد التي اقترحتها / ericeslinger / @ c0b مقبولة حتى يمكنني البدء على العلاقات العامة أم ماذا.

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

كما أنني ما زلت أعتبر مشاكل الكتابة المطبوعة المذكورة في هذا الموضوع على أنها مشاكل في إعلان الطباعة (لماذا لا يقوم بلوبيرد بتنفيذ Promise بشكل صحيح ... أحتاج إلى التعمق أكثر في ذلك؟) ، من المشكلات في تنفيذ knex.

ومع ذلك ، فأنا لا أعارض التخلص من العصفور الأزرق في بعض الفترات الزمنية عندما أرى فقط مشكلتين منفصلتين هنا.

: +1: للوعود الأصلية.

elhigu :

في الواقع ، التعامل مع الكتابة المطبوعة هو أنه يكفي أن يقوم الكائن المرتجع بتنفيذ الواجهة بشكل صحيح

عادلة بما فيه الكفاية. ما زلت متمسكًا برأيي القائل بأن التبعيات الأقل والمزيد من الخيارات أفضل ، لكني الآن أرى ما تعنيه بشأن الكتابة المكسورة.

لا يزال 👍 بالنسبة للوعود الأصلية (التي ما زلت على استعداد للمساعدة فيها) ، لكني أرى الآن أنه يمكن حل مشكلتي الفورية عن طريق إصلاح كتابات Bluebird. شكرا للمعلومة.

لذلك بدأت في استخدام TypeScript قليلاً وأنا أحبه وأدرك الآن أن المشكلات هنا هي نقطة ألم حقيقية. أثناء انتظار المكاسب الإضافية في موطئ قدم في Node Land الأخيرة ، فإن الأداة المساعدة Bluebird fns ( map ، reduce ، tap ، bind ، return ) تصبح أقل فائدة. سأكون رائعًا مع الاستمرار في استخدام Bluebird داخليًا ولكن رسميًا "إهمال" واجهة برمجة التطبيقات العامة لمنشئ استعلام knex وإرجاع جميع طرق الأدوات الإضافية.

مع هذا الدمج ، يمكننا بعد ذلك ترقية تعريفات TypeScript لإسقاط كتابات Bluebird (باستثناء toBluebird ) ، وتغيير كتابة Bluebird إلى Promise Typings.

إذا كان أي شخص لديه عرض النطاق الترددي يريد معالجة هذا ، فإليك ما أفكر به لخطة عمل:

• [] أضف تحذيرًا بإيقاف جميع طرق Bluebird التي تم إنشاء وكيل لها ( tap ، map ، reduce ، bind ، return ).
• [] أضف طريقة .toBluebird() والتي ستكون مسارًا للترحيل لأولئك الذين يريدون الاستمرار في استخدام Bluebird (يمكنهم القيام بذلك عن طريق البحث / الاستبدال البسيط لجميع مكالمات الطرق المذكورة أعلاه وإضافتها من قبل هؤلاء يسمون)
• [] بمجرد دمج هذا الإصدار الجديد / قصه (0.15) يمكننا تحديث تعريفات التنضيد
• [] في النهاية يمكننا التخلي عن هذه الأساليب تمامًا. تمهد واجهة برمجة التطبيقات الأبسط هذه الطريق لاستخدام الوعود الأصلية وغير المتزامنة / الانتظار عندما يكون ذلك منطقيًا.

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

سأكون بالتأكيد مهتمة للمساعدة في هذا.

هل هذا يعني أن Knex ستبدأ في الحفاظ على تعريفات TypeScript الخاصة بها؟ سيسمح لنا بالقيام ببعض الأشياء الرائعة باستخدام الأدوية الجنيسة التي لن تدعمها الكتابة التلقائية.

لقد بدأت هذه الشوكة كمحاولة أولى لإضافة دعم للوعود الأصلية:
https://github.com/tgriesser/knex/pull/2523/files

مثل هذا التعليق من عام 2016:

فضولي: تريد استبدال مكتبة أسرع بمكتبة مدمجة أبطأ

مذهل كم يمكن أن يتغير في 2 سنوات.

عند إرجاع Bluebird من وظيفة تمت كتابتها لإرجاع Promise ، يشكو TypeScript لأن نوع Bluebird ليس مطابقًا لنوع Promise.

malexdev في الواقع يستخدم الكتابة المطبوعة الهيكلية (يستخدم التدفق الكتابة الاسمية وسيعمل بالطريقة التي تصفها) طالما أن النوع الخاص بك يفي بواجهة Promise فهو متوافق مع Promise سواء كان صريحًا extends / implements ذلك أم لا.

كيف يتم هذا التقدم؟ أعتقد أن الخطوة الأولى الجيدة هي استبعاد استدعاءات أسلوب Bluebird المعينة داخل knex (أي لا تقم بإزالتها بالفعل بعد). ستتبع إزالة بلوبيرد وتوفير خيار لمنشئ وعد مخصص (ويمنح الأشخاص الذين يستخدمون طرق بلوبيرد مسار ترقية).

لا أبدأ العمل في الخطوة الأولى إذا لم تكن هناك اعتراضات. يبدو أن العمل الحالي قد تلاشى.

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

نعم. في الجزء التالي من وقت فراغي ، سأجري بعض التغييرات الصغيرة قدر الإمكان لاستخراج كل طريقة.

tgriesser هل توجد أية آراء عندما يجب أن نمضي قدمًا مع هذا (إن وجد)؟ بالنسبة لي ، قد يبدو شهر أبريل المقبل وقتًا معقولاً عندما يصل Node 6 LTS إلى نهاية السطر.

معلومات مثيرة للاهتمام في 2018:

أداء promises-native-async-await أفضل من promises-bluebird في العقدة 10.
المرجع: https://github.com/petkaantonov/bluebird/tree/master/benchmark

لذا لم يعد الأداء سببًا للاحتفاظ بلوبيرد بعد الآن. يجب أن نذهب لعدم التزامن / الانتظار.

وعود - أصلي - غير متزامن - انتظار لديه أداء أفضل

هذا أيضًا ما كنت أؤمن به بشدة في عام 2016 أن الطريقة الأصلية ستتحسن بشكل أسرع ، لمجرد أنها جوهر مجتمع Nodejs ، ولديها عدد أكبر من الأشخاص المهتمين بها ، أكثر من أي مكتبات تابعة لجهات خارجية

بينما ، تم تقديم التذكرة للمطالبة بالخيارات ، هناك العديد من عمليات التنفيذ المتنافسة Promise ، ليس من الجيد المراهنة على بلوبيرد إلى الأبد

هل هناك أي تحديث على ذلك؟

cfanoulis نفسه لا يزال قائما. عندما يأتي أبريل ، يمكننا إسقاط دعم Node 6 والبدء في إزالة بلوبيرد.

أي تحديث 2019؟ / cc لبعض المساهمين الأساسيين أو المشرفين أو أي شخص @ هنا يهتم بذلك: johanneslumpetgriesserwubzzelhigu من https://github.com/tgriesser/knex/graphs/contributors؟type=c&from=2018-01- 01 & to = 2019-12-31

من ناحية أخرى ، مجتمع JavaScript هو عالم ديناميكي وحيوي وأحيانًا قاسي ، كل 3 أو 2 سنوات (أو حتى أسرع) هناك بدائل لشيء كنا مألوفًا من قبل ، فكر في Grunt ، Gulp => Webpack ، الأدوات ، تتنافس المكتبات والأطر بشكل كامل على كل مستوى ، لذلك ، بالنسبة للمكتبات القديمة إذا كنت تتوقف عن جلب الابتكارات ، أو تبطئ دعم المعايير الجديدة (فكر في ES2019 غير المتزامن / انتظار التكرارات ...) سيتم استبدالك في النهاية

لقد أجريت للتو بعض الأبحاث البسيطة ، يبدو أنه على مستوى DB ORM ، هناك أيضًا العديد من البدائل ، قد يكون TypeORM خيارًا جيدًا ... (أتوقف هنا حتى لا أقول المزيد ...)
https://bestofjs.org/tags/db
https://bestofjs.org/projects/typeorm

@ c0b لا حاجة لنسخة. أحصل على رسائل بريد إلكتروني من جميع التعليقات على أي حال. kibertoad قال للتو كل ما يجب أن يقال في تعليقه الأخير ... هذه المشكلة أيضًا لا علاقة لها بميزة knex التي تدعم غير متزامن / انتظار ميزات ES2019 بشكل أفضل و knex ليست ORM لذا لست متأكدًا مما كان هذا التعليق حقًا حول.

إذا كنت بحاجة إلى ORM جيد ، يمكنني أن أوصي بـ objection.js. يتم تنفيذه فوق knex أيضًا ، إليك موضوع جميل حوله https://github.com/Vincit/object.js/issues/1069

في مرحلة ما ، سيتم استبدال knex ، ولكن ليس بأي ORM. يمكن استبداله ببعض منشئ الاستعلام الآخر ، الذي يحتوي على قاعدة رمز أنظف وواجهة برمجة تطبيقات أكثر اتساقًا. مثل على سبيل المثال knex 1.0 ربما ؛)

وأيضًا إذا تم استبدال knex ، فسأكون على ما يرام تمامًا مع ذلك ، وسيقل العمل بالنسبة لي: D

هناك العمل قيد التقدم الذي أعتقده: https://github.com/tgriesser/knex-next

أردت فقط أن أذكر أيضًا أن عدم استخدام الوعود الأصلية يؤدي إلى https://github.com/nodejs/node/issues/22360 عند استخدام async_hooks مما يتسبب في فقد السياق الحالي.

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

بعد دمج # 3227 ، يمكننا البدء أخيرًا!

أعلم أنك ذكرت من قبل أنه يمكنك استخدام المساعدة في هذا الترحيل ، إذا كان هذا هو الاتجاه الذي تريد أن تسلكه ، فهل يمكننا المساعدة بأي طريقة؟

أفكر في: إنشاء مشروع وإضافة مهمتين ومعرفة ما إذا كان يمكن لأي شخص (ربما لدي الوقت) تعيينه وتحديد بعض التواريخ؟

chaffeqa ستنشئ بعض المهام الدقيقة قريبًا ، احصل على # 3250 للجولة الأولى من التغييرات السهلة. نحتاج بشكل أساسي إلى استبدال بلوبيرد. إذا كان لديك بعض الوقت بالفعل ، فيمكنك محاولة التفرع من # 3250 وإلقاء نظرة على أي متطلبات "بلوبيرد" متبقية (أوصي بالبدء بأخرى غير خاصة باللهجة بحيث يمكنك التحقق بسرعة من صحة الوظيفة التي لا تزال تعمل عن طريق تشغيل test:sqlite بدون أي إعداد Docker).

qubyte إذا كنت ترغب في المساهمة ، فقد حان الوقت الآن!

@ kibertoad هل أنا آمن لاستخدام غير متزامن / انتظر الآن؟

تقصد في قاعدة بيانات knex؟ بالتأكيد. في حياتك الخاصة كنت دائمًا: - د

https://github.com/tgriesser/knex/issues/3253
https://github.com/tgriesser/knex/issues/3254
https://github.com/tgriesser/knex/issues/3255
https://github.com/tgriesser/knex/issues/3256
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgriesser/knex/issues/3268
https://github.com/tgriesser/knex/issues/3286
جاهزة للاستيلاء عليها.

آسف لكوني MIA في الأسبوع الماضي ، تتزايد الأمور لشركتنا ، لذا يتعين علي التركيز هناك.

أردت إغلاق الحلقة في بعض المناقشات التي أجريناها حول إحدى الكتل الأكبر للترقية: استبدال استخدام Disposer .

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

لقد بدأت بالفعل في عدد قليل من POC ، وأعتقد أن هذا هو أبسطها:

class DisposablePromise extends Promise {

  disposerFunc = null;
  originalResource = null;

  then(onFulfilled, onRejected) {
    const $onFulfilled = this.wrap(onFulfilled);
    return super.then($onFulfilled, onRejected).copyContext(this);
  }

  copyContext(promise) {
    this.disposerFunc = promise.disposerFunc;
    this.originalResource = promise.originalResource;
    return this;
  }

  disposer(disposerFunc) {
    this.disposerFunc = disposerFunc
  }

  isDisposable() {
    return !!this.disposerFunc
  }

  wrap(onFulfilled: any) {
    const $onFulfilled = (result: any) => {
      if (this.disposerFunc && !this.originalResource) {
        this.originalResource = result
      }
      if (result instanceof Promise) {
        return onFulfilled(result);
      } else {
        const res = onFulfilled(result)
        if (this.disposerFunc) {
          this.disposerFunc(this.originalResource)
        }
        return res
      }
    };

    return $onFulfilled;
  }
}

وآخر:

      var DisposablePromise = function DisposablePromise() {
          var self = DisposablePromise.convert(Promise.resolve());
          return self;
      };
      DisposablePromise.convert = function convert(promise, props) {
          promise.__proto__ = DisposablePromise.prototype;
          return props ? Object.assign(promise, props) : promise;
      };
      DisposablePromise.prototype = Object.create(Promise.prototype);
      DisposablePromise.prototype.constructor = DisposablePromise;
      DisposablePromise.prototype.then = function then(resolve, reject) {
          var returnVal = Promise.prototype.then.call(this, resolve, reject);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.catch = function _catch(err) {
          var returnVal = Promise.prototype.catch.call(this, err);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.finally = function finall(obj) {
          var returnVal = Promise.prototype.finally.call(this, obj);
          return DisposablePromise.convert(returnVal);
      };
      DisposablePromise.prototype.disposer = function disposer(disposerFunc) {
        var returnVal = Promise.prototype.finally.call(this, obj);
        return DisposablePromise.convert(returnVal);
      };

لكن لم يتح لها الوقت لإثبات ذلك.

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

أود أن أقول أنه إذا تمكنا من معرفة هذا الجزء ، فإن بقية هذه المهام تكون مباشرة إلى الأمام.

chaffeqa Np ، أقدر أنك ما زلت تجد الوقت للعودة إلى هذا!
أشك بشدة في أن الأشخاص من بلوبيرد سيكونون منفتحين للحصول على اقتراحات لإعادة هندسة تنفيذها بجدية ، لقد كرروا مرارًا وتكرارًا النقطة التي مفادها أنهم في هذه المرحلة مهتمون بالاستقرار فوق كل شيء ، ويوصون الأشخاص باستخدام الوعود الأصلية ما لم يحتاج المرء حقًا إلى ميزات متقدمة مقدمة من Bluebird.
بالنظر إلى أن Node 8 يبدو أنه الإصدار الأكثر شيوعًا من Node.js في الوقت الحالي (استنادًا إلى إحصائيات تنزيل Node.js الرسمية) ، أخشى أنه لا يمكننا الانتقال إلى النهج القائم على التكرار غير المتزامن حتى الآن.
ما الجوانب السلبية التي تراها لتطبيق Knex على تطبيق DisposablePromise داخليًا؟ نظرًا لأنه يمتد إلى Promise الأصلي ، أفترض أنه لا يجلب معه أيًا من عيوب Bluebird ، ولا يحتاج أي شيء في مساحة المستخدمين إلى معرفته عنه؟

ericeslinger FWIW ، لا ينبغي أن تكون كتابة TS مشكلة رئيسية بعد الآن ، فنحن نكتب وعودنا كوعود أصلية الآن لثني المستخدمين عن الاعتماد على ميزات Bluebird. قد يتسبب هذا في حدوث مشكلات على الطريق عندما تنفذ شركة Promises الأصلية شيئًا لا تعد به Bluebird ، لذلك ما زلنا نريد استبدال الوعود المستخدمة قدر الإمكان. أي مساهمات من هذا القبيل ستكون موضع تقدير كبير :)

فكنت أحسب الكثير من المكسرات 😞
أوافق على القيام بشيء مثل DisposablePromise ربما يكون هو السبيل للذهاب في هذه الحالة ، خاصة وأن العنصر المطلوب حقًا لا يزال قيد الاقتراح .

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

إذا كان هناك أي شخص آخر في هذا الموضوع يود أن يأخذ طعنة في هذه المشكلة <3 u طويلة!

chaffeqa ما مدى تعقيد تنفيذ بلوبيرد؟ ربما يمكننا ببساطة استخراجها وإضافة الوعد المحلي؟

chaffeqa أسوأ سيناريو للحالة - يمكننا إزالة جميع استخدامات Bluebird الأخرى والاحتفاظ بهذا الاستخدام نظرًا لتعقيده إذا رأينا أنه محفوف بالمخاطر للغاية. ليس مثاليًا ، ولكن في النهاية سيحدث using .

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

تكمن المشكلة في أن خط الأنابيب يجب أن يكون وعدًا بأسلوب Bluebird ، والذي إذا فهمته بشكل صحيح ، فإنه لا يلتزم بأداء الوعد الأصلي (وبالتالي تفقد كل وظائف التتبع + غير المتزامنة الأصلية).

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

لمعلوماتك شيء آخر في ذهني هو: هناك بالفعل حد أدنى من استخدام usage و .disposer في knex ، لذلك ربما تعمل الطريقة بشكل أفضل لنقل ذلك إلى مستوى أعلى؟

يستحق التجربة :)

oooo أيضًا خيار وجدته بناءً على https://github.com/petkaantonov/bluebird/issues/1593

في كلتا الحالتين ، أعتقد أن الخطوة الجيدة للأمام كانت ما بدأته في فرع سابق ، حيث قمنا بعزل كل الاستخدامات Promise التي هي في الواقع BluebirdPromise ، وبهذه الطريقة يمكننا أن نبدأ في التلاعب بالإسقاط في بدائل مثل DisposablePromise أو BluebirdNativePromise .

chaffeqa هل تقصد الجزء Bluebird.setScheduler(fn => Promise.resolve().then(fn)) ؟
التحويل الإجمالي يسير بسلاسة حقًا! إذا تمكنا من الاحتفاظ بـ Disposers في Bluebird مع جعلهم يستخدمون الوعود الأصلية تحت الغطاء ، فقد يكون هذا حلاً جيدًا في الواقع.

حسنًا ، لا يزال هؤلاء بحاجة إلى الاهتمام:
https://github.com/tgriesser/knex/issues/3257
https://github.com/tgriesser/knex/issues/3286
https://github.com/tgriesser/knex/issues/3256

المساعدة ستكون محل تقدير كبير!

أردت فقط أن أذكر أيضًا أن عدم استخدام الوعود الأصلية ينتج عنه nodejs / node # 22360 عند استخدام async_hooks مما يتسبب في فقد السياق الحالي.

الحل البديل هو استخدام https://github.com/TimBeyer/cls-bluebird patch.

للعلم فقط ، ينتهي LTS for Node v8 هذا العام.

@ سياق بيسونوف ؟ كيف يؤثر اهتزاز min node بـ 10 على هذه المشكلة؟ لاحظ أننا أسقطنا دعم العقدة 6 بالفعل.

لست على دراية بقاعدة كود knex ، ولكن ربما هناك بعض الميزات التي يمكن أن تساعدك في التخلص من بلوبيرد. على سبيل المثال ، تدعم العقدة 10 Promise.finally .

لكن أنيوا ، يسعدني أن أرى التقدم في هذا الموضوع: +1:

حول نمط التخلص - هل يمكننا فقط إضافة رد اتصال اختياري للأشياء ، ما الذي يعود بالوعد المتاح؟
(تمامًا كما هو الحال مع المعاملات)

getDisposableConnection(config, cb) {
    const connection = await getConnection(config)

   // user want autodisposable connection
    if (cb) 
      Promise.resolve(cb(connection)).then(() => connection.dispose())
   // user will dispose by himself
   return connection
}

ما هو مستوى استقلالية المكتبات التي نحتاجها؟
1) يستخدم الجميع وعودًا محلية
2) وعود داخلية ، يمكن للمستخدم تعيين الوعد الخاص lib للواجهة
3) يمكن للمستخدم تعيين الوعد lib للداخلية والواجهة

ما هو الوضع الحالي لهذه القضية. بشكل عام ، تعمل knex الآن مع عدم التزامن في انتظار ولكن الكتابة المطبوعة ستبلغ تحذيرًا بأننا ننتظر الطريقة التي لا تعد وعدًا محليًا.

للإجابة على السؤال الأصلي. الحل الحالي هو الانتظار ببساطة وإضافة شيء مثل // tslint:disable-next-line: await-promise

maximelkin لقد صوتت للخيار 1. على المدى الطويل ، آمل أن تصبح كل مكتبة وعد بالية.

معرّف ثانيًا أننا في هذه المرحلة يتجاوزون الوعود المتعددة حتى بالنسبة لغالبية المتصفحات

يعتمدBessonov حاليًا على knex على المكتبات (وربما المشاريع) ، الأمر الذي يتطلب بالضبط بلوبيرد

يجب أن نعطي بعض الحلول الاحتياطية لهم

يعتمدBessonov حاليًا على knex على مكتبات (وربما مشاريع) ، الأمر الذي يتطلب بلوبيرد تمامًا ، يجب أن نقدم بعض الحلول الاحتياطية لهم

لا يهم إذا كان مستخدمو Knex يعتمدون على بلوبيرد. لا يزال بإمكان Knex استخدام الوعود المحلية وسوف يتعاملون بشكل جيد مع وعود بلوبيرد. يجب ألا نعطي أي احتياطات على الإطلاق.

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

لكني أفترض أن جميع مستخدمي النسخة المطبوعة البالغ عددهم 1.5 سعداء الآن.

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

في وقت سابق على الأقل مع إصدارات knex 0.x ، تم اعتبارها على أنها إصدارات رئيسية مع حدوث تغييرات محتملة ، لذا فإن التحديث إلى 0.20.x فقط كان ينبغي اعتباره ترقية آمنة (semver غير مفكك حقًا عندما يكون رقم الإصدار <1).

كانت إزالة بلوبيرد مطروحة على الطاولة منذ فترة طويلة ، ولا يتعلق الأمر بهذه المشكلة فقط.

إزالة بلوبيرد بدون سبب

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

بدون أي تحذير ، سجل التغيير ،

متفق. لقد قمت بالاطلاع على أحدث التغييرات ... للأسف ، يبدو أننا فشلنا في سرد ​​التغييرات الفاصلة بين الإصدارات. نحتاج إلى أن نكون أكثر حرصًا عند كتابة سجلات التغيير للإشارة حقًا إلى التغييرات التي تكسر واجهات برمجة التطبيقات القديمة. على سبيل المثال ، ستؤدي العديد من تغييرات الكتابة في الواقع إلى كسر رمز TS القديم.

كانت هناك نفس المشكلة في مشروع ioredis https://github.com/luin/ioredis/commit/da60b8b. لقد أرادوا دعم الوعود الأصلية - وقدم الرجال حلاً جيدًا حقًا - لقد أضافوا خيارًا لدعم أي مكتبة وعد مخصصة ويستخدمون الوعد الأصلي افتراضيًا. لما لا؟ يعد إعداد مكتبة الوعد المخصصة أمرًا سريعًا ولا يتطلب تصحيح جميع التعليمات البرمجية للتطبيق.

كان الاستمرار في استخدام Bluebird يتطلب إضافة رمز التفاف بلوبيرد إضافي في واجهة برمجة تطبيقات knex بدون سبب على الإطلاق.

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

أيضا ، رأيت رأي أن

على المدى الطويل ، آمل أن تصبح كل مكتبة وعد بالية.

لكن هناك افتراضان خاطئان في IMHO:

• يستخدم بلوبيرد لأنه أسرع.
• بلوبيرد يستخدم كمحطة بوليفيل.

أعتقد أن هذا ليس هو الحال بالنسبة للتطبيقات المعقدة حقًا ، والتي تتجاوز عدم التزامن - تنتظر بطانات واحدة.
يحتوي Bluebird على العديد من الميزات الضرورية للغاية للتدفق غير المتزامن المعقد - مثل المهلات ومعالجة الأخطاء المخصصة ورسم الخرائط بالتزامن والإلغاء والتقليل وما إلى ذلك. يمكن تنفيذ كل هذه الميزات بوعود محلية ، ولكن هذا كثير من النماذج غير المجدية. في عام 2020 ، ما زلنا نستخدم بلوبيرد في العقدة 12 لأننا لا نريد كل هذا النموذج.

لما لا؟ يعد إعداد مكتبة الوعد المخصصة أمرًا سريعًا ولا يتطلب تصحيح جميع التعليمات البرمجية للتطبيق.

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

تضمين التغريدة

إنها ليست مهمة صغيرة كما قد تبدو عند الفحص الأول.

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

jehy : لا تتردد في إرسال بيان عام لهذه الأسطر العشرة من التعليمات البرمجية إذا رأيت طريقة مباشرة لتنفيذها.

سأقضي أيضًا بعض الوقت اليوم في محاولة إيجاد حل بديل.

لما يستحق ، يتم تكرار جزء كبير من واجهة برمجة التطبيقات الخاصة بلوبيرد مع نفس واجهة برمجة التطبيقات أو إغلاقها باستخدام وعود أصلية من خلال هذه الحزم: https://github.com/sindresorhus/promise-fun

بالنسبة لما يستحق ، يتم تكرار جزء كبير من واجهة برمجة التطبيقات الخاصة بـ Bluebird مع نفس واجهة برمجة التطبيقات أو إغلاقها باستخدام وعود أصلية من خلال هذه الحزم

~ 50 عبوة بدلاً من 1؟ عنجد؟

نعم ، على الرغم من أن الأمر يتطلب في معظم الأحيان القليل فقط (خريطة p على سبيل المثال). قد تختلف الأميال الخاصة بك بالطبع. يتم تقديمها كطريق محتمل واحد فقط لما تريده.

jehy : إليك شيء يمكنك تجربته كحل مؤقت داخل رمز التطبيق الخاص بك:

const Bluebird = require('bluebird');


const prototypesNeedingDecoration = [
  require('knex/lib/query/builder').prototype,
  require('knex/lib/schema/builder').prototype,
  require('knex/lib/transaction').prototype,
  require('knex/lib/raw').prototype,
];

const corePromiseMethods = ["then", "catch", "finally"];


function decoratePromiseMethods(target) {
  for(const m of corePromiseMethods) {
    const original = target[m];

    target[m] = function(...args) {
      return Bluebird.resolve(original.apply(this, args))
    }
  }  
}

function hackBluebird() {
  for(const target of prototypesNeedingDecoration) {
    decoratePromiseMethods(target);
  }
}


hackBluebird();

هذا ليس حلاً مناسبًا للمشكلة بشكل عام. هناك كائنات مؤقتة أخرى تم إنشاؤها داخل knex والتي يجب أن يتم تزيينها بطريقة مماثلة.

أيضًا ، إخلاء المسئولية: لقد كان الحل البديل قليلًا جدًا من الاختبارات. لذلك ، يجب إعادة تشغيل اختبارات التطبيق الخاص بك للتأكد من عدم تعطل أي شيء.

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

من منظور تطبيقنا ، كانت knex هي آخر مكتبة أجبرتنا على طلب Bluebird ، والامتثال لدعم الوعد المحلي الكامل يعني أن:

1. لم يعد لدينا آثار مكدس ملطخة
2. قمنا بتخفيض وزن SSR لدينا بمقدار لائق
3. لقد قمنا بتحسين الأداء نظرًا لأن انتظار Async الأصلي أصبح الآن أكثر أداءً من بلوبيرد (ويزداد عدد مرات الظهور أكثر!)

إنه فوز كبير لمواصلة الجري نحو معيار es ... وأنا أعلم أن هذا ليس بالأمر السهل على مسؤولي المكتبة ، لذلك أردت أن أصرخ لكم يا رفاق وأشكركم على تحمل هذا العبء!

لأولئك الذين يعانون من التغيير: أرغب في تقديم المساعدة لأننا استفدنا ، لذا يرجى التواصل إذا كنت بحاجة إلى مساعدة في تصحيح الأخطاء أو الترحيل!

chaffeqa شكرًا لك على هذه التعليقات ، فهذا يعني الكثير!

jehy : هل سنحت لك الفرصة لمحاولة حل ما تم اقتراحه؟ إذا كان الأمر كذلك ، فهل تم حل مشكلاتك العاجلة؟