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

سؤال جيد حول الأصول. أعتقد أن معظم مصادر البيانات تمثل الأصول بالنسبة إلى الأصول كسلسلة مع عنوان URL أو مسار إلى الأصل. تمثل لقطة المخطط فقط النوع كسلسلة مع عنوان URL / المسار أو كائن أصل له خاصية سلسلة مع عنوان URL / المسار.

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

jquense هذا ما أفكر فيه. يمكنك إما تشغيل أمر "لقطة" للمخطط الذي تم إنشاؤه ديناميكيًا والذي من شأنه كتابة ملف بالمخطط في شكل رسم بياني عادي أو يمكنك كتابة نفس النموذج مباشرة بنفسك.

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

أنا أبحث حاليًا في الأجزاء الداخلية لمخطط غاتسبي الذي يستنتج المنطق في ..
https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/schema
والتعرف على كيفية تعريف مخططات GraphQL. سأحاول إنشاء دليل على مفهوم العلاقات العامة قريبًا.

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

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

أود أن أذكر أن تحديد المخطط يدويًا ممكن بالفعل ومدعومًا عبر gatsby api ، وإن كان ذلك باستخدام Graphql-js وليس لغة مخطط المربعات.

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

هل يمكنك أيضًا توضيح المزيد حول "كيف أعتقد أن الوقت سيكون أفضل
تم إنفاقه على السماح لمؤلفي البرنامج المساعد بتوفير ملف .graphql ... "؟

الخميس، 28 ديسمبر 2017 في 08:27 جيسون Quense [email protected]
كتب:

أنا أتفهم تمامًا تسهيل وصول المستخدمين إلى شيء جديد ، كما أعتقد
الإضافات مختلفة بعض الشيء. من المتوقع عمومًا أن يفهم المؤلفون
gql بالفعل ولا يجب على المستخدمين عمومًا العبث بأي شيء آخر
من الاستعلام عند استخدام البرنامج المساعد المصدر.

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

أود أن أذكر أن تحديد المخطط يدويًا هو بالفعل
ممكن ومدعوم عبر gatsby api ، وإن كان ذلك باستخدام Graphql-js وليس ملف
لغة مخطط terser.

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-354288169 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAuc_6X_eEWEf281KUspXxB1NuPZPeC4ks5tE5clgaJpZM4RNLJn
.

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

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

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

تعجبني فكرة المكونين الإضافيين. أعتقد أن APIjquense يتحدث عنه
هو https://www.gatsbyjs.org/docs/node-apis/#setFieldsOnGraphQLNodeType. لكن
أعتقد أنه يسمح فقط بإضافة حقول إلى مخطط صحيح؟ وليس الكتابة
ما تم استنتاجه.

في الخميس ، 28 ديسمبر 2017 الساعة 10:06 صباحًا ، كتب M4rrc0 [email protected] :

ماذا عن مكونين إضافيين مختلفين؟ واحد يتيح لنا تحديد
مخطط في ملف وآخر لإنشاء هذا الملف من ملف
مصدر.
لذلك قد يكون المصدر مختلفًا ... على سبيل المثال مساحة محتوى حيث
قد يكون كل حقل مكتمل هو المصدر لإنشاء المخطط. ثم
يمكن استخدام المخطط في أي مساحة ذات محتوى لها نفس المساحة
هندسة معمارية. وبالطبع ربما لا نزال نعدّل المخطط يدويًا إذا
بحاجة.
على أي حال ، يبدو أن البرنامج المساعد no1 هو الخطوة الأولى. ربما لا نزال
تقرر متى يتم ذلك وماذا تفعل بعد ذلك.
jquense https://github.com/jquense هل يوجد في مكان ما مثال على ملف
المخطط المحدد يدويا؟ لم أكن أعلم أنه كان ممكنًا.

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-354302287 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAuc_4fqrocUXxBPkFsK2tFn2VVDduv3ks5tE66AgaJpZM4RNLJn
.

نعم ، أعتقد أنك على حق ، فليس كل شيء يتم استبداله: /

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

حسنًا ، سأفعل بعض الاستكشاف حول المكون الإضافي الأول للتعريف
المخططات كملفات graphql. أنا مهتم بسماع مدخلات كايل أيضًا :)
شكرا للجميع على المناقشة الرائعة!

يوم الخميس ، 28 كانون الأول (ديسمبر) 2017 ، الساعة 10:31 صباحًا ، جيسون كوينس ، إخطارات github.com
كتب:

نعم ، أعتقد أنك على حق ، فليس كل شيء يتم استبداله: /

أنا أؤيد بشكل عام المكونات الإضافية لحل المشكلات ولكن أعتقد أن هذا النوع من
الشيء الذي قد يحتاج إلى التعامل معه في واجهة برمجة التطبيقات الأساسية لتحقيق قابلية الاستخدام الصحيحة
ملاحظات (يمكن أن أكون مخطئا تماما مع ذلك). في رأسي سيكون api المثالي
فقط لتوجيه gatsby إلى ملف .graphql ويقوم بالباقي ، ولكن هذا ممكن
ليس لطيفا كما أتخيل. أعتقد أن الأمر يستحق الاستكشاف فيه
الإضافات إذا كان ذلك ممكنًا قبل الانتقال إلى النواة ... بالطبع
ارجع لما يعتقده كايل منذ أن أصبح الرئيس :)

-
أنت تتلقى هذا لأنك قمت بتأليف الموضوع.
قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-354306088 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAuc_6wNLHfte9zCZ2OqgirIMRadX609ks5tE7RTgaJpZM4RNLJn
.

@ jsanchez034 هل بحثت فيه أكثر؟ سأحاول بشكل مناسب العمل في هذا الأسبوع المقبل وأنا مهتم إذا أجريت بعض الأبحاث ويمكنني مشاركة نتائجك

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

يوم الجمعة 5 كانون الثاني (يناير) 2018 الساعة 7:16 مساءً Michal Piechowiak [email protected]
كتب:

@ jsanchez034 https://github.com/jsanchez034 هل بحثت عنها أكثر؟
سأحاول بشكل مناسب العمل في هذا الأسبوع المقبل وأنا مهتم إذا فعلت ذلك
بعض الأبحاث ويمكن أن تشارك النتائج الخاصة بك

-
أنت تتلقى هذا لأنه تم ذكرك.

قم بالرد على هذا البريد الإلكتروني مباشرة ، وقم بعرضه على GitHub
https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment-355699899 ،
أو كتم الخيط
https://github.com/notifications/unsubscribe-auth/AAuc_3w7px_NJjL2EKl8G5TP1GJgQFVWks5tHrtNgaJpZM4RNLJn
.

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

البرنامج المساعد كاتب المخطط

ماذا يجب أن يفعل البرنامج المساعد؟

• خذ مخططًا ومحلل ويجب أن يتم خياطة المخطط الناتج في مخطط Gatsby الرئيسي
  
  
  
  • يبحث في src/schema عن المجلدات ، يحتوي كل مجلد على مخطط وملف محلل
  
  
  • سيأخذ البرنامج المساعد جميع الملفات ويشغلها من خلال makeExecutableSchema من حزمة graphql-tool npm
  
  
  • أنشئ وظيفة واجهة برمجة تطبيقات Gatsby Node جديدة تسمى شيئًا مثل mergeSchema يتم استدعاؤه قبل هذا السطر في ملف إنشاء المخطط الذي يستخدم graphql-tool خياطة المخطط | src/schema
  
  
• يجب تعيين بعض البيانات النموذجية الوهمية للمخطط الجديد باستخدام createNode
  
  
  
  • استخدم sourceNodes في ملف gatsby-node.js للمكوِّن الإضافي
  
  

هذه هي ملاحظاتي التقريبية على البرنامج المساعد لكاتب المخطط. المكوّن الإضافي الآخر الذي ذكره MarcCoet هو الذي يمكنك من خلاله توجيه المكوّن الإضافي إلى نقاط النهاية في مجال حيث يتم إعداد البيانات لتكون في حالة كاملة ، ثم يتم إنشاء المخططات وحفظها في src/schema .

ملاحظة: سيتم تعريف المخططات باستخدام لغة نوع GraphQL

لسوء الحظ ، لا أعتقد أن graphql-tools سيعمل هنا لأنه كان من المفترض دمج المخططات الكاملة (أي التعريفات والبيانات / أدوات التحليل) وإضافة روابط بين هذه المخططات.

من وثائق الدالة mergeSchemas (https://www.apollographql.com/docs/graphql-tools/schema-stitching.html#mergeSchemas) حول المخططات التي تم تمريرها للدمج:

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

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

Field "frontmatter.title" already exists in the schema. It cannot also be defined in this type extension

بالنسبة للخيار الثاني (باستخدام GraphQLSchema ) لقد "اخترقته" للعمل عن طريق إضافة استعلام وهمي ، لكن المشكلة الأولية هي أنه لا يمكنني استخدام أنواع من المخطط "الرئيسي" - لا يمكننا ببساطة القيام بذلك:

type frontmatter {
  featuredImage: File
  title: String
}

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

سأحاول تقييم طريقتين أخريين:

• البحث عن أو إنشاء أداة مصممة لتعديل مخطط موجود بالفعل (قد تكون أداة رسم بياني عامة أكثر)
• أو فرض أنواع محددة من قبل المستخدم / البرنامج المساعد في الحقول عند إنشاء مخطط (من شأنه تحديد gatsby)

لقد أحرزت بعض التقدم. قررت اتباع نهج محدد لـ gatsby في الوقت الحالي (إضافة دعم لـ "الأنواع القسرية" في https://github.com/gatsbyjs/gatsby/tree/master/packages/gatsby/src/schema) حيث وجدت أنه من الأسهل التعامل معها من اللعب مع كائنات مخطط الرسم البياني. سأحاول تنظيف الكود الخاص بي قليلاً حتى يكون أكثر قابلية للقراءة وإنشاء طلب سحب هذا الأسبوع لمناقشته أكثر هناك.

مجرد ذروة التسلل للنتائج (imo واعدة جدًا):
لقد استخدمت https://github.com/gatsbyjs/gatsby-starter-blog واستخدمت frontmatter في المنشورات لمحاكاة بعض المشكلات التي يمكن أن تسبب أخطاء في الإنشاء ناتجة عن الاستعلامات التي لا تتطابق مع المخطط:

// post #1
---
title: Hello World
date: "2015-05-01T22:12:03.284Z"
featuredImage: "sasalty_egg.jpg" // badly formatted value that wouldn't allow to make this File type 
test: "some string" // incompatible value type with other posts (in other posts test field is object) - it would be skipped in schema
---

// post #2
---
title: My Second Post!
date: "2015-05-06T23:46:37.121Z"
test:
  floatField: 5.5
  intField: 99
  arrayOfStringsField:
    - "it"
    - "works"
---

// post #3
---
title: New Beginnings
date: "2015-05-28T22:40:32.169Z"
test:
  stringField: "string"
  boolField: true
---

تعريفات الأنواع المستخدمة:

type MarkdownRemark {
  frontmatter: frontmatter_forced_type
}

type frontmatter_forced_type {
  featuredImage: File
  title: ImageSharp
  test: TotallyCustomType
}

type TotallyCustomType {
  stringField: String
  floatField: Float
  intField: Int
  boolField: Boolean
  arrayOfStringsField: [String]
}

_ملاحظة: _ لا يجب أن تكون تلك تعريفات كاملة للنوع (fe في تعريف MarkdownRemark أنا فقط أجبر نوع حقل المادة الأمامية على عدم الاعتماد على تسمية النوع تلقائيًا)

إليك كيف تبدو المادة الأولى قبل استخدام التغييرات (لا يوجد حقل test ، نوع "سيئ" من featuredImage حقل):

و بعد:

مرحباpieh! شكرًا لك على هذا ، يبدو الحل الذي تقدمه واعدًا جدًا! آسف لم أستطع المساهمة أكثر في هذه المشكلة في الأسبوعين الماضيين ، لم يكن لدي الوقت للتعمق في هذا الأمر. يُرجى إعلامي إذا كان هناك أي شيء يمكنني المساعدة فيه.

إذا كان أي شخص مهتمًا ، فيمكنك عرض تغييرات الكود الخاص بي https://github.com/gatsbyjs/gatsby/compare/master...pieh : schema_wip (بعد حذف بعض التعليمات البرمجية الميتة وإعادة هيكلة بعض الأشياء التي كانت لدي بالأمس ، يكون الرمز أقل بكثير مما لدي فكر :) ).

ليس لديك وقت لوضع العلاقات العامة للتعليقات مع وصف جيد ومستودع موقع الويب المستخدم للاختبار ، لذلك أحسب أنني سأشارك الكود الخاص بي في الوقت الحالي. إذا أراد أي شخص اللعب بها - ضع ملف gatsby-schema.gql مع تعريف المخطط في الدليل الجذر لمشروعك (على طول gatsby-node.js ، وما إلى ذلك).

أي فرصة هذا يمكن أن يشق طريقه إلى العلاقات العامة؟
أعتقد أن الكثير من الناس سيكونون سعداء بالحصول على هذا.

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

لذلك يبدو إنشاء المخطط حاليًا كما يلي:

يتضاعف التنفيذ لكل مصدر من الأنواع. يضيف إثبات المفهوم الخاص بي (الفرع الذي قمت بربطه) مصدرًا آخر فقط والآن تضاعف ثلاث مرات:

لن يكون من الممكن الاستمرار في إضافة هذا في الشكل الحالي.

ما أريد القيام به هو أن يبدو هذا شيئًا كهذا:

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

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

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

لقد قمت بإنشاء مشكلة RFC حول إعادة البناء (https://github.com/gatsbyjs/gatsby/issues/4261) ، إذا كان أي شخص مهتمًا بالانضمام إلى المناقشة ، فيرجى القيام بذلك.

شكرا على التحديث والعمل pieh . سأراقب مشكلة RFC.

مرحبا شباب. أي تحديثات على هذا؟ حاليًا أداة حظر / عرض توقف لنا لاستخدام Gatsby + Contentful وأردت فقط معرفة ما إذا كان هناك أي تطوير نشط أو ما إذا كان ينبغي علينا التفكير في خيارات أخرى. شكرا لك.

@ i8ramin لا يوجد تطوير نشط بعد ، أخطط لبدء هذا الأسبوع.

مرحبًا يا شباب ، فقط تحقق مما إذا كان شخص ما قد أحرز أي تقدم في هذه المشكلة - لقد اكتشفناها للتو عند التعامل مع الحقول الاختيارية / الفارغة في Contentful> Gatsby - لذلك سيكون من الجيد أن يكون لديك حل - من الواضح :) شكرًا مقدمًا!

مرحبًا pieh ، هل تساءلت فقط عما إذا حدث أي شيء مع التطوير؟ أرغب في استخدام Gatsby مع Contentful لمشروع ما ، ومع ذلك ، فإن هذا يعد قليلاً من العوائق. في صحتك مقدما!

يا nicolaslair و nathanjdunn ! آسف لعدم وجود تحديثات على هذا. اضطررت إلى تعليق هذا المشروع (... مرة أخرى) وتركيز وقتي على gatsby v2 في الوقت الحالي. أتمنى لو كان لدي أخبار أفضل :(

مرحبًا pieh ، هل سيتم إصلاح هذه المشكلة في Gatsby v2؟

لم يتم جدولة هذا لـ v2 - لن تؤدي هذه الميزة إلى كسر التغيير ، لذا فإن الخطة هي دفع v2 بأسرع ما يمكن ثم إضافة هذه الميزة في أحد إصدارات v2 الثانوية

pieh وأي شخص آخر ، أقوم بعمل noramlizer فوضوي للتأكد من وجود نفس نموذج البيانات دائمًا لـ GraphQL بغض النظر عن الحقول الاختيارية / الفارغة وما إلى ذلك. هل توصل أي شخص إلى حل بديل أفضل قبل تطوير شيء أكثر جوهرية؟

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

pieh هذه فكرة جيدة ، شكرًا أعتقد أنني

كمرجع ، أقوم الآن بإجراء هذا الحل البديل للإدخال الوهمي في المكون الإضافي المصدر الخاص بي ، مما يبقي فريق CMS سعيدًا ، ويعني أنه يتم التعامل مع تطبيع الإدخال الوهمي واستبعاده داخل كود Gatsby ، بدلاً من مكونات CMS أو UI React .

dominicchapman هل ترغب في إنشاء ريبو تجريبي لهذا؟
أو وظيفة متوسطة؟
أو أي شيء في هذه المرحلة

أى اخبار؟

شاهدت للتو المكوّن الإضافي https://github.com/Undistraction/gatsby-plugin-node-fields .

طريقة بسيطة ومتسقة لإدارة إنشاء الحقول على العقد الخاصة بك ، مع دعم القيم الافتراضية والتحويلات والتحقق من صحة القيم

أعتقد أن هذا يجب أن يكون جزءًا أساسيًا ... سأجربه بالتأكيد.

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

سيتم استئناف هذا بعد إصدار v2. ليس لدي عرض النطاق الترددي للتعامل مع الإصدار 2 وهذا في نفس الوقت

هل هناك حل بديل مقترح حتى وقت ما بعد V2 عندما يتم العمل عليه مرة أخرى؟
يبدو غريبًا إذا لم يكن الكثير من الأشخاص الذين يستخدمون GatsbyJS بحاجة إلى حقول اختيارية. أنا أستخدمها مع Contentful راجع للشغل.

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

لا يمتلك المكون الإضافي

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

pieh شكرًا على اقتراح الحل الآن :-)

pieh لم أكن أعرف ذلك - شكرًا لك على التوضيح. سؤال متابعة إذن ، ألن يكون من الممكن لمؤلفي البرنامج المساعد إدخال قيم وهمية للبيانات المفقودة قبل تمريرها إلى Gatsby؟ إذا اعترف Gatsby بالمفاتيح ذات القيمة undefined في المخطط ، فسأعتبر هذا حلاً أفضل بكثير.

نحن أيضًا نواجه هذه المشكلة مع gatsby-source-ghost . يحتوي مخطط البيانات الخاص بنا على الكثير من الحقول التي يمكن إرجاعها بشكل شرعي كأصفار ، وبالتالي يتم حذفها بواسطة Gatsby.

أسمع وأفهم 100٪ أن أي عمل في هذا يتوقف مؤقتًا حتى بعد أرض الإصدار 2 (وهو ما أتطلع إليه كثيرًا). أردت أن أشير إلى المكون الإضافي Ghost source على أنه مثال جيد آخر حيث يحدث هذا وأعرض المساعدة إذا كان هناك أي شيء يمكننا القيام به عندما يحين الوقت لاستئناف هذا 🙂

نفس المشكلة على https://github.com/datocms/gatsby-source-datocms 😄

سؤال: في V2 ، هل يمكننا استخدام هذا لتجنب مشكلة "الاستعلام عن البيانات المفقودة"؟

https://next.gatsbyjs.org/docs/actions/#addThirdPartySchema

بمعنى آخر ، هل يمكن أن يستخدم المكون الإضافي Contentful هذه الوظيفة لإدخال المخطط لنموذج محتوى لا يحتوي على بيانات / إدخالات حتى الآن؟

pieh هل كان لديك أي وقت لتحسين هذا وبدء أي تطوير؟ 😁

مرحبًا بالجميع ، أنا جديد تمامًا على GatsbyJS ولكني كنت أستخدم Contentful لفترة طويلة ، وبدأت للتو في تجربة إطار العمل والتلاعب ببعض من GraphQL. تعامل مع هذه المشكلة بسرعة كبيرة لأنه غالبًا ما يكون من المفيد وجود حقول اختيارية في Contentful.

ومع ذلك ، اكتشفت ما إذا كنت تقوم بسحب مجموعة (على سبيل المثال ، allContentfulNews إلخ) ولديك إدخال واحد على الأقل في تلك المجموعة يحتوي على محتوى في جميع الحقول (في حالتي ، لدي "تاريخ انتهاء صلاحية اختياري" ') ، فلن يؤدي ذلك إلى كسر البنية وإرجاع الإدخالات التي تحتوي على تاريخ انتهاء الصلاحية فارغة كـ null . لذا ، كحل بديل ، أخطط للاحتفاظ بنشر "النموذج" هذا وإخفائه في الواجهة الأمامية.

moreguppy حصلت على حل مماثل. يمكنك إنشاء صفحة جاهزة _Test_ وإخفاء هذه الصفحة. فمثلا:

allContentfulPageExample( filter: { title: { ne: "Test" } } )

moreguppyloeildes نعم ، هذا هو بالضبط كيف حللناها أيضًا في هذه الأثناء. ولكنه يجعل الأمر أكثر صعوبة على المدى الطويل ، في كل مرة تضيف فيها نموذج محتوى جديد / حقل جديد تحتاج إلى إنشاء / تحديث جميع الإدخالات "الوهمية" التي تم إنشاؤها.

لقد عمل إنشاء إدخالات وهمية بالنسبة لي كعمل مؤقت. ليس مثاليًا للأسباب المذكورة أعلاه ، فهل من المحتمل أن يتم النظر في هذا في أي وقت قريب؟

لا يزال لا يوجد حل في الأفق؟ لدينا إطلاق في 21 يومًا

@ bgnz968 من غير المحتمل أن يكون هناك إصلاح مناسب (أو بالأحرى ميزة) أرض في 21 يومًا. ليس لدي أي تواريخ هنا. هناك الكثير من المشكلات التي يجب حلها هنا - بعضها يتعلق بمخطط gatsby المدمج المستنتج ، والبعض الآخر بالمخططات المخيطة من طرف ثالث (https://github.com/gatsbyjs/rfcs/pull/11).

الشكل سأرمي سجلًا على النار أيضًا ... يجب أن أقوم أيضًا بعمل "الإدخال الوهمي" لتجنب إنشاء كسر في حفنة من المشاريع التي تستخدم gatsby-source-prismic . مثل stoltzrobin الذي تم التعبير عنه: إنه إصلاح مؤقت جيد بما فيه الكفاية ، لكنه اختراق.

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

أنا أستخدم أيضًا الإدخالات الوهمية للتعامل مع هذا ولكن أوافق على أنه v hacky. أحب أن أرى الإصلاح!

أيضًا باستخدام حل loeildes . فقط أضف صوتي هنا على أمل أن يكون هناك حل أكثر أمثل قريبًا.

مرحبا يا اصدقاء،
لم أختبر هذا ولكن قد يكون هذا الحل البديل النظيف الذي لا يتطلب إنشاء محتوى وهمي.

https://medium.com/@Zepro/contentful- الحقول المرجعية مع-gatsby-js-graphql-9f14ed90bdf9

Khaledgarbaya لم يكن لدي الكثير من الوقت لاختبار الحل الخاص بك ، ولكن في لمحة لا يمكنني الوصول إليها إلا من خلال توزيع Node هكذا؟

... on Node {
    ... on FieldType {
     # ...
   }
}

نعم ، يعمل الحل البديل فقط مع المراجع "متعددة الأشكال" ، ولكن ليس مع الحقول الاختيارية العادية

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

أعتقدpieh الصورة الحل سيكون بما فيه الكفاية ولكن أريد ذكر شيء في ذهني.

أرى أن https://www.drupal.org/project/schemata باستخدام http://json-schema.org/ مفيد هنا. ربما يمكننا الاستفادة من هذا ولدينا طريقة اختيارية لتوفير مخطط json بدلاً من استنتاجه. كيفية عرض مخطط json هذا سيعتمد جزئيًا على المكون الإضافي.

سيكون من الرائع الحصول على حل لهذا. يعمل استخدام محتوى العنصر النائب ولكنه يشعر بالتسلل ويجعلني متوترة خاصة عندما يكون لديك مراجع متداخلة

لقد أنشأت مشكلة مشابهة ولكنها مختلفة قليلاً في النطاق # 10856 - كيف يمكن للمكوِّن الإضافي المصدر إصلاح مشكلة الحقول وأنواع العقد المفقودة نظرًا لأن المخطط متاح لإبلاغ Gatsby بما هو مفقود.

rexxars هناك تذكرة أخرى متعلقة بهذا - https://github.com/gatsbyjs/gatsby/issues/4261 . لقد عمل https://github.com/gatsbyjs/gatsby/issues/4261#issuecomment -442549881 - هناك مثال على تحديد أنواع العقدة وشكلها (حتى لو لا توجد بيانات متاحة للاستدلال منها)

pieh شكرا! يبدو هذا واعدًا!

المنشور الأصلي من كانون الأول (ديسمبر) 2017. بدأنا نفقد الأمل وسنجد حلاً مناسبًا.

أعلم أن هذا ليس حلاً للمشكلة في هذا الإصدار من Gatsby ، ولكن Gatsby-source-graphql الخاص بـ Gatsby 2.0 قد أزال إلى حد كبير مشاكل استنتاج المخطط في تجربتي.

الجميع: يتم العمل على هذا بنشاط في # 11480.

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

هذا مثير للغاية ، شكرًا على عملك الشاق stefanprobst !

لقد رأيت واجهة برمجة التطبيقات الجديدة قيد المعاينة: ولكن ليس من الواضح بالنسبة لي كيف يمكن استخدام ذلك "لأخذ لقطة" لمخطط الرسم البياني الحالي لحل المشكلة التي تمت مناقشتها في هذه البطاقة. رأيت هناك على سبيل المثال https://www.gatsbyjs.org/packages/gatsby-plugin-extract-schema/ مع بعض التعليمات البرمجية البسيطة لاستخراج المخطط إلى ملف json. هل الفكرة هي أن شيئًا كهذا يمكن "إطعامه مرة أخرى" في مخطط غاتسبي؟

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

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

pieh يبدو رائعًا: سنستمر في مشاهدة هذا الفضاء. في غضون ذلك ، نضيف محتوى "اختبارًا" (: /) ونستبعد المحتوى من استعلامات الرسم البياني في وقت الإنشاء. يشعر "قذرة" :) شكرا!

واجهت مشكلة عند استخدام تخصيص المخطط الجديد مع gatsby-source-contentful.

يؤدي تحديد نوع يشير فيه أحد الحقول إلى مصفوفة مرجعية دائمًا إلى إرجاع null

بمعنى آخر:

type ContentfulPage implements Node {
   editorTitle: String
   title: String
   slug: String
   sections: [ContentfulSection] // im always null 
}

مرحبا!

لقد ساد الهدوء هذه القضية. الهدوء المخيف. 👻

نتلقى الكثير من المشكلات ، لذلك نقوم حاليًا بإغلاق المشكلات بعد 30 يومًا من عدم النشاط. لقد مرت 20 يومًا على الأقل منذ آخر تحديث هنا.

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

شكرًا لكونك جزءًا من مجتمع Gatsby! 💪💜

مرحبًا مرة أخرى!

لقد مرت 30 يومًا منذ حدوث أي شيء بشأن هذه المشكلة ، لذلك سيقوم روبوت الحي الودود (هذا أنا!) بإغلاقه.

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

شكرًا مرة أخرى لكونك جزءًا من مجتمع Gatsby!

واجهت مشكلة عند استخدام تخصيص المخطط الجديد مع gatsby-source-contentful.

يؤدي تحديد نوع يشير فيه أحد الحقول إلى مصفوفة مرجعية دائمًا إلى إرجاع null

بمعنى آخر:

type ContentfulPage implements Node {
   editorTitle: String
   title: String
   slug: String
   sections: [ContentfulSection] // im always null 
}

@ sami616 لقد وجدت أن هذا النهج

// In gatsby-node.js
exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type ContentfulPage implements Node {
      sections: ContentfulSection
    }
    type ContentfulSection implements Node {
      title: String
    }
  `
  createTypes(typeDefs)
}

يبدو أنه بالنسبة للحقول المرجعية ، يجب عليك تحديد شكل النموذج الذي تشير إليه أيضًا

لذلك أحاول حل هذا الأمر. لدي حقل "فيديو" (غير مطلوب في المحتوى) في نوع محتوى "ContentfulHomepage" مع حقل مرجعي يسمى "Blocks" يستدعي "ContentfulBlockHomepageBanner"

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

الاستعلام أدناه.

محاولتي...

خطأ في الخروج ...

هل يمكن لأي شخص أن يشير إلى أين أخطأت هنا؟ شكر.

مرحبًا مرة أخرى!

لقد مرت 30 يومًا منذ حدوث أي شيء بشأن هذه المشكلة ، لذلك سيقوم روبوت الحي الودود (هذا أنا!) بإغلاقه.

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

كتذكير ودي: أفضل طريقة لرؤية هذه المشكلة ، أو أي مشكلة أخرى ، يتم إصلاحها هي فتح طلب سحب. تحقق من gatsby.dev/contribute لمزيد من المعلومات حول فتح العلاقات العامة ، وقضايا الفرز ، والمساهمة!

شكرًا مرة أخرى لكونك جزءًا من مجتمع Gatsby!

هل أنا الوحيد الذي لا يزال يعاني من هذه المشكلة؟

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

واجهت مشكلة عند استخدام تخصيص المخطط الجديد مع gatsby-source-contentful.
يؤدي تحديد نوع يشير فيه أحد الحقول إلى مصفوفة مرجعية دائمًا إلى إرجاع null
بمعنى آخر:

type ContentfulPage implements Node {
   editorTitle: String
   title: String
   slug: String
   sections: [ContentfulSection] // im always null 
}

@ sami616 لقد وجدت أن هذا النهج

// In gatsby-node.js
exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type ContentfulPage implements Node {
      sections: ContentfulSection
    }
    type ContentfulSection implements Node {
      title: String
    }
  `
  createTypes(typeDefs)
}

يبدو أنه بالنسبة للحقول المرجعية ، يجب عليك تحديد شكل النموذج الذي تشير إليه أيضًا

silviopaganini لقد وجدت أن هذا حل جيد في هذه الأثناء

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

moreguppy أنا أحاول هذا لإصلاح مشكلة مماثلة مع gatsby-source-wordpress ، لكنني أتلقى الرسالة التالية عندما أضيف هذا الكود إلى gatsby-node.js:

خطأ: يجب أن يحتوي المخطط على أنواع ذات أسماء فريدة ولكن يحتوي على أنواع متعددة تسمى "wordpress__PAGEAcf".

رمز بلدي:

exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type wordpress__PAGEAcf implements Node {
      enter_content: String
    }
  `
  createTypes(typeDefs)
}

بغض النظر ، بالنسبة لأي شخص يواجه مشكلة مماثلة ، هذا هو التنسيق الصحيح لإصلاحه:

exports.sourceNodes = ({ actions }) => {
  const { createTypes } = actions
  const typeDefs = `
    type wordpress__PAGE implements Node {
      acf: wordpress__PAGEAcf
    }
    type wordpress__PAGEAcf implements Node {
      enter_content: String
    }
  `
  createTypes(typeDefs)
}

مرحبًا مرة أخرى!

لقد مرت 30 يومًا منذ حدوث أي شيء بشأن هذه المشكلة ، لذلك سيقوم روبوت الحي الودود (هذا أنا!) بإغلاقه.

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

كتذكير ودي: أفضل طريقة لرؤية هذه المشكلة ، أو أي مشكلة أخرى ، يتم إصلاحها هي فتح طلب سحب. تحقق من gatsby.dev/contribute لمزيد من المعلومات حول فتح العلاقات العامة ، وقضايا الفرز ، والمساهمة!

شكرًا مرة أخرى لكونك جزءًا من مجتمع Gatsby!

إعادة فتح وإضافة علامة not stale اعتبارًا من https://github.com/gatsbyjs/gatsby/issues/3344#issuecomment -505001979

سأكون ممتنًا للغاية إذا تمكن شخص ما من إعطاء الأشياء في # 16291 بعض الاختبارات الواقعية. شكر!

لدينا علاقات عامة مفتوحة لإغلاق المخطط في # 16291. سيكون رائعًا إذا كان بإمكان أولئك الذين لا يزالون مهتمين برؤية هذه الأرض مشاركة بعض التعليقات. شكر!

يا stefanprobst . عمل رائع!
آسف على الرد المتأخر. لقد توقف هذا لفترة طويلة لدرجة أنني اعتدت على الحلول ولم تعد مشكلة كبيرة بالنسبة لي. إنه أنيق للغاية رغم أن هذا يمضي قدمًا! :)
لقد جربته سريعًا وعملت بسلاسة! هذا نادر بما يكفي للتحية. ؛د
أنا أعمل على تحديث كبير لمشروع وسأخضع لمزيد من اختبارات "العالم الحقيقي" في الأسابيع المقبلة. سأعلق أكثر في العلاقات العامة.
شكرا جزيلا على العمل!

stefanprobst أي فكرة عن # 19210