Async: कॉलबैक के बिना कार्यों को वादे के रूप में मानें

हमारे पास विश्वसनीय रूप से यह पता लगाने का कोई तरीका नहीं है कि कोई फ़ंक्शन एक वादा लौटाता है या नहीं, और हमें इसे कॉलबैक पास करने की आवश्यकता है या नहीं। ( Function.length या पार्सिंग Function.toString() पर्याप्त नहीं है) यह वही है जो asyncify के बारे में है - वादा-वापसी कार्यों को कॉलबैक लेने वाले कार्यों में परिवर्तित करना। चूँकि हम async फ़ंक्शंस का पता लगा सकते हैं क्योंकि उनके पास एक अलग प्रकार है, हम उन्हें स्वचालित रूप से asyncify कर सकते हैं (जो कि आंतरिक रूप से कैसे काम करता है)। लेकिन सामान्य कार्यों के लिए जो एक वादा वापस करने के लिए होते हैं, हमारे पास Async उन्हें कॉल करने से पहले बताने का कोई तरीका नहीं है।

@ अर्ली हम्म ठीक है, तो शायद शीर्ष-स्तर पर कॉलबैक का पता लगाने जैसा कुछ आसान हो?

async function parallel(o, cb) {
  if (!cb) { // promise behavior
    return Object.fromEntries(
      await Promise.all(Object.entries(o).map(async ([k, v]) => [k, await v()]))
    )
  }
  // else do the callback behavior
}

हम पहले से ही ऐसा कुछ कर रहे हैं - यदि आप कॉलबैक को async.parallel छोड़ देते हैं तो एक वादा वापस करें। यदि आप कॉलबैक को छोड़ देते हैं तो हम आपके द्वारा पास किए गए कार्यों को वापस करने के वादे नहीं मानते हैं क्योंकि हमारे पास उपयोगकर्ता के इरादे को मानने का कोई तरीका नहीं है। शायद मैं गलत समझ रहा हूँ कि आपका क्या मतलब है?

ठीक है, चलो ठोस हो: https://repl.it/@caub/async -async

// npm.im/async expects all inner functions to be async,
// even when using no outer callback (as 2nd arg of async.parallel)
console.log(
  await async.parallel({
    foo: async () => delay(1000).then(() => 1),
    bar: async (rs) => {
      return 2
    },
  })
);

// Doesn't work without those async,
// but I'd like this to resolve just like above instead of freezing
console.log(
  await async.parallel({
    foo: () => delay(1000).then(() => 1),
    bar: () => {
      return 2
    },
  })
);

मुझे लगता है, भविष्य में अगले प्रमुख संस्करण में, इस तरह से केवल कॉलबैक का समर्थन करना दिलचस्प हो सकता है:

await Promise.all([
  { then(resolve){ setTimeout(resolve, 50, 1) } }, // callback way
  2,
  delay(45).then(())=>3)
])
// [1, 2, 3]

आंतरिक कार्यों में अनावश्यक async कीवर्ड की आवश्यकता को दूर करना

लाभ अधिक स्पष्टता है। मैं उपयोगकर्ता के इरादे को न मानने के बारे में आपकी बात समझता हूं, लेकिन आप अभी भी यह मान रहे हैं कि लोग वादा समाधान का उपयोग करना चाहते समय async कीवर्ड नहीं भूलेंगे

यह पश्चगामी संगतता को बहुत बड़े तरीके से तोड़ देगा - उदाहरण के लिए आप Async.map(fileNames, fs.readFile) जैसी चीजें और नहीं कर सकते।

क्या आप समझा सकते हैं कि यह कहाँ टूटेगा?

वर्तमान में ब्रेक क्या है:

await async.map(['server.js', 'package.json'], fs.readFile) // works
await async.map(['server.js', 'package.json'], fs.promises.readFile) // works
await async.map(['server.js', 'package.json'], s => fs.promises.readFile(s)) // doesn't work
await async.map(['server.js', 'package.json'], async s => fs.promises.readFile(s)) // works

तीसरे को ठीक करने का विचार है

मुझे वे समस्याएं लगातार आती हैं, उदाहरण के लिए मैंने लिखा:

  // ...
  doc = await async.map(items, item => item.toDoc(currentUser, options));

कहीं, और फिर, टाइमआउट क्योंकि मुझे async item => item.toDoc.. याद आ रहा था

अगर मैं उस मामले में अकेला हूं, तो यह इसके लायक नहीं है, लेकिन अगर इस स्थिति में और लोग हैं, तो मुझे लगता है कि प्रस्तावित बदलाव पर विचार करना उचित है

async.map साथ यह उदाहरण भी बहुत प्रतिनिधि है, क्योंकि आप मेरी बात को कैसे . के साथ देख सकते हैं

  doc = await Promise.all(items.map(item => item.toDoc(currentUser, options)));

async item => item.toDoc.. की आवश्यकता के बिना काम करता है

तीसरे को मज़बूती से ठीक करने का कोई तरीका नहीं है, इस पर अतीत में बहुत चर्चा की गई है। हम किसी फ़ंक्शन के रिटर्न वैल्यू की जांच नहीं कर सकते हैं और फिर फ़ंक्शन पर कॉलबैक पास नहीं कर सकते हैं। async कीवर्ड जितना अच्छा हो उतना अच्छा है।

@caub बेशर्म प्लग यहाँ, लेकिन मुझे लगता है कि asyncp में आप जो खोज रहे हैं उसे संभालने की क्षमता है।

यहां तक ​​​​कि इस मुद्दे के बंद होने के बाद भी, जैसा कि ऊपर दिए गए लिंक में है, मैं यहां @caub के बयानों पर फिर से जोर देना
वर्तमान व्यवहार ने मुझे बहुत भ्रमित किया है, और जब मैं यहां चर्चा की गई तकनीकी सीमाओं को समझता हूं, तो मेरा मानना ​​​​है कि दस्तावेज़ीकरण वर्तमान व्यवहार के अनुरूप नहीं है।
उदाहरण के लिए mapLimit यह कहता है "रिटर्न: एक वादा, अगर कोई कॉलबैक पास नहीं हुआ है" - मैंने कॉलबैक संस्करण के साथ शुरुआत की, और फिर मूल रूप से कॉलबैक छोड़ दिया और आश्चर्यचकित था कि मुझे वादा नहीं मिला (क्योंकि मेरे पास नहीं था 'async' कीवर्ड)।
इसके अलावा, iteratee फ़ंक्शन में 'कॉलबैक' कथन की आवश्यकता नहीं है, इसके बजाय आपको एक मान 'वापसी' करने की आवश्यकता है।
इसलिए, या तो व्यवहार को बदला जाना चाहिए (पसंदीदा) या कम से कम प्रलेखन और उदाहरणों को भ्रम से बचने के लिए मेरे दृष्टिकोण में संरेखित किया जाना चाहिए।

@caub यही कारण है
https://github.com/caolan/async/blob/8aecf108b3922bc5211036706a0f6f75e02bd42b/lib/internal/wrapAsync.js#L3 :L5

function isAsync(fn) {
    return fn[Symbol.toStringTag] === 'AsyncFunction';
}

इस तरह, यह जांचना आसान है कि क्या फ़ंक्शन वास्तव में इसे कॉल किए बिना एक वादा लौटाता है। लेकिन फिर भी आपसे सहमत हूं कि यह एसिंक्स/प्रतीक्षा सम्मेलनों के खिलाफ है। आंतरिक await बिना async कीवर्ड जोड़ना वास्तव में अधिकांश मामलों में एक बुरा अभ्यास माना जाता है।

https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/async_function से

async फ़ंक्शन के शरीर को शून्य या अधिक प्रतीक्षा अभिव्यक्तियों से विभाजित होने के बारे में सोचा जा सकता है। शीर्ष-स्तरीय कोड, पहले प्रतीक्षित अभिव्यक्ति (यदि कोई है) सहित और समकालिक रूप से चलाया जाता है।

... और इसलिए यह बेकार और सबसे खराब होगा यदि कोड को बेबेल द्वारा ट्रांसपिल किया गया है तो यह कुछ प्रदर्शन ओवरहेड जोड़ देगा क्योंकि यह async कीवर्ड के अस्तित्व के कारण अधिक कोड और कदम जोड़ देगा

उदाहरण के लिए, निम्नलिखित:

async function foo() {
   return 1
}

...के बराबर है:

function foo() {
   return Promise.resolve(1)
}

लेकिन इस पुस्तकालय के साथ,

async.mapLimit([1], 1, async v => v)

तथा

async.mapLimit([1], 1, v => Promise.resolve(v)))

समकक्ष नहीं हैं!