Razzle: بدء تطبيق جديد

تم إنشاؤها على ٥ يونيو ٢٠١٧  ·  5تعليقات  ·  مصدر: jaredpalmer/razzle

هذا المشروع يبدو رائعا سأقوم بإنشاء مشروع جديد وكنت أتساءل فقط بين next.js ، و create-response-app ، و razzle ، ما هي الفوائد ، أو ما هو الأفضل على المدى الطويل. أود حقًا SSR لذا ربما يكون CRA غير وارد. لقد أنشأت تطبيقًا مع التالي ثم اكتشفت هذا المشروع. نأمل أن يكون هذا مكانًا جيدًا لطرح هذا السؤال ولكن أردت فقط الحصول على بعض الأفكار حول ما هو الأفضل على المدى الطويل.

discussion

التعليق الأكثر فائدة

شكرا knipferrc

تجربة مماثلة قادتني إلى ابتكار Razzle.

منذ حوالي 6 أشهر ، بدأت تطبيقًا ضخمًا مع Next.js بعد ظهوره مباشرة وكان هذا التطبيق أكثر من اللازم بالنسبة لي. لقد قمت فعليًا بتقديم PR لمثال التوجيه ذي المعلمات (على سبيل المثال ، /user/:id ). أتذكر أنني فقدت أسبوعًا كاملاً من العمل بسبب بعض الأخطاء الغريبة المتعلقة بإطلاق getInitialProps في تغييرات المسار . في نهاية اليوم ، يتخذ Next.js الكثير من القرارات المهمة جدًا بالنسبة لك (مثل التوجيه ، وجلب البيانات ، وهيكل المجلد ، والتصميم). يعتمد ما إذا كانت جيدة أو سيئة تمامًا على نوع التطبيق الذي تقوم ببنائه. كما اتضح ، لم أكن بحاجة فعليًا إلى عرض الخادم لكل مسار واحد (فقط مثل 2) ، كنت أرغب في حالات تحميل العميل بدلاً من إعادة تحميل الصفحة بالكامل ، ولم أرغب في تدمير شجرة الحالة العالمية بين تغييرات المسار. هذا ، إلى جانب رأيي بأن React-Router 4 هو أفضل شيء منذ شرائح الخبز ، يعني أن Next.js لم يكن مناسبًا للمشروع.

أبحث عن شيء أكثر استقرارًا ، انتقلت إلى مشروع NYT's kyt. كان هذا كافيًا لمدة شهرين تقريبًا ، ولكن 1) أصبحت أوقات الإنشاء بطيئة للغاية (> 45 ثانية) مع نمو التطبيق ، 2) لم تكن قواعد SCSS الخاصة بـ kyt مناسبة للمشروع ، و 3) وجدت تسجيل kyt (باستخدام الكمية المجنونة من الرموز التعبيرية) مزعجة جدًا. لذلك قررت أن أبدأ العمل على بديل أنحف وأسرع لـ kyt ، ولكن باستخدام HMR العالمي وواجهة برمجة تطبيقات تكوين مشابهة لـ Next.js - create-react-app-ssr ، إذا جاز التعبير.

بمجرد قول وفعل كل شيء ، أدركت أنني قمت بإنشاء نظام بناء شبه محايد للإطار وأن هذا المستوى من التجريد كان أكثر ملاءمة لاحتياجات مشروعي. من خلال "حيادي إطار العمل" ، أعني أن Razzle سيعمل بنسبة 100٪ مع Angular و Vue و Rax و Preact و Inferno و React-XP و RN-Web و Reason-React ، والأهم من ذلك بالنسبة لي ، أيًا كانت الأشياء المجنونة التي تأتي بعد ذلك. IMHO ، القدرة على التكيف هي الفارق الرئيسي بين Razzle وكل شيء آخر رأيته. باستخدام Razzle ، يمكنك القراءة عن شيء ما في منشور مدونة ، وإنشاء مفترق ، وإضافة نظام babel-transform / webpack config / المتوازي ، وما عليك سوى الانتقال إلى تجربة shit . لماذا ا؟ لأنه على عكس التالي ، فإن Razzle ليس إطار عمل وعلى عكس CRA ، يتيح لك Razzle زيادة التكوين الأساسي دون الحاجة إليه. هذا ضخم بالنسبة للطريقة التي أتعلم بها وأعلم بها وأقوم بالتجربة وأقوم بأعمال تجارية.

لقد أثمرت مرونة Razzle ولا أدريته بالفعل بالنسبة لي ولفريقي:

  • لقد نقلنا تطبيقنا تدريجيًا من Flow جزئيًا إلى TypeScript بنسبة 100٪ عن طريق تغيير أقل من 10 أسطر من التعليمات البرمجية في razzle.config.js .
  • بدون المحاولة ، أصبح Razzle أسرع طريقة لبدء مشروع ReasonReact (SSR أو SPA).

أما بالنسبة لمستقبل رازل. قبل يومين ، تم ذكر "إضافة دعم SSR إلى CRA" كأفضل 15 يجب القيام به في خريطة طريق فريق React Core. إذا تمت إضافة دعم SSR إلى CRA ، فقد لا تحتاج Razzle إلى الوجود بعد الآن ... وأنا رائع تمامًا مع ذلك_. حتى يحدث ذلك ، ستدفع Razzle للأمام كأداة بناء لا تعتمد على إطار عمل لخادم جافا سكريبت عالمي.

ال 5 كومينتر

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

بقدر ما أعرف أن Next.js هو إطار عمل كامل يمكن استخدامه اختياريًا كجزء من نظام ZEIT البيئي؟ أم منصة ؟. في حين أن Razzle أكثر بساطة. لذلك فهو لا يتضمن ميزات قد لا تحتاجها ، ولكن من الصحيح أيضًا أنه لا يتضمن ميزات قد تحتاجها أو قد تحتاجها في النهاية.

لقد فكرت أيضًا في استخدام Next.js من قبل ، ولكن كانت هناك بعض التفاصيل الصغيرة التي كانت مزعجة بالنسبة لي. على سبيل المثال ، لا يقوم Next.js بتصغير إخراج HTML بشكل صحيح (أعلم أن هذا ليس مهمًا على الإطلاق ، لكن هذا كان بمثابة كسر للصفقة بالنسبة لي). كما أنه يستخدم Styled-jsx و CSS-in-JS ، لكنني أفضل المكوّنات الأنماط. بالإضافة إلى مشروعي الجديد ، لم أكن بحاجة إلى التوجيه (بعد 😄).

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

شكرا knipferrc

تجربة مماثلة قادتني إلى ابتكار Razzle.

منذ حوالي 6 أشهر ، بدأت تطبيقًا ضخمًا مع Next.js بعد ظهوره مباشرة وكان هذا التطبيق أكثر من اللازم بالنسبة لي. لقد قمت فعليًا بتقديم PR لمثال التوجيه ذي المعلمات (على سبيل المثال ، /user/:id ). أتذكر أنني فقدت أسبوعًا كاملاً من العمل بسبب بعض الأخطاء الغريبة المتعلقة بإطلاق getInitialProps في تغييرات المسار . في نهاية اليوم ، يتخذ Next.js الكثير من القرارات المهمة جدًا بالنسبة لك (مثل التوجيه ، وجلب البيانات ، وهيكل المجلد ، والتصميم). يعتمد ما إذا كانت جيدة أو سيئة تمامًا على نوع التطبيق الذي تقوم ببنائه. كما اتضح ، لم أكن بحاجة فعليًا إلى عرض الخادم لكل مسار واحد (فقط مثل 2) ، كنت أرغب في حالات تحميل العميل بدلاً من إعادة تحميل الصفحة بالكامل ، ولم أرغب في تدمير شجرة الحالة العالمية بين تغييرات المسار. هذا ، إلى جانب رأيي بأن React-Router 4 هو أفضل شيء منذ شرائح الخبز ، يعني أن Next.js لم يكن مناسبًا للمشروع.

أبحث عن شيء أكثر استقرارًا ، انتقلت إلى مشروع NYT's kyt. كان هذا كافيًا لمدة شهرين تقريبًا ، ولكن 1) أصبحت أوقات الإنشاء بطيئة للغاية (> 45 ثانية) مع نمو التطبيق ، 2) لم تكن قواعد SCSS الخاصة بـ kyt مناسبة للمشروع ، و 3) وجدت تسجيل kyt (باستخدام الكمية المجنونة من الرموز التعبيرية) مزعجة جدًا. لذلك قررت أن أبدأ العمل على بديل أنحف وأسرع لـ kyt ، ولكن باستخدام HMR العالمي وواجهة برمجة تطبيقات تكوين مشابهة لـ Next.js - create-react-app-ssr ، إذا جاز التعبير.

بمجرد قول وفعل كل شيء ، أدركت أنني قمت بإنشاء نظام بناء شبه محايد للإطار وأن هذا المستوى من التجريد كان أكثر ملاءمة لاحتياجات مشروعي. من خلال "حيادي إطار العمل" ، أعني أن Razzle سيعمل بنسبة 100٪ مع Angular و Vue و Rax و Preact و Inferno و React-XP و RN-Web و Reason-React ، والأهم من ذلك بالنسبة لي ، أيًا كانت الأشياء المجنونة التي تأتي بعد ذلك. IMHO ، القدرة على التكيف هي الفارق الرئيسي بين Razzle وكل شيء آخر رأيته. باستخدام Razzle ، يمكنك القراءة عن شيء ما في منشور مدونة ، وإنشاء مفترق ، وإضافة نظام babel-transform / webpack config / المتوازي ، وما عليك سوى الانتقال إلى تجربة shit . لماذا ا؟ لأنه على عكس التالي ، فإن Razzle ليس إطار عمل وعلى عكس CRA ، يتيح لك Razzle زيادة التكوين الأساسي دون الحاجة إليه. هذا ضخم بالنسبة للطريقة التي أتعلم بها وأعلم بها وأقوم بالتجربة وأقوم بأعمال تجارية.

لقد أثمرت مرونة Razzle ولا أدريته بالفعل بالنسبة لي ولفريقي:

  • لقد نقلنا تطبيقنا تدريجيًا من Flow جزئيًا إلى TypeScript بنسبة 100٪ عن طريق تغيير أقل من 10 أسطر من التعليمات البرمجية في razzle.config.js .
  • بدون المحاولة ، أصبح Razzle أسرع طريقة لبدء مشروع ReasonReact (SSR أو SPA).

أما بالنسبة لمستقبل رازل. قبل يومين ، تم ذكر "إضافة دعم SSR إلى CRA" كأفضل 15 يجب القيام به في خريطة طريق فريق React Core. إذا تمت إضافة دعم SSR إلى CRA ، فقد لا تحتاج Razzle إلى الوجود بعد الآن ... وأنا رائع تمامًا مع ذلك_. حتى يحدث ذلك ، ستدفع Razzle للأمام كأداة بناء لا تعتمد على إطار عمل لخادم جافا سكريبت عالمي.

رائع!! شكرا جزيلا يا رفاق على الردود الرائعة.

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

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات

القضايا ذات الصلة

howardya picture howardya  ·  5تعليقات

Jayphen picture Jayphen  ·  4تعليقات

JacopKane picture JacopKane  ·  3تعليقات

mhuggins picture mhuggins  ·  3تعليقات

gabimor picture gabimor  ·  3تعليقات