किसी ऑब्जेक्ट के गुणों को एक्सेस करने के लिए डॉट नोटेशन का उपयोग करें

(STAGVED में पंजीकृत) OL

यह चुनौती केवल समाधान के रूप में निम्नलिखित को स्वीकार करती है:

console.log(dog.name);
console.log(dog.numLegs);

हालाँकि, हम स्पष्ट रूप से यह नहीं बताते हैं कि 2 अलग-अलग बयानों का उपयोग किया जाना चाहिए, और निम्नलिखित पास नहीं होते हैं:

console.log(dog.name, dog.numLegs);

मैं सोच रहा हूं कि हमें या तो यह निर्दिष्ट करना चाहिए कि 2 अलग-अलग console.log() बयान देने की आवश्यकता है, या दोनों समाधानों को स्वीकार करने के लिए परीक्षण को फिर से करें - मुझे लगता है कि मैं बाद वाला विकल्प पसंद करूंगा। विचार?

उदाहरण के साथ ऑब्जेक्ट के कंस्ट्रक्टर को सत्यापित करें :

(STAGVED में पंजीकृत) OL

• किसी कारण के लिए, लिंटर चेतावनी Expected an assignment of function call and instead saw an expression फेंकता है जब सही समाधान myHouse instanceof House; लिखा जाता है। चुनौती हालांकि से गुजरती है।
• इसके अलावा, बीज कोड में ही एक लापता अर्ध-बृहदान्त्र के लिए लोड पर एक चेतावनी है।
• अंत में इस पर, यकीन नहीं है कि यह जानबूझकर है, लेकिन यह थोड़ा भ्रमित हो सकता है - इस खंड में पिछली चुनौतियों में, इस तरह से निर्माणकर्ताओं को परिभाषित किया गया है:

function House(numBedrooms) {
  this.numBedrooms = numBedrooms;
}

लेकिन इस चुनौती में वे इस वाक्यविन्यास पर जाते हैं:

let House = function(numBedrooms) {
  this.numBedrooms = numBedrooms;
}

यह भ्रम के संभावित स्रोत के रूप में इतना मुद्दा नहीं है। यदि हम दोनों तरीकों का उपयोग करते हैं, तो मुझे लगता है कि हमें विशेष रूप से अंतर पर ध्यान देना चाहिए, अन्यथा, सिंटैक्स को पूरे खंड में सुसंगत रखें। शायद दोनों का परिचय एक अच्छा विचार है, हालांकि मुझे लगता है।

स्वयं के गुणों को समझना :

बस इस एक पर एक अवलोकन, और उत्सुक जो दूसरे राय हैं देखने के लिए - लेकिन इस चुनौती अधिक चारों ओर एक सा घूमता रहा है for...in बजाय hasOwnProperty , और for...in नहीं है इस खंड में अभी तक पर्याप्त रूप से समझाया गया है।

यदि हम मान रहे हैं कि लोगों ने बाकी पाठ्यक्रम के माध्यम से काम किया है, तो मुझे लगता है कि यह ठीक है, क्योंकि यह कम से कम बेसिक डेटा स्ट्रक्चर्स सेक्शन में शामिल है, लेकिन अगर हम वर्गों को एक-दूसरे से स्वतंत्र होने का इरादा रखते हैं और आवश्यकता नहीं है हम इसे फिर से देखना चाहते हैं?

कंस्ट्रक्टर संपत्ति को समझें :

(STAGVED में पंजीकृत) OL

यह चुनौती या तो समाधान से गुजरेगी:

function joinDogFraternity(candidate) {
  if (candidate instanceof Dog) {
    return true;
  }
  return false;
}

// OR:

function joinDogFraternity(candidate) {
  if (candidate.constructor === Dog) {
    return true;
  }
  return false;
}

मैं इसे एक बड़ी समस्या के रूप में नहीं देखता क्योंकि वृत्ति यह बताती है कि लोग पहले उनके द्वारा सुझाए गए समाधान को आजमाएंगे, हालाँकि, मैं यह भी देख सकता हूँ कि एक समस्या को रेखा के नीचे खोला जा रहा है जब प्रेमी टूरिस्ट दोनों तरह से कोशिश करता है और चाहता है इसे इंगित करें।

हम सिर्फ एक परीक्षण मामला जोड़ सकते हैं जो "message: 'your solution should use the constructor property'" कहता है और एक regex के साथ सत्यापित करता है।

इनहेरिटेंस का उपयोग करें ताकि आप खुद को न दोहराएं :

मुझे लगता है कि यह चुनौती थोड़ी गड़बड़ है। शीर्षक इनहेरिटेंस को संदर्भित करता है, हालांकि, चुनौती में वंशानुक्रम का कभी उल्लेख नहीं किया गया है - मुझे यह पता चलता है कि यह अगली चुनौती से जुड़ा हुआ है, इसलिए कैंपर जल्दी से पता लगा लेंगे, लेकिन जिस तरह से इसका प्रस्तुतिकरण अभी भी थोड़ा दूर है। इसके अलावा, चुनौती के अंत में, हमने Animal कमाया है, लेकिन हम थोड़े भ्रमित हैं, क्योंकि इस बिंदु पर Animal , Cat से टाई नहीं करते हैं Dog । भ्रम को थोड़ा कम करने के लिए, मुझे लगता है कि हम थोड़ा बदलाव कर सकते हैं:

यह वाक्यांश अगली चुनौती से आता है:

यह और अगली चुनौती को फिर से परिभाषित किए बिना बर्ड और डॉग के अंदर पशु के तरीकों का पुन: उपयोग करने के लिए कैसे कवर किया जाएगा। यह वंशानुक्रम नामक एक तकनीक का उपयोग करता है।

शायद, चीजों को टाई करने के लिए, इसी तरह का एक उच्च स्तरीय अवलोकन, इस चुनौती में दिया जा सकता है जो सभी 3 को एक साथ जोड़ता है इसलिए यह समझा जाता है कि वे एक अनुक्रम हैं, और वास्तव में इस अवधारणा का परिचय देते हैं कि चुनौती का शीर्षक है, और इसे बनाता है स्पष्ट है कि इस चुनौती के अंत में हम अभी तक नहीं किए गए हैं।

इनहेरिट बिहेवियर फ्रॉम अ सुपरपाइप :

(STAGVED में पंजीकृत) OL

सुपर मामूली मुद्दा यहाँ - इस के लिए बीज का हिस्सा इस प्रकार है:

// Add your code below this line

let duck
let beagle

duck.eat(); // Should print "nom nom nom"
beagle.eat(); // Should print "nom nom nom"

यह एक लाइनर त्रुटि फेंकता है। मैं इसके बजाय निम्नलिखित का प्रस्ताव करूंगा:

सुपर मामूली मुद्दा यहाँ - इस के लिए बीज का हिस्सा इस प्रकार है:

let duck; // change this line
let beagle; // change this line

duck.eat(); // Should print "nom nom nom"
beagle.eat(); // Should print "nom nom nom"

@ नो-स्टैक-डब-बोरी - ये सभी महान बिंदु हैं, और मैंने इस खंड के लिए कोई समस्या नहीं देखी है, हालांकि मैं कल का एक हिस्सा ऑफ़लाइन था। इस खंड के माध्यम से इस तरह के विस्तार के लिए धन्यवाद going यहाँ मेरे विचार हैं (tl; dr - मैं आपके द्वारा लाई गई हर बात से सहमत हूँ):

• Use Dot Notation to Access the Properties of an Object : यदि कोई एक console.log कथन का उपयोग करता है तो परीक्षण पास होना चाहिए।
• Verify an Object's Constructor with instanceof : हमें लापता अर्ध-बृहदान्त्र को ठीक करना चाहिए और जिस तरह से House परिभाषित किया गया है उसके अनुरूप होना चाहिए। जबकि JS में चीजों को करने के कई तरीके हैं, पहली बार सीखने वाले लोगों को भ्रमित करने की कोई आवश्यकता नहीं है।
• Understanding Own Properties : for...in बारे में आपकी बात पर - हमने आमतौर पर यह विचार किया कि पाठ्यक्रम में पहले से ही शामिल अवधारणाओं का उपयोग करना ठीक है। कैंपर्स अपनी इच्छानुसार घूम सकते हैं, लेकिन विषयों के लिए एक प्रवाह है। (अन्यथा, चुनौतियां लंबी / दोहराव प्राप्त कर सकती हैं यदि उन्हें बिंदु पर पहुंचने से पहले चीजों को फिर से कवर करना है)। उस ने कहा, मुझे लगता है कि उदाहरण के तहत नोट को सही तरीके से रखना मददगार हो सकता है जो संक्षेप में वाक्य रचना (" for...in करता है ...) को याद करता है।"
• Understand the Constructor Property : निर्देशों में कंस्ट्रक्टर का उपयोग करने के लिए अपनी बात पर सहमत हों
• Use Inheritance So You Don't Repeat Yourself : हाँ, एक साथ बेहतर चुनौतियों को टाई करने के लिए अच्छे अंक
• Inherit Behaviors from a Supertype : हमें निश्चित रूप से अर्ध-कॉलोन को जोड़ना चाहिए, और टिप्पणियां भी सहायक हैं

मुझे बताएं कि क्या आप इन पर काम करना चाहते हैं - मैं दूसरे खंड में कूद रहा हूं (एक या दो दिन में इस पर काम कर सकता है), या हम इसे खोल सकते हैं जैसे कि मदद चाहते थे want

@ हज़ कूल, धन्यवाद! मैं अनुभाग को समाप्त करने जा रहा हूं, अगर मेरे पास कोई और टिप्पणी है, और फिर हम उस बिंदु पर निर्णय ले सकते हैं, लेकिन मैं सोच रहा हूं कि इसे मदद करने के लिए खोलना सबसे अच्छा होगा। आपको सूचित किया जाता रहेगा।

वंशानुक्रम के बाद तरीके जोड़ें :

निम्नलिखित परीक्षण मामले के कारण यह चुनौती थोड़ी भ्रामक है:

Dog should have the bark() method as an own property.

इस भाग के समाधान की तलाश है:

Dog.prototype.bark = function() {
    console.log('Woof!');
};

और जब Dog.prototype.hasOwnProperty('bark') true (इसलिए यह निश्चित रूप से सही है), भ्रम का स्रोत यहाँ से आता है (जो कि Iterate Over All Properties से है ):

जानकारी देने वालों के साथ इस बिंदु तक पहुंचने के बाद, वे संभवतः यह मान लेंगे कि उस परीक्षा को पास करने के लिए, उन्हें bark पद्धति को परिभाषित करना होगा, सीधे Dog के ऑब्जेक्ट उदाहरण पर बजाय प्रोटोटाइप पर।

अंतर यह है कि Dog , bark _not_ के उदाहरणों के लिए own संपत्ति होगी, लेकिन यह _is_ एक own Dog.prototype संपत्ति है।

कहने के लिए परीक्षण मामले को बदलने के लिए सबसे सरल समाधान होगा:

Dog.prototype should have the bark() method as an own property.

हालाँकि, शायद एक त्वरित स्पष्टीकरण यह बताने के लिए है कि कैंपरों को एक prototype एक प्रोटोटाइप की संपत्ति वास्तव में एक own उस प्रोटोटाइप की संपत्ति है? वाह, यह एक जीभ भांजनेवाला है, तो हाँ, यह थोड़ा भ्रमित है, और मुझे यकीन नहीं है कि भ्रम को दूर करने का सबसे अच्छा तरीका क्या है ...

बाहरी रूप से संशोधित होने से एक वस्तु के भीतर गुणों की रक्षा के लिए बंद का उपयोग करें :

(STAGVED में पंजीकृत) OL

छोटे टाइपो:

मुझे लगता है कि "... bird की परिभाषा के बाहर होना चाहिए।" ?

तुरंत लागू फंक्शन एक्सप्रेशन (IIFE) को समझें :

इस चुनौती के साथ कोई बड़ी समस्या नहीं है - सिर्फ एक सुझाव - जब मुझे गुमनाम IIFE का अधिक सामान्य पैटर्न (और पैटर्न जो अगली चुनौती में उपयोग किया जाता है) हैं, शायद यहाँ उस IIFE का उल्लेख करने के लिए एक अच्छी जगह है IIFE होने पर त्रुटियों को ट्रैक करना मुश्किल होगा।

विचार?

मॉड्यूल बनाने के लिए IIFE का उपयोग करें :

मैं इस पर कुछ विचार प्राप्त करना चाहूंगा ... शायद @ डायकोड्स या @Greenheart?
मेरा मुद्दा यह है कि मुझे नहीं लगता कि चुनौती यह समझाने का पर्याप्त काम करती है कि क्यों इस परिदृश्य में IIFE अर्थ है।

समाधान के लिए कहता है:

let funModule = (function() {
  return {
    isCuteMixin: function(obj) {
      obj.isCute = function() {
        return true;
      };
    },  
    singMixin: function(obj) {
      obj.sing = function() {
        console.log("Singing to an awesome tune");
      };
    }
  };
})();

तो आप कुछ ऐसा कर सकते हैं:

function Bird () { }
let duck = new Bird();
funModule.singMixin(duck);
duck.sing();

हालाँकि, आप एक ही चीज़ को कम क्रियात्मक तरीके से प्राप्त कर सकते हैं, और बिना किसी फ़ंक्शन को लागू किए, बस ऑब्जेक्ट को IIFE रिटर्न में परिभाषित करके।

चुनौती यह कहती है:

मॉड्यूल पैटर्न का लाभ यह है कि गति के सभी व्यवहारों को एक एकल ऑब्जेक्ट में पैक किया जा सकता है जिसे तब आपके कोड के अन्य भागों द्वारा उपयोग किया जा सकता है।

लेकिन चूंकि इसमें एक IIFE की आवश्यकता नहीं है, इसलिए मुझे लगता है कि मैं यहां अवधारणा को पेश करने के विचार पर सवाल उठाऊंगा, या इसे टाई करने का एक मजबूत तरीका खोजूंगा। यह भ्रमित / भ्रामक हो सकता है क्योंकि कैंपर्स सोच सकते हैं कि उन्हें ऐसा करने की आवश्यकता है। इस पैटर्न को प्राप्त करें जब ऐसा न हो।

कोई विचार?

@ नहीं-स्टैक-डब-बोरी मैं मानता हूं कि यह एक IIFE का सबसे अच्छा उदाहरण नहीं है। यदि हम एक उदाहरण के रूप में module प्रदान करें तो बेहतर होगा?

मुझे लगता है कि IIFE का मुख्य मूल्य यह है कि आप अपनी वस्तुओं के निजी गुण और तरीके बना सकते हैं। यह उन तरीकों को कम करने के लिए वास्तव में उपयोगी है जो अन्य (गलत) आपके सॉफ़्टवेयर का उपयोग इस उम्मीद में कर सकते हैं कि यह चीजों को अधिक विश्वसनीय बनाता है।

उदाहरण के लिए, आपके पास अपने वेनिला js एप्लिकेशन के लिए एक छोटा उपयोगिता मॉड्यूल हो सकता है, जहां आप केवल कुछ सार्वजनिक तरीकों को उजागर करना चाहते हैं क्योंकि बाकी को बदलने / निकालने के बारे में हैं और परेशानी का कारण बनेंगे यदि उन्हें कोडबेस के अन्य भागों में उपयोग किया जाता है।

इस साइट के बहुत अच्छे उदाहरण हैं: https://toddmotto.com/mastering-the-module-pattern/

@Greenheart खैर यहाँ 2 IIFE चुनौतियों में से एक है, इसे एक मॉड्यूल पैटर्न के रूप में पेश किया गया है, और मुझे इसके साथ कोई समस्या नहीं है, मुझे लगता है कि यह अधिक स्पष्ट रूप से समझाया जा सकता है _why_ एक IIFE का उपयोग करें, और वह एक IIFE जरूरी नहीं कि उसी कार्यक्षमता को प्राप्त करने के लिए उपस्थित होना चाहिए। मुझे लगता है कि यह यह सब कहता है:

IIFE का मुख्य मूल्य यह है कि आप अपनी वस्तुओं के निजी गुण और तरीके बना सकते हैं। यह उन तरीकों को कम करने के लिए वास्तव में उपयोगी है जो अन्य (गलत) आपके सॉफ़्टवेयर का उपयोग इस उम्मीद में कर सकते हैं कि यह चीजों को अधिक विश्वसनीय बनाता है।

अगर हम इसे समझा सकते हैं, और उपयोगकर्ता को बता सकते हैं "आप एक IIFE के बिना एक ही कार्यक्षमता प्राप्त कर सकते हैं, लेकिन एक IIFE के साथ एक बेहतर तरीका है, और यहाँ क्यों ..."।

वर्तमान निर्देश कहते हैं:

एक तुरंत लागू फ़ंक्शन अभिव्यक्ति (IIFE) को अक्सर किसी एकल ऑब्जेक्ट या मॉड्यूल में समूह से संबंधित कार्यक्षमता के लिए उपयोग किया जाता है।

इसके लिए बस इसे जोड़ते हैं: "जबकि एक ही कार्यक्षमता IIFE के बिना प्राप्त की जा सकती है, IIFE का मूल मूल्य, इस संदर्भ में, यह है कि आप अपनी वस्तुओं के निजी गुण और तरीके बना सकते हैं। यह घटने के लिए बहुत उपयोगी हो सकता है। अन्य तरीके (गलत) आपके सॉफ़्टवेयर का उपयोग कर सकते हैं और चीजों को बहुत अधिक विश्वसनीय बना सकते हैं। "

@ नहीं-स्टैक-डब-बोरी दिस! :दर्शाना:

मैंने इसे संकलित करने और कुछ मामूली बदलाव करने की स्वतंत्रता ली। कुछ ऐसा ही है जिसकी हमें आवश्यकता है: ब्लश:
An <dfn>immediately invoked function expression</dfn> (IIFE) is often used to group related functionality into a single object or module. While the same functionality can be achieved without an IIFE, its core value in this context is that you can create private properties and methods for your objects. This can be very useful for decreasing the ways others can (mis)use your software, and make things much more reliable.

यदि पिछली चुनौतियों में इस शब्द का उपयोग नहीं किया गया है, तो संभवतः <dfn> उपयोग करें।

मैं आगे बढ़ूँगा और किसी ऑब्जेक्ट के गुणों को एक्सेस करने के लिए

Https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -275974706 पर जारी रखें।

पहली समस्या यह है कि लिंटर नहीं चाहता है कि हम एक अभिव्यक्ति लिखें जो अनिवार्य रूप से मृत कोड है (क्योंकि हम न तो किसी फ़ंक्शन को कॉल करते हैं और एक चर बनाते हैं)। इसे ठीक करने के लिए, मेरा सुझाव है कि हम परिणाम को एक चर पर नियत करें।

आपके द्वारा प्रस्तावित कोड का उपयोग करने के लिए बीज को बदलकर दूसरी और तीसरी समस्या को ठीक किया जा सकता है। फ़ंक्शन ऑब्जेक्ट्स को वेरिएबल्स पर असाइन करना या तो कहीं और, या अनुभव द्वारा सिखाया जा सकता है। मुझे लगता है कि हमें function X () {} अनुरूप होना चाहिए

मैं इसे ठीक करूँगा: मुस्कान:

फिक्सिंग https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276268534: मुस्कान:

फिक्सिंग https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276565338

मैं ठीक करूँगा https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -276245864

मैंने देखा कि किसी भी चुनौती के समाधान नहीं हैं, इसलिए मैं वर्तमान में एक पीआर पर काम कर रहा हूं।

स्वयं के गुणों को समझना :

(STAGVED में पंजीकृत) OL

परीक्षण वर्तमान में विधि में बनाया के उपयोग की अनुमति देता है Object.keys() , लेकिन मुझे लगता कैम्पर का उपयोग करके बेहतर अभ्यास मिल for...in के साथ संयुक्त Object.hasOwnProperty() ।

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग: Iterate ओवर ऑल प्रॉपर्टीज :

(STAGVED में पंजीकृत) OL

बस पता चला कि इस चुनौती में एक ही समस्या है - यह Object.keys() का उपयोग करने की अनुमति देता है जैसा कि मुझे अभी भी नहीं लगता है कि इन चुनौतियों में इसकी अनुमति दी जानी चाहिए, मैं इस लाइन से परीक्षण मामले को जोड़ते हुए एक पीआर बनाऊंगा

function Dog(name) {
  this.name = name;
}

Dog.prototype.numLegs = 4;

let beagle = new Dog("Snoopy");

let ownProps = Object.keys(beagle);
let prototypeProps = Object.keys(Dog.prototype);

इसे ठीक करना: मुस्कान:

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग: प्रोटोटाइप को नई ऑब्जेक्ट में बदलें

अपर्याप्त निर्देश और परीक्षण। क्या describe और eat केवल prototype मौजूद होना चाहिए, या क्या उन्हें कार्य करना चाहिए?

मुझे लगता है कि हमें यह सत्यापित करने के लिए परीक्षण जोड़ना चाहिए कि वे कार्य हैं।

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग: प्रोटोटाइप को बदलते समय कंस्ट्रक्टर प्रॉपर्टी को सेट करना याद रखें

PR सबमिट किया गया: white_check_mark:

यह चुनौती संभवत: पठनीयता और स्थिरता को बढ़ाने के लिए <code>constructor</code> property रूप में "कंस्ट्रक्टर संपत्ति" को प्रारूपित करना चाहिए। तुम क्या सोचते हो?

उदाहरण के लिए, परीक्षण संदेश इस प्रारूप का उपयोग करता है।

एक सामान्य सुझाव यह है कि हम सर्वोत्तम प्रथाओं को दिखाने के लिए let कथनों को const साथ प्रतिस्थापित करते हैं। @Mpj का यह वीडियो इसे अच्छे से समझाता है!

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग: इनहेरिटड कंस्ट्रक्टर प्रॉपर्टी को रीसेट करें :

पीआर प्रस्तुत: white_check_mark:

मामूली टाइपो: supertype's संभवतः supertype होना चाहिए

ऑब्जेक्ट ओरिएंटेड प्रोग्रामिंग: एक मॉड्यूल बनाने के लिए एक IIFE का उपयोग करें :

PR सबमिट किया गया: white_check_mark:

माइनर टाइपो: "यहां इसका उपयोग करने वाला एक उदाहरण है:" इसे "यहां

मैं https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340 पर पीआर के लिए काम कर रहा हूं

एक अन्य सामान्य सुझाव: मुझे लगता है कि हमें उदाहरणों को बदलने की जरूरत है ताकि कैंपर्स केवल उदाहरण की नकल न कर सकें और चुनौती को पूरा करने के लिए 1-2 चीजों को बदल सकें।

उदाहरणों को अवधारणा को दिखाना चाहिए, लेकिन उन गुणों या विधियों का उपयोग नहीं करना चाहिए जो चुनौती से उपयोग किए जाते हैं। इस तरीके से, मुझे लगता है कि लोग प्रत्येक चुनौती से अधिक सीखेंगे।

बूटस्ट्रैप के लिए कस्टम कस्टम सीएसएस

शनिवार, 4 फरवरी, 2017 को रात 9:11 बजे, सैमुअल प्लम्प्पु सूचनाएं @github.com
लिखा था:

एक और सामान्य सुझाव: मुझे लगता है कि हमें उदाहरण बदलने की जरूरत है
campers सिर्फ उदाहरण की नकल नहीं कर सकते हैं और 1-2 चीजों को पूरा करने के लिए बदल सकते हैं
चुनौती।

उदाहरणों को अवधारणा को दिखाना चाहिए, लेकिन गुणों या विधियों का उपयोग नहीं करना चाहिए
यह चुनौती द्वारा उपयोग किया जाता है। इस तरीके से, मुझे लगता है कि लोग सीखेंगे
प्रत्येक चुनौती से अधिक।

-
आप इसे प्राप्त कर रहे हैं क्योंकि आपको इस धागे की सदस्यता दी गई है।
इस ईमेल का उत्तर सीधे दें, इसे GitHub पर देखें
https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment-277463832 ,
या धागा म्यूट करें
https://github.com/notifications/unsubscribe-auth/AX9USApjW3rwocbHWe2yoFLV0RegbkCCks5rZL9SgaJpZM4LxApU
।

@iansibindi ऐसा लगता है कि आप इस रिपॉजिटरी के सभी संदेशों की सदस्यता ले चुके हैं। इसे अक्षम करने के लिए, https://github.com/freecodecamp/freecodecamp पर "Unwatch" पर क्लिक करें।

असुविधा के लिए खेद है!

@Greenheart मुझे लिंक के साथ भी इनमें से प्रत्येक का पालन करना थोड़ा मुश्किल लग रहा है - मुझे लगता है कि मुझे शायद हर एक के लिए एक अतिरिक्त मुद्दा खोलना चाहिए था! मेरा अभिप्राय मूल टिप्पणियों में एक चेकलिस्ट को जोड़ना था।

मैं PRs की प्रारंभिक समीक्षा करना शुरू कर दूंगा, लेकिन क्या आपको लगता है कि आप प्रत्येक मूल टिप्पणी में एक टिप्पणी जोड़ सकते हैं यदि उनके लिए एक पीआर खुला है तो हम ट्रैक कर सकते हैं कि किन मुद्दों को संबोधित किया गया है?

@ नहीं-स्टैक-डब-बोरा हाहा मुझे स्वीकार करना है कि मैं इसे खुद भी पालन नहीं कर सकता, मैं बस पोस्ट करता रहा! :मुस्कुराओ:

मैं प्रत्येक टिप्पणी की शुरुआत में एक बड़ा "PR ओपन" (इसके लिंक के साथ) जोड़ूंगा जो WIP / फिक्स्ड है।

@Greenheart बिल्कुल सही! धन्यवाद! मैंने पहले कई PR की समीक्षा की है

मैं https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277457211 ठीक करूंगा

मैं https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277459744 ठीक करूंगा

मैं https://github.com/freeCodeCamp/freeCodeCamp/issues/12966#issuecomment -277447340 ठीक करूंगा

@ नहीं-स्टैक-डब-बोरी ठीक है, अभी भी कुछ चीजें यहाँ करने के लिए लेकिन मैंने आज उनमें से कुछ को हल किया!

उफ़, इसे फिर से बंद कर दिया: हँस:

@ग्रीनहार्ट वाह! एक फेंक - इस में कुछ करना बाकी है? कुछ बड़े सुधार किए गए थे!

@ नहीं-स्टैक-डब-बोरी मुझे नहीं पता - ऊपर की टिप्पणियों के अनुसार कुछ चीजें बाकी हैं, लेकिन वे अन्य स्थानों पर हल हो गई हैं?

मुझे लगता है कि इसका अभी तक निर्धारण नहीं हुआ है। अगर आपको लगता है तो मुझे बताएं

महान हर कोई काम करता है। मैं इस मुद्दे को बंद कर रहा हूं और हम अधिक विशिष्ट मुद्दों को फिर से खोल सकते हैं क्योंकि वे फसल लेते हैं।