डेवलपर्स के लिए ईमेल बिल्डर

GrapesJS के साथ एक ड्रैग-एंड-ड्रॉप ईमेल बिल्डर बनाएं

अपने SaaS, CMS, मार्केटिंग प्लेटफ़ॉर्म या आंतरिक टूल के लिए एक विज़ुअल ईमेल संपादक बनाएं। उपयोगकर्ताओं को ड्रैग-एंड-ड्रॉप ब्लॉक के साथ उत्तरदायी ईमेल बनाने दें, जबकि आपकी टीम घटकों, टेम्प्लेट, भंडारण, आउटपुट और प्रकाशन को नियंत्रित करती है।

ड्रैग-एंड-ड्रॉप कैनवासHTML, MJML या परियोजना JSONआपका डेटाबेस, आपका ESPओपन सोर्स कोर, BSD-3-Clause

आपके उपयोगकर्ता नेत्रहीन रूप से ईमेल बनाते हैं। आपका एप्लिकेशन अनुभव को नियंत्रित करता है।

लाइव संपादक

ईमेल बिल्डर आज़माएं

यह इस पृष्ठ पर चल रहा एक वास्तविक GrapesJS संपादक है - न कि वीडियो और न ही स्क्रीनशॉट। दाईं ओर से एक ब्लॉक को खींचें, इसे फिर से स्टाइल करने के लिए कुछ भी चुनें, फोन की चौड़ाई पर स्विच करें, फिर मार्कअप को वापस पढ़ें। हेडर और पाद लेख लॉक हैं, जो वही पैटर्न है जो अनुभाग आगे बताता है।

आप यहां क्या कर सकते हैं

  1. ब्लॉक
  2. कैंवस
  3. बिछाना
  4. प्रतिसंवेदी
  5. पूर्वसमीक्षा
  6. HTML / JSON
परिभाषा

ड्रैग-एंड-ड्रॉप ईमेल बिल्डर क्या है?

ड्रैग-एंड-ड्रॉप ईमेल बिल्डर एक विज़ुअल एडिटर है जो उपयोगकर्ताओं को HTML टेबल और ईमेल-विशिष्ट CSS लिखने के बजाय पुनः प्रयोज्य घटकों से ईमेल लेआउट बनाने देता है।

अंतर यह है कि नियमों को किसे जानना है। एक बिल्डर के बिना, जो कोई भी ईमेल लिखता है उसे यह जानने की जरूरत है कि लेआउट नेस्टेड टेबल के साथ किया जाता है, कि अधिकांश स्टाइल इनलाइन होना चाहिए, और यह कि एक आवारा मार्जिन एक क्लाइंट में डिजाइन को ध्वस्त कर सकता है। एक बिल्डर के साथ, उन नियमों को एक बार एन्कोड किया जाता है - आपके द्वारा - ब्लॉक और घटकों में, और बाकी सभी बस उन्हें व्यवस्थित करते हैं।

एक दृश्य बिल्डर के बिना

कोई व्यक्ति टेबल मार्कअप को हाथ से लिखता है, फिर उसे हाथ से जांचता है। हर नया ईमेल पिछले ईमेल की एक प्रति से शुरू होता है।

welcome.htmlhtml
<table role="presentation" cellpadding="0" cellspacing="0" width="600">
  <tr>
    <td style="padding:32px;font-family:Arial,sans-serif">
      <h1 style="margin:0 0 12px;font-size:26px">स्वागत है</h1>
      <p style="margin:0;font-size:15px;line-height:1.6">आपकी सामग्री... </p>
    </td>
  </tr>
</table>

ड्रैग-एंड-ड्रॉप बिल्डर के साथ

कोई ब्लॉक की व्यवस्था करता है. तालिका मार्कअप उन घटकों से उत्पन्न होता है जिन्हें आपने एक बार परिभाषित और समीक्षा की थी.

  1. हैडर
  2. Hero
  3. टेक्स्ट
  4. छवि
  5. CTA
  6. पाद लेख

ईमेल को आसान बनाने के लिए बिल्डर नहीं है। यह कठिन भागों को किसी और के निर्णय को बनाने के लिए है - आपका, एक बार किया गया, घटक स्तर पर।

कठिन हिस्सा

ईमेल बिल्डर्स वेबसाइट बिल्डरों की तुलना में कठिन क्यों हैं

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

जहां आपके ईमेल को जीवित रहना है

  • Gmail

    वेब, एंड्रॉइड और आईओएस ऐप एक दूसरे से अलग व्यवहार करते हैं, और वेब क्लाइंट रेंडरिंग से पहले आपकी शैलियों को संसाधित करता है।

  • Outlook

    डेस्कटॉप, वेब और नए विंडोज क्लाइंट प्रभावी रूप से अलग-अलग रेंडरर हैं। विंडोज पर डेस्कटॉप बिल्ड ऐतिहासिक रूप से सबसे सख्त लक्ष्य रहा है।

  • Apple Mail

    आम ग्राहकों में सबसे अनुमेय, जो इसे एक खराब प्रॉक्सी बनाता है: एक ईमेल जो यहां दिखता है वह अभी भी कहीं और टूट सकता है।

  • Yahoo Mail

    शैलियों और मार्कअप के लिए अपने स्वयं के स्वच्छता नियमों के साथ एक और वेबमेल क्लाइंट।

  • मोबाइल क्लाइंट

    संकीर्ण व्यूपोर्ट, आक्रामक टेक्स्ट स्केलिंग और डार्क-मोड हैंडलिंग जो ऐप और ओएस संस्करण के अनुसार भिन्न होती है।

  • बाकी सब कुछ

    कॉर्पोरेट गेटवे, क्षेत्रीय प्रदाता और पुराने ग्राहक जो कभी भी एक विशिष्ट परीक्षण मैट्रिक्स में दिखाई नहीं देते हैं।

यह बिल्डर पर क्या मजबूर करता है

  • लेआउट टेबल है, फ्लेक्सबॉक्स या ग्रिड नहीं

    आपके कॉलम, स्पेसर और डिवाइडर टेबल घटक होने चाहिए। उपयोगकर्ताओं को कभी भी कैनवास में नंगे div को गिराने में सक्षम नहीं होना चाहिए।

  • CSS समर्थन आंशिक और असमान है

    ब्राउज़र के पूर्ण सेट को उजागर करने के बजाय, Style Manager को उन गुणों तक सीमित करें जिनका आपने वास्तव में परीक्षण किया है।

  • शैलियाँ सबसे सुरक्षित इनलाइन हैं

    या तो एक प्रीसेट के साथ लेखक जो निर्यात पर इनलाइन करता है, या ईमेल आपके बैकएंड को छोड़ने से पहले अपनी पाइपलाइन में एक इनलाइनर चलाता है।

  • मीडिया के प्रश्नों का सार्वभौमिक रूप से सम्मान नहीं किया जाता है

    डिज़ाइन करें ताकि एकल-स्तंभ फ़ॉलबैक पहले से ही स्वीकार्य हो, और उत्तरदायी नियमों को एक आवश्यकता के बजाय सुधार के रूप में मानें।

  • छवियां अक्सर डिफ़ॉल्ट रूप से अवरुद्ध होती हैं

    प्रत्येक छवि घटक पर वैकल्पिक पाठ की आवश्यकता होती है, और कभी भी किसी ब्लॉक को पठनीय होने के लिए छवि पर निर्भर न होने दें।

  • डार्क मोड आपके ईमेल को फिर से रंग दे सकता है

    कुछ ग्राहक स्वचालित रूप से रंग बदल देते हैं या बदल देते हैं। ऐसे डिज़ाइन से बचें जो किसी विशिष्ट पृष्ठभूमि पर निर्भर करते हैं, बिल्कुल उसी रंग के रहते हैं।

  • वेब फ़ॉन्ट अक्सर लोड नहीं होते हैं

    प्रत्येक पाठ घटक पर एक वास्तविक फ़ॉलबैक स्टैक शिप करें, और इच्छित चेहरे के बजाय फ़ॉलबैक के साथ ईमेल की जाँच करें।

  • स्क्रिप्ट नहीं चलती हैं, और अन्तरक्रियाशीलता सीमित है

    कुछ भी गतिशील एक लिंक के पीछे होता है। एक बिल्डर जो उपयोगकर्ताओं को इंटरैक्टिव ब्लॉक प्रदान करता है, उन्हें कुछ ऐसा पेश कर रहा है जो काम नहीं करेगा।

  • वाणिज्यिक मेल कानूनी आवश्यकताओं को पूरा करता है

    प्रेषक की पहचान और सदस्यता समाप्त करने का तंत्र दायित्व हैं, डिज़ाइन विकल्प नहीं। चेकलिस्ट पर भरोसा करने के बजाय उन्हें टेम्पलेट में लॉक करें।

आप एक ऐसे संपादक का निर्माण नहीं कर रहे हैं जो सुंदर HTML का उत्पादन करता है। आप एक ऐसे संपादक का निर्माण कर रहे हैं जो खतरनाक HTML का उत्पादन नहीं कर सकता।

क्लाइंट व्यवहार रिलीज़ और रेंडरिंग मोड के साथ बदलता है, इसलिए यह पृष्ठ कोई प्रति-ग्राहक समर्थन मैट्रिक्स नहीं बताता है। ग्राहकों के खिलाफ मान्य करें और आपके अपने दर्शकों द्वारा वास्तव में उपयोग की जाने वाली सुविधाओं को मान्य करें। अंतिम समीक्षा 2026-09-03।

संपादन परत

ईमेल बिल्डर के लिए GrapesJS का उपयोग क्यों करें?

GrapesJS एक ओपन-सोर्स (BSD-3-Clause) वेब बिल्डर फ्रेमवर्क है, जो वर्तमान में 0.23.6 है, जिसमें GitHub पर लगभग 26k+ सितारे हैं। यह आपको एक संपादक के ऐसे हिस्से देता है जिन्हें बनाना महंगा होता है और उनमें अंतर करना उबाऊ होता है, और उन हिस्सों के लिए रास्ते से हट जाता है जो वास्तव में आपके उत्पाद हैं।

कैनवास और ड्रैग-एंड-ड्रॉप

चयन के साथ एक iframe कैनवास, लक्ष्य खींचें, संकेतक ड्रॉप करें, आकार बदलें और एक घटक टूलबार - इंटरैक्शन परत जिसे सही होने में महीनों लगते हैं और जिसके लिए कोई भी आपके उत्पाद को नहीं खरीदता है।

Components और ब्लॉक

एक बार ईमेल-सुरक्षित घटक को परिभाषित करें, फिर इसे एक ब्लॉक उपयोगकर्ता के रूप में उजागर करें। Components अपने स्वयं के नियम रखें: वे क्या स्वीकार करते हैं, क्या संपादित किया जा सकता है, क्या स्टाइल किया जा सकता है।

शैली और Trait प्रबंधक

एक स्टाइलिंग पैनल जिसे आप उन गुणों तक सीमित कर सकते हैं जिन्हें ईमेल वास्तव में समर्थन करता है, और उन सेटिंग्स के लिए एक traits पैनल जो CSS नहीं हैं - एक लिंक लक्ष्य, एक वैकल्पिक पाठ, एक मर्ज फ़ील्ड।

परतें और संपत्ति

नेस्टेड तालिकाओं के लिए एक संरचना वृक्ष जिसे क्लिक करके चुनना कठिन होता है, और एक परिसंपत्ति प्रबंधक जिसे आप अपनी स्वयं की मीडिया लाइब्रेरी में इंगित कर सकते हैं.

Storage Manager और परियोजना की स्थिति

पूरा संपादक राज्य JSON को प्रोजेक्ट करने के लिए क्रमबद्ध करता है। Storage Manager को अपने API पर इंगित करें और संपादक यह परवाह करना बंद कर देता है कि डेटा कहाँ रहता है।

Commands और प्लगइन्स

प्रत्येक संपादक कार्रवाई एक नामित कमांड है जिसे आप कॉल कर सकते हैं, ओवरराइड कर सकते हैं या जोड़ सकते हैं - जो कि 100+ प्लगइन्स पर GJS.Market इसे बिना कांटे के कैसे बढ़ाते हैं।

GrapesJS संपादन परत प्रदान करता है। आपका एप्लिकेशन ईमेल उत्पाद प्रदान करता है।

स्‍थापत्‍यशैली

ड्रैग-एंड-ड्रॉप ईमेल बिल्डर कैसे काम करता है

एक अनुरोध पथ, ब्लॉक खींचने वाले व्यक्ति से लेकर मेल खोलने वाले व्यक्ति तक। नीचे दी गई प्रत्येक परत का एक मालिक होता है, और अधिकांश एकीकरण समस्याएं गलत जिम्मेदारी डालने से आती हैं।
  1. Your SaaS / application

    आपका उत्पाद: खाते, किरायेदार, बिलिंग, वह मार्ग जिस पर संपादक लगाया जाता है।

  2. Email builder UI

    संपादक के चारों ओर आपका खोल: टेम्पलेट पिकर, राज्य सहेजें, बटन भेजें, अनुमोदन।

  3. GrapesJS

    दृश्य संपादन इंजन। यह घटकों और कैनवस के बारे में जानता है, और आपके उपयोगकर्ताओं के बारे में कुछ भी नहीं जानता है।

  4. Editor modules

    आपके द्वारा कॉन्फ़िगर किए गए संपादक उप-सिस्टम: कौन से ब्लॉक मौजूद हैं, वे क्या स्वीकार करते हैं, क्या स्टाइल किया जा सकता है, क्या संपादित किया जा सकता है।

    • Blocks
    • Components
    • Styles
    • Traits
  5. Project JSON

    क्रमबद्ध संपादक की स्थिति। यह वही है जिसे आप संग्रहीत करते हैं ताकि बाद में एक ईमेल को फिर से खोला जा सके।

  6. Your backend / API

    आपका API: अनुमतियाँ, संस्करण, मर्ज-टैग रिज़ॉल्यूशन, सत्यापन, अभियान रिकॉर्ड।

  7. HTML / MJML

    मार्कअप जो आप वास्तव में भेजते हैं। संग्रहीत परियोजना से मांग पर उत्पन्न।

  8. Your email provider

    प्रदाता जो मेल वितरित करता है और रिपोर्ट करता है कि उसके साथ क्या हुआ।

  9. Recipient

    इनबॉक्स, और जो भी क्लाइंट इसे प्रस्तुत करने के लिए होता है।

GrapesJS कभी भी आपके डेटाबेस से बात नहीं करता है और कभी भी आपके ईमेल प्रदाता से बात नहीं करता है। यह आपको एक दस्तावेज़ सौंपता है; उसके बाद सब कुछ आपकी वास्तुकला है।

जिम्मेदारियों

किसका मालिक है

तीन मालिक, कोई ओवरलैप नहीं। इस पृष्ठ के विषय पर सबसे आम वास्तुशिल्प गलती संपादक से दाहिने हाथ के कॉलम में कुछ करने की उम्मीद कर रही है।

आपका आवेदन
  • उपयोगकर्ता और खाते
  • भूमिकाएं और अनुमतियां
  • टेम्पलेट रिकॉर्ड
  • भंडारण और संस्करण
  • मर्ज-टैग समाधान
  • अभियान और शेड्यूलिंग
  • आउटपुट सत्यापन
GrapesJS
  • दृश्य कैनवास
  • खींचें और छोड़ें
  • घटक मॉडल
  • ब्लॉक लाइब्रेरी
  • शैली संपादन
  • परत का पेड़
  • पूर्ववत करें / फिर से करें
  • परियोजना क्रमांकन
आपका ईमेल प्रदाता
  • वितरण
  • उछाल और शिकायतें
  • खुलता है, क्लिक और इवेंट

दाहिने हाथ के कॉलम में कुछ भी GrapesJS गैप नहीं है - वे पंक्तियाँ कभी भी संपादक का काम नहीं थीं। उन्हें पहले स्प्रिंट से एप्लिकेशन कार्य के रूप में मानना ही एकीकरण को सरल रखता है।

उत्पादन

HTML, MJML और JSON: क्या अंतर है?

तीन कलाकृतियाँ एक ही कैनवास से निकलती हैं, और वे विनिमेय नहीं होती हैं। एक वह प्रोजेक्ट है जिसे आप रखते हैं, दो वे डिलीवरी प्रारूप हैं जो आप इससे उत्पन्न करते हैं।

परियोजना JSON

GrapesJS कोर

ईमेल का संपादन योग्य प्रतिनिधित्व - घटक, शैलियाँ, संपत्तियाँ और पृष्ठ, ठीक उसी तरह जैसे संपादक उन्हें रखता है।

के लिए सबसे अच्छा

  • कार्य को बचाने का कार्य प्रगति पर है
  • संपादन के लिए टेम्पलेट को फिर से खोलना
  • डुप्लिकेट करना और वर्ज़न करना
  • संशोधनों के बीच क्या बदल गया

आप इसे कैसे प्राप्त करते हैं

editor.getProjectData()

यह स्टोर करने के लिए है। केवल HTML को संग्रहीत करने का मतलब है कि अगला संपादन उपयोगकर्ता द्वारा बनाए गए दस्तावेज़ के बजाय पार्स किए गए मार्कअप से शुरू होता है।

HTML

grapesjs-preset-newsletter

टेबल-आधारित मार्कअप जो आप एक भेजने वाले प्रदाता को सौंपते हैं, जिसमें शैलियाँ शामिल होती हैं ताकि अधिक ग्राहक उन्हें बनाए रखें।

के लिए सबसे अच्छा

  • अंतिम ईमेल जो भेजा जाता है
  • मौजूदा पाइपलाइन को सौंपना
  • आउटपुट पर अधिकतम नियंत्रण

आप इसे कैसे प्राप्त करते हैं

editor.runCommand('gjs-get-inlined-html')

इनलाइनिंग कमांड न्यूज़लेटर प्रीसेट से आता है, GrapesJS कोर से नहीं। इसके बिना आपको कैनवास मार्कअप और एक स्टाइलशीट मिलती है, जो वह नहीं है जिसे आप भेजना चाहते हैं।

MJML

grapesjs-mjml

ईमेल के लिए एक उच्च-स्तरीय मार्कअप भाषा जो उत्तरदायी तालिका HTML तक संकलित करती है।

के लिए सबसे अच्छा

  • कम मार्कअप के साथ उत्तरदायी ईमेल लिखना
  • संग्रहीत स्रोत को पठनीय रखना
  • भेजने के समय HTML तक संकलन

आप इसे कैसे प्राप्त करते हैं

editor.runCommand('mjml-code')

MJML एक अलग पारिस्थितिकी तंत्र है: संपादक प्लगइन MJML घटकों को प्रस्तुत करता है, और एक कंपाइलर उन्हें HTML में बदल देता है। दोनों आपके द्वारा जोड़े गए तृतीय-पक्ष पैकेज हैं।

JSON परियोजना है। HTML और MJML डिलीवरी हैं। पहले को स्टोर करें, दूसरों को जेनरेट करें।

कैनवास से इनबॉक्स तक

  1. दृश्य संपादक
  2. परियोजना JSON
  3. आपका डेटाबेस
  4. भेजने पर रेंडर करें
  5. HTML
  6. आपका प्रदाता
सेव टाइम के बजाय भेजने के समय पर रेंडरिंग करने से टैग को प्रति प्राप्तकर्ता हल करने देता है — और जो आपको प्रत्येक टेम्पलेट को फिर से सहेजे बिना एक पाद लेख को ठीक करने देता है.
अवयव

उपयोगकर्ताओं को ईमेल-सुरक्षित घटक दें

उपयोगकर्ताओं को एक खाली कैनवास और एक div न दें। घटकों का एक छोटा सा सेट शिप करें जो पहले से ही टेबल मार्कअप, इनलाइन शैलियों और फॉलबैक को एन्कोड करते हैं, फिर लोगों को उन्हें व्यवस्थित करने दें। ये दस मार्केटिंग और जीवनचक्र ईमेल को वास्तव में क्या चाहिए, उनमें से अधिकांश को कवर करते हैं।

  • हैडर

    लोगो, ब्रांड बार, प्रीहेडर टेक्स्ट। आमतौर पर लॉक किया जाता है ताकि हर ईमेल एक ही पहचान के साथ छोड़ दे।

  • Hero

    शीर्षक, सहायक पंक्ति और एक कार्रवाई। आकार का ताकि संदेश छवि लोड किए बिना जीवित रहे।

  • टेक्स्ट

    एक वास्तविक फ़ॉन्ट फ़ॉलबैक स्टैक और लाइन ऊंचाई के साथ एक पैराग्राफ ब्लॉक जो फोन की चौड़ाई पर रहता है।

  • छवि

    निश्चित चौड़ाई, स्पष्ट आयाम और आवश्यक वैकल्पिक पाठ, इसलिए एक अवरुद्ध छवि अभी भी एक पठनीय ईमेल छोड़ती है।

  • घुंडी

    एक स्टाइल एंकर के बजाय एक टेबल-आधारित बटन - अंतर सख्त ग्राहकों में दिखाई देता है।

  • दो-कॉलम अनुभाग

    एक तालिका पंक्ति जो संकीर्ण व्यूपोर्ट पर ढेर होती है, स्टैक्ड ऑर्डर आपके द्वारा पहले से ही तय की जाती है।

  • उत्पाद कार्ड

    छवि, नाम, मूल्य और लिंक, कॉपी-पेस्ट के बजाय आपके बैकएंड को भरने वाले फ़ील्ड द्वारा संचालित।

  • सामाजिक लिंक

    आइकन और URL की एक निश्चित पंक्ति, मार्कअप के बजाय सेटिंग्स के रूप में संपादन योग्य।

  • विभक्त

    <hr> तत्व के बजाय टेबल बॉर्डर के साथ खींचा गया नियम, जिसे कई क्लाइंट रीस्टाइल करते हैं।

  • पाद लेख

    प्रेषक की पहचान, पता और सदस्यता समाप्त करें लिंक। आमतौर पर बंद कर दिया जाता है, क्योंकि ये दायित्व हैं।

उपयोगकर्ताओं को ईमेल HTML को समझने की आवश्यकता के बिना विज़ुअल डिज़ाइन करने दें।

ब्लॉक

पुनः प्रयोज्य ब्लॉकों से ईमेल बनाएं

एक घटक परिभाषा है; एक ब्लॉक वह है कि उपयोगकर्ता कैनवास पर एक कैसे प्राप्त करता है। ब्लॉक लाइब्रेरी आपके पास सबसे शक्तिशाली लीवर है जो लोग बना सकते हैं - और उदार होने से गलत होने के लिए सबसे आसान है।

वह लूप जिसे आपके उपयोगकर्ता दोहराते हैं

  1. ब्लॉक लाइब्रेरी
  2. कैनवास पर खींचें
  3. अनुकूलित करें
  4. टेम्पलेट के रूप में सहेजें

एक अप्रतिबंधित कैनवास

हर तत्व उपलब्ध है, हर शैली संपादन योग्य, संरचना के बारे में कोई राय नहीं।

  • उपयोगकर्ता मार्कअप का उत्पादन करते हैं जिसकी किसी ने समीक्षा नहीं की
  • एक क्लाइंट रेंडरिंग के बारे में समर्थन अनुरोध
  • टेम्प्लेट हफ्तों के भीतर ब्रांड से दूर हो जाते हैं
  • बाद में साझा किए गए अनुभाग को बदलने का कोई सुरक्षित तरीका नहीं है

एक क्यूरेटेड ब्लॉक लाइब्रेरी

आपके द्वारा डिज़ाइन किए गए ब्लॉकों की एक छोटी सूची, परीक्षण किया गया है और केंद्रीय रूप से बदल सकता है।

  • आउटपुट आपके द्वारा मान्य मार्कअप के अंदर रहता है
  • नए उपयोगकर्ता प्रशिक्षण के बिना उत्पादक हैं
  • ब्रांड नियम घटक में रहते हैं, दस्तावेज़ में नहीं
  • किसी ब्लॉक में सुधार करने से उसका उपयोग करने वाले प्रत्येक ईमेल में सुधार होता है
सुव्‍यवस्थित करना

टेम्प्लेट, ब्लॉक और घटक

तीन स्तर, और उन्हें भ्रमित करना वह है जो ईमेल बिल्डरों को विकसित करना कठिन बनाता है। घटक वही हैं जो चीजें हैं, ब्लॉक वे हैं कि वे कैसे जोड़े जाते हैं, टेम्पलेट शुरुआती बिंदु समाप्त हो जाते हैं।

  1. टेम्पलेट्स
  2. ब्लॉक
  3. अवयव
  4. एक टेम्पलेट सिस्टम जिसे आपकी टीम विकसित कर सकती है

टेम्पलेट्स

पूर्ण ईमेल डिज़ाइन

एक संपूर्ण ईमेल जिसे उपयोगकर्ता शुरू कर सकता है - न्यूज़लेटर, रसीद, ऑनबोर्डिंग चरण। प्रोजेक्ट JSON के रूप में संग्रहीत, उपयोग पर क्लोन।

ब्लॉक

पुनः प्रयोज्य अनुभाग

एक टेम्पलेट खींचने योग्य इकाइयों से इकट्ठा किया जाता है: एक hero, एक लेख पंक्ति, एक CTA बैंड, एक पाद लेख।

अवयव

डोमेन-विशिष्ट तत्व

एक ब्लॉक के अंदर संपादन योग्य आदिम, अपने स्वयं के traits और नियमों के साथ - एक उत्पाद कार्ड जो जानता है कि इसकी कीमत है।

पहले घटकों का निर्माण करें, फिर वे ब्लॉक बनाएं जो उन्हें उजागर करते हैं, फिर उन्हें व्यवस्थित करने वाले टेम्पलेट। टेम्पलेट स्तर पर शुरू होने वाली टीमें दर्जनों लगभग समान डिज़ाइन के साथ समाप्त होती हैं और उनमें से किसी को भी बदलने का कोई तरीका नहीं होता है।

एक न्यूज़लेटर टेम्पलेट, विस्तारित

न्यूज़लेटर टेम्पलेट

  • ├── हैडर (लॉक)
  • ├── Hero
  • ├── लेख ब्लॉक ×3
  • ├── CTA
  • └── पाद लेख (लॉक)

प्रत्येक बच्चा एक ब्लॉक है; प्रत्येक ब्लॉक घटकों से बना है। लेख ब्लॉक को एक बार बदलें और इस टेम्पलेट से बनाया गया प्रत्येक न्यूज़लेटर अगली बार खोलने पर इसे उठाता है।

रेलिंग

उपयोगकर्ताओं को टेम्पलेट को तोड़ने की अनुमति दिए बिना स्वतंत्रता दें

GrapesJS में लॉक करना एक मोड या योजना स्तर नहीं है - यह एक घटक परिभाषा पर विकल्पों का एक सेट है। एक बंद क्षेत्र अभी भी प्रस्तुत करता है, अभी भी निर्यात करता है, और बस संपादक में खींचने, हटाने या फिर से स्टाइल करने से इनकार करता है।

कंपनी हेडर

बंद

हर ईमेल में मौजूद, हर ईमेल में समान। किसी को भी इसे स्थानांतरित करने की आवश्यकता नहीं है।

संपादन योग्य सामग्री

संपादन योग्य

पाठ और चित्र प्रेषक वास्तव में लिखने के लिए यहां है।

कार्यवाई के लिए बुलावा

संपादन योग्य

संपादन योग्य लेबल और लिंक, और रंगों की एक छोटी सूची - नीचे मार्कअप नहीं।

कानूनी पाद लेख

बंद

प्रेषक की पहचान और सदस्यता समाप्त करें लिंक। एक दायित्व, डिजाइन निर्णय नहीं।

विकल्प जो इसे उत्पन्न करते हैं

कंपनी हेडर
removable: false, draggable: false
संपादन योग्य सामग्री
editable: true
कार्यवाई के लिए बुलावा
stylable: ['background-color', 'color']
कानूनी पाद लेख
removable: false, copyable: false

यह आपको क्या खरीदता है

  • हर भेजने पर समीक्षा चरण के बिना ब्रांड-सुरक्षित संपादन
  • अनुपालन सामग्री जिसे गलती से हटाया नहीं जा सकता
  • एक छोटा Style Manager, जो एक सरल भी है UI
  • स्वीकृत ब्लॉक जो हर टेम्पलेट में समान व्यवहार करते हैं
  • ड्राफ़्ट को छुए बिना साझा अनुभागों में केंद्रीय परिवर्तन
नियंत्रित नो-कोड पैटर्न देखें

ये विकल्प संपादक UI को नियंत्रित करते हैं। वे प्राधिकरण नहीं हैं। आपके सेव एंडपॉइंट पर सीधे पोस्ट किया गया एक संशोधित प्रोजेक्ट केवल वही है जो आपका सर्वर मान्य करता है - इसलिए हर बार बैकएंड पर संरचना, आवश्यक क्षेत्रों और अनुमत फ़ील्ड को मान्य करें।

निजीकरण

डायनेमिक ईमेल सामग्री बनाएँ

वैयक्तिकृत ईमेल दो अलग-अलग समस्याएं हैं: उपयोगकर्ता को सिंटैक्स जाने बिना प्लेसहोल्डर रखने की अनुमति देना, और भेजने के समय वास्तविक डेटा के खिलाफ उस प्लेसहोल्डर को हल करना। संपादक पहले वाले को हल करता है। केवल आपका एप्लिकेशन ही दूसरे को हल कर सकता है।

टेम्पलेट में टैग मर्ज करें

  • {{first_name}}
  • {{company_name}}
  • {{order.total}}
  • {{unsubscribe_url}}

जहां तक संपादक का सवाल है, ये सामान्य पाठ हैं। वे बिल्कुल लिखित रूप में संग्रहीत होते हैं और जीवित रहते हैं, सहेजते हैं, फिर से खोलते हैं और अछूते निर्यात करते हैं।

उपयोगकर्ता उन्हें कैसे सम्मिलित करते हैं

उपलब्ध फ़ील्ड को अपने टेक्स्ट घटक पर एक विशेषता के रूप में प्रदर्शित करें — "पहला नाम", "कंपनी", "ऑर्डर टोटल" का ड्रॉपडाउन — और टोकन को स्वयं सामग्री में लिखें. उपयोगकर्ता एक फ़ील्ड चुनते हैं; वे कभी भी सिंटैक्स नहीं सीखते हैं, और वे एक ऐसे टैग का आविष्कार नहीं कर सकते हैं जिसे आपका रेंडरर नहीं जानता है.

गतिशील ब्लॉक

एक ब्लॉक उस सामग्री के लिए एक प्लेसहोल्डर हो सकता है जो अभी तक मौजूद नहीं है। उपयोगकर्ता एक उत्पाद कार्ड में ड्रॉप करता है और कॉन्फ़िगर करता है कि उसे कौन से उत्पाद दिखाने चाहिए; ईमेल रेंडर होने पर मान आते हैं।

  1. 1उपयोगकर्ता एक उत्पाद कार्ड रखता है
  2. 2आपका बैकएंड भेजने के समय कैटलॉग से पूछताछ करता है
  3. 3नाम, मूल्य, छवि और URL भरे जाते हैं
  4. 4प्रदान किया गया HTML आपके प्रदाता के पास जाता है

GrapesJS संपादन अनुभव प्रदान करता है। आपका बैकएंड गतिशील डेटा को हल करता है और ईमेल रेंडर या भेजे जाने पर टैग मर्ज करता है।

पूर्वसमीक्षा

भेजने से पहले ईमेल का पूर्वावलोकन करें

दो चौड़ाई लगभग सभी डिज़ाइन समीक्षा को कवर करती हैं: ईमेल जिस चौड़ाई पर लिखा गया है, और एक फोन। दोनों संपादक में एक डिवाइस स्विच दूर हैं, और न ही परीक्षण के रूप में एक ही बात है।

डेस्कटॉप600pxसंलेखन चौड़ाई। लगभग हर ईमेल टेम्पलेट 600px पर बनाया गया है।
मोबाइल375pxजहां अधिकांश मेल वास्तव में खोले जाते हैं। स्टैक्ड ऑर्डर और टैप किए गए लक्ष्यों की जाँच करें।

वर्कफ़्लो जो वास्तव में समस्याओं को पकड़ता है

  1. 1संपादक में पूर्वावलोकनडिवाइस स्विच करें, छवियों को टॉगल करें, और फ़ॉलबैक फ़ॉन्ट के साथ ईमेल पढ़ें। यह सेकंड में संरचना और पदानुक्रम की समस्याओं को पकड़ लेता है।
  2. 2आउटपुट का निरीक्षण करेंकिसी भी चीज़ के लिए जेनरेट किए गए मार्कअप को पढ़ें जो वहां नहीं होनी चाहिए - एक आवारा वर्ग, एक अप्रकाशित नियम, एक लापता वैकल्पिक विशेषता।
  3. 3बीज सूची में भेजेंआपके दर्शक जिन ग्राहकों का उपयोग करते हैं, उन पर वास्तविक खाते। यह एकमात्र चरण है जो आपको दिखाता है कि प्राप्तकर्ता क्या देखते हैं।
  4. 4एक रेंडरिंग सेवा जोड़ें यदि यह अपना स्थान अर्जित करता हैतृतीय-पक्ष सेवाएं एक साथ कई ग्राहकों में एक टेम्पलेट का स्क्रीनशॉट लेती हैं। इसके लायक है जब आप अक्सर टेम्प्लेट शिप करते हैं कि एक बीज सूची अड़चन बन जाती है।

एक इन-एडिटर पूर्वावलोकन आपका ब्राउज़र है जो कैनवास मार्कअप को प्रस्तुत करता है। एक मेल क्लाइंट अपने स्वयं के इंजन के माध्यम से उस मार्कअप के एक रूपांतरित संस्करण को प्रस्तुत करता है, और दोनों भिन्न हो सकते हैं। पूर्वावलोकन डिजाइन समीक्षा के लिए है; एक बीज सूची या एक प्रतिपादन सेवा संगतता के लिए है।

मान्यता

भेजने से पहले सत्यापित करें

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

सामग्री

क्या ईमेल पूरा हो गया है?

इससे पहले कि कोई टेम्पलेट ड्राफ़्ट से बाहर निकल सके, चलाएँ.

  • विषय पंक्ति और प्रीहेडर मौजूद हैं
  • हर छवि में alt text होता है
  • प्रत्येक छवि URL पूर्ण और सार्वजनिक रूप से उपलब्ध है
  • टेम्पलेट से कोई प्लेसहोल्डर प्रतिलिपि नहीं बची है
  • परियोजना में आवश्यक क्षेत्र अभी भी मौजूद हैं
लिंक

क्या सब कुछ हल हो जाता है?

स्वचालित करने के लिए सस्ता, और सबसे आम एकल विफलता।

  • प्रत्येक href पूर्ण है और सफलता की स्थिति देता है
  • कोई mailto या tel typos नहीं
  • ट्रैकिंग पैरामीटर लगातार लागू होते हैं
  • प्रत्येक मर्ज टैग उस फ़ील्ड से मेल खाता है जिसे आपका रेंडरर जानता है
  • रेंडर किए गए आउटपुट में कोई टैग अनसुलझा नहीं छोड़ा गया
अनुपालन

क्या भेजना कानूनी है?

गैर-परक्राम्य, इसलिए इसे चेकलिस्ट के बजाय कोड में लागू करें।

  • अनसब्सक्राइब लिंक वर्तमान और कार्यात्मक
  • प्रेषक की पहचान और डाक पता मौजूद है
  • इस प्रेषण पर प्राप्तकर्ताओं के लिए दर्ज की गई सहमति
  • सहेजे गए प्रोजेक्ट में लॉक किया गया कानूनी पाद लेख बरकरार है
  • आउटपुट को सैनिटाइज किया जाता है यदि इसका कोई हिस्सा उपयोगकर्ता इनपुट से आया है
दृढ़ता

ईमेल प्रोजेक्ट सहेजें और पुनर्स्थापित करें

Storage Manager एक इंटरफ़ेस है, डेटाबेस नहीं। इसे अपने स्वयं के API के खिलाफ लागू करें और संपादक आपके द्वारा नियंत्रित समापन बिंदुओं के माध्यम से लोड, ऑटोसेव और पुनर्स्थापित करता है - जो वह बिंदु है जिस पर ड्राफ्ट, संस्करण और अनुमोदन बिल्कुल संभव हो जाते हैं।

आपका बैकएंड जिस जीवनचक्र को परिभाषित करता है

  1. संपादित करें
  2. स्वतः सेव
  3. ड्राफ्ट
  4. विवरण
  5. स्वीकृत
  6. प्रकाशित
storage-adapter.tsJS
// The editor hands you project JSON; your backend decides
// what a draft, a version and an approved template mean.
editor.Storage.add('email-api', {
  async load({ templateId }) {
    const res = await fetch(`/api/email-templates/${templateId}`);
    return res.json();               // -> project JSON
  },
  async store(data, { templateId }) {
    await fetch(`/api/email-templates/${templateId}`, {
      method: 'PUT',
      headers: { 'Content-Type': 'application/json' },
      // Authorization is enforced server-side. Never trust this call.
      body: JSON.stringify({ project: data }),
    });
  },
});

ऑटोसेव को टाइमर के बजाय परिवर्तनों की संख्या से थ्रॉटल किया जाता है, इसलिए संपादनों के एक विस्फोट के लिए अभी भी एक अनुरोध की लागत होती है। संस्करणों को परियोजना की अपरिवर्तनीय प्रतियों के रूप में रखें JSON - एक संशोधन को पुनर्स्थापित करने में एक भार के अलावा कुछ भी खर्च नहीं होता है, और एक खराब संपादन एक घटना बनना बंद हो जाता है।

वितरण

अपने मौजूदा ईमेल इन्फ्रास्ट्रक्चर को कनेक्ट करें

इस आर्किटेक्चर के बारे में कुछ भी आपको मेल भेजने के तरीके को बदलने के लिए नहीं कहता है। संपादक एक दस्तावेज़ तैयार करता है; आपका बैकएंड इसे प्रस्तुत करता है और इसे उस प्रदाता को सौंप देता है जिसके लिए आप पहले से ही भुगतान करते हैं।

  1. 01

    GrapesJS

    परियोजना का उत्पादन करता है और, अनुरोध पर, मार्कअप। प्राप्तकर्ताओं के बारे में कुछ नहीं जानता।

  2. 02

    HTML / MJML

    संग्रहीत परियोजना से मांग पर उत्पन्न, शैलियों के साथ इनलाइन या MJML संकलित।

  3. 03

    आपका बैकएंड

    मर्ज टैग का समाधान करता है, आउटपुट को मान्य करता है, अभियान रिकॉर्ड करता है, प्रदाता को कॉल करता है।

  4. 04

    आपका प्रदाता

    मेल वितरित करता है और बाउंस, शिकायतों, खुलता है और आपको वापस क्लिक करता है।

आपके बैकएंड पोस्ट के उदाहरण

  • Mailgun
  • Postmark
  • SendGrid

अंतिम हॉप के चित्रण के रूप में वर्णानुक्रम में सूचीबद्ध। HTTP API या SMTP समापन बिंदु वाला कोई भी प्रदाता एक ही आकार में फिट बैठता है, और एक को दूसरे के लिए स्वैप करना संपादक को नहीं छूता है।

GrapesJS संपादक है, आपकी ईमेल डिलीवरी सेवा नहीं।

न तो GrapesJS और न ही GJS.Market ऊपर नामित किसी भी प्रदाता के साथ एकीकरण भेजता है, और कोई साझेदारी निहित नहीं है। सुपुर्दगी, प्रमाणीकरण और दमन प्रबंधन आपके प्रदाता और आपके एप्लिकेशन की जिम्मेदारी बनी हुई है।

send-campaign.tsts
// Server side. GrapesJS is not in this file — and that is the point.
const template = await db.emailTemplates.find(templateId);

// 1. Your application resolves merge tags. The editor never does.
const html = renderMergeTags(template.html, {
  first_name: user.firstName,
  unsubscribe_url: unsubscribeUrlFor(user),
});

// 2. Your ESP delivers it. Swap the client, keep the editor.
await esp.send({ to: user.email, subject: template.subject, html });
बक्सों का इस्तेमाल करें

आप क्या बना सकते हैं?

एक ही संपादन परत, आठ अलग-अलग तरीकों से पैक की गई। उनके बीच क्या परिवर्तन होता है कि कौन संपादन करता है, उन्हें क्या बदलने की अनुमति है, और आउटपुट कहां जाता है।

SaaS ईमेल बिल्डर

ग्राहकों को आपके उत्पाद के अंदर उन टेम्पलेट्स और ब्लॉकों के विरुद्ध जीवनचक्र और अभियान ईमेल डिज़ाइन करने दें, जिन्हें आप प्रति योजना नियंत्रित करते हैं.

SaaS बिल्डर आर्किटेक्चर

न्यूज़लेटर बिल्डर

एक मार्केटिंग टीम को एक आवर्ती प्रारूप के लिए एक दृश्य संपादक दें, जिसमें एक लेख ब्लॉक होता है जो हर मुद्दे को सुसंगत रखता है।

न्यूज़लेटर प्लगइन्स

मार्केटिंग ऑटोमेशन बिल्डर

उन ईमेल को लिखें जो अभियानों और वर्कफ़्लो के अंदर बैठते हैं, उन लैंडिंग पृष्ठों के साथ ब्लॉक साझा करते हैं जिन्हें वे इंगित करते हैं।

लैंडिंग पेज बिल्डर

लेन-देन ईमेल संपादक

रसीदों और सूचनाओं के लिए कसकर नियंत्रित टेम्पलेट - ज्यादातर लॉक, एक छोटे संपादन योग्य मध्य के साथ।

टेम्पलेट सिस्टम

CMS ईमेल संपादक

सामग्री टीमों को उन ब्लॉकों का पुनः उपयोग करने दें जिनके साथ वे पहले से ही वेब सामग्री लिखते हैं, बाकी सामग्री मॉडल के बगल में संग्रहीत हैं।

हेडलेस CMS संपादन

एजेंसी ईमेल बिल्डर

एक संपादक, प्रति ग्राहक एक ब्रांडेड ब्लॉक सेट, और टेम्पलेट जिन्हें समीक्षाओं के बीच आकार से बाहर नहीं निकाला जा सकता है।

व्हाइट-लेबल बिल्डर्स

आंतरिक ईमेल उपकरण

आंतरिक टीमों को एक साझा HTML फ़ाइल और एक अनुरोध कतार के बजाय एक नियंत्रित संपादक दें।

डेवलपर्स के लिए नो-कोड

व्हाइट-लेबल ईमेल बिल्डर

संपादक को अपने उत्पाद के हिस्से की तरह दिखें और व्यवहार करें, पैनल, आइकन और भाषा तक।

संपादक को व्हाइट-लेबल करें
बिल्ड बनाम एडॉप्ट

क्या आपको स्क्रैच से एक ईमेल संपादक बनाना चाहिए?

निर्णय नहीं, दायरा जांच। प्रत्येक पंक्ति एक ईमेल बिल्डर की आवश्यकता है। बायां कॉलम वह काम है जो आपके पास होगा; दाईं ओर वह है जो GrapesJS आपको एक घटक लिखने से पहले देता है।

योग्‍यताखरोंच सेGrapesJS के साथ
दृश्य कैनवासइसे बनाओसुलभ
खींचें और छोड़ेंइसे बनाओसुलभ
घटक मॉडलइसे बनाओसुलभ
ब्लॉक लाइब्रेरीइसे बनाओएक्स्टेंसिबल
शैली संपादनइसे बनाओसुलभ
परत का पेड़इसे बनाओसुलभ
पूर्ववत करें / फिर से करेंइसे बनाओसुलभ
संपत्ति प्रबंधनइसे बनाओसुलभ
भंडारण एकीकरणइसे बनाओकॉन्फ़िगर करने योग्य
कस्टम घटकइसे बनाओसमर्थित
प्लगइन आर्किटेक्चरइसे बनाओसमर्थित

"उपलब्ध" का अर्थ है क्षमता कोर के साथ जहाज और कॉन्फ़िगरेशन की आवश्यकता है, निर्माण की नहीं। इसका मतलब यह नहीं है कि इसे किसी काम की आवश्यकता नहीं है: प्रत्येक गंभीर ईमेल बिल्डर अपने स्वयं के घटकों को परिभाषित करता है, अपनी शैलियों को प्रतिबंधित करता है और अपना स्वयं का स्टोरेज एडाप्टर लिखता है। grapesjs 0.23.6 के विरुद्ध 2026-09-03 पर सत्यापित किया गया।

अपना ईमेल उत्पाद बनाएं, न कि किसी अन्य संपादक इंजन का।

बाज़ार

प्लगइन्स के साथ अपने ईमेल बिल्डर का विस्तार करें

GJS.Market कैटलॉग से वास्तविक लिस्टिंग, जिस निर्माण से संबंधित हैं, उसके चरण के आधार पर समूहीकृत की जाती है। नाम, कीमतें और छवियां सीधे बाज़ार से आती हैं, इसलिए आप यहां जो देख रहे हैं वह वास्तव में आज बिक्री के लिए है।

टेम्पलेट्स

शुरुआती बिंदुओं की एक लाइब्रेरी, इसलिए कोई भी खाली कैनवास से ईमेल शुरू नहीं करता है।

श्रेणी ब्राउज़ करें

ईमेल प्राप्त करना

तैयार दस्तावेज़ को हैंडऑफ़, समीक्षा या किसी मौजूदा बिल्ड पाइपलाइन के लिए निर्यात करें.

श्रेणी ब्राउज़ करें

इस पृष्ठ पर कुछ क्षमताओं के पीछे कोई प्लगइन नहीं है, और यह खंड एक का आविष्कार नहीं करेगा: कोई पूर्वावलोकन या स्पैम-चेक उत्पाद नहीं है, कोई CSS-इनलाइनर उत्पाद नहीं है, कोई मर्ज-टैग उत्पाद नहीं है और कैटलॉग में कोई तैयार ईमेल-टेम्पलेट उत्पाद नहीं है। उन्हें यहां लागू करने के लिए पैटर्न के रूप में वर्णित किया गया है, या हमारी टीम आपके साथ काम कर सकती है।

ढेर

अपना ईमेल बिल्डर स्टैक बनाएं

चार बिल्ड, केवल उन लिस्टिंग से इकट्ठे होते हैं जो आज मौजूद हैं। उस पंक्ति से शुरू करें जो आप जो शिपिंग कर रहे हैं उससे मेल खाती है और जब वह अपना स्थान अर्जित कर ले तो अगली परत जोड़ें।

विपणन मंच

एक मार्केटिंग टीम का संपादक: ब्लॉक, टेम्पलेट और होस्ट की गई संपत्तियां जो मसौदे से आगे निकल जाती हैं।

अभियान वर्कफ़्लो देखें

कीमतें निर्माण समय पर लाइव कैटलॉग से आती हैं। निःशुल्क लिस्टिंग चिह्नित हैं; भुगतान किए गए सीधे उनके उत्पाद पृष्ठ पर लिंक करते हैं।

जल्दी शुरू

5 चरणों में ड्रैग-एंड-ड्रॉप ईमेल बिल्डर बनाएं

काम का आकार, क्रम में यह करने के लिए समझ में आता है। प्रत्येक चरण उस गाइड से जुड़ता है जो इसे ठीक से कवर करता है - यह पृष्ठ एक नक्शा है, ट्यूटोरियल नहीं।

  1. 1

    संपादक को प्रारंभ करें

    एक कंटेनर पर GrapesJS माउंट करें, दो डिवाइस ईमेल की जरूरतों को सेट करें, और किसी भी अन्य चीज़ से पहले डिफ़ॉल्ट स्थानीय संग्रहण को बंद करें।

    GrapesJS सेटअप गाइड
  2. 2

    ईमेल घटकों को परिभाषित करें

    उन तालिका-आधारित घटकों को लिखें जिनसे आपके ईमेल बने हैं, जो स्टाइल किया जा सकता है उसे प्रतिबंधित करें, और प्रत्येक को एक ब्लॉक के रूप में उजागर करें।

    घटकों को गहराई से ईमेल करें
  3. 3

    टेम्पलेट जोड़ें

    उपयोगकर्ताओं को शुरू करने के लिए कहीं दें। टेम्प्लेट को प्रोजेक्ट JSON के रूप में स्टोर करें और मूल को संपादित करने के बजाय उपयोग पर क्लोन करें।

    टेम्पलेट सिस्टम
  4. 4

    प्रोजेक्ट स्टोर करें

    अपने API के खिलाफ एक स्टोरेज एडाप्टर लागू करें ताकि ड्राफ्ट, autosave और संस्करण परिभाषित करने के लिए आपके हों।

    भंडारण प्लगइन्स
  5. 5

    रेंडर करें और भेजें

    भेजें पर मार्कअप जनरेट करें, मर्ज टैग सर्वर-साइड को हल करें, और परिणाम अपने प्रदाता को सौंपें।

    निर्माण के साथ सहायता प्राप्त करें
email-editor.tsts
import grapesjs from 'grapesjs';
import newsletter from 'grapesjs-preset-newsletter';

const editor = grapesjs.init({
  container: '#email-editor',
  height: '100%',
  // Email is authored at a fixed width; give users one extra viewport
  // to check, not a full responsive breakpoint set.
  deviceManager: {
    devices: [
      { id: 'desktop', name: 'Desktop', width: '' },
      { id: 'mobile', name: 'Mobile', width: '375px' },
    ],
  },
  // Curated blocks only: the preset's table sections, plus your own.
  plugins: [
    (ed) => newsletter(ed, { inlineCss: true, showBlocksOnLoad: true }),
  ],
  // Point the editor at your API rather than the browser's localStorage.
  storageManager: {
    type: 'remote',
    autosave: true,
    stepsBeforeSave: 10,
  },
});
email-button.tsts
// An email-safe button: users edit the label and the link,
// never the table markup that makes it render in Outlook.
editor.DomComponents.addType('email-button', {
  isComponent: (el) => el.dataset?.type === 'email-button',
  model: {
    defaults: {
      draggable: '[data-gjs-type="cell"], td',
      // Users may recolour it; they may not restyle it into a div.
      stylable: ['background-color', 'color', 'border-radius'],
      traits: [
        { name: 'href', label: 'Link' },
        { name: 'label', label: 'Button text' },
      ],
      components: `
        <table role="presentation" cellpadding="0" cellspacing="0">
          <tr><td><a href="#">Read the update</a></td></tr>
        </table>`,
    },
  },
});

दोनों नमूने grapesjs 0.23.6 के खिलाफ चलते हैं। 'अंगूरजेएस-प्रीसेट-न्यूज़लेटर' और 'अंगूरजेएस-एमजेएमएल' अलग-अलग BSD-3-Clause पैकेज हैं - कोर शिप कोई ईमेल प्रीसेट नहीं है - इसलिए जो भी आपके द्वारा ऊपर चुने गए आउटपुट स्वरूप से मेल खाता है उसे स्थापित करें।

लॉन्च से पहले

उत्पादन चेकलिस्ट

एक कार्यशील डेमो को एक ईमेल बिल्डर से क्या अलग करता है जिसे आप ग्राहकों को सौंप सकते हैं। यहां सब कुछ आपका काम है, संपादक का नहीं।

Editor

संपादन अनुभव

उपयोगकर्ता क्या कर सकते हैं और क्या नहीं।

  • क्यूरेटेड ब्लॉक लाइब्रेरी, डिफ़ॉल्ट सेट नहीं
  • प्रतिबंधित शैलियों के साथ ईमेल-सुरक्षित घटक
  • दोनों डिवाइस चौड़ाई पर उत्तरदायी संपादन
  • रिक्त स्थिति से उपलब्ध टेम्पलेट
  • लॉक किए गए हेडर, पाद लेख और कानूनी क्षेत्र
डाटा

दृढ़ता

उपयोगकर्ता द्वारा बनाई गई कुछ भी खोने योग्य नहीं होनी चाहिए।

  • परियोजना JSON आपके अपने API के माध्यम से बनी रही
  • परिवर्तन गणना द्वारा थ्रॉटल किया गया ऑटोसेव
  • पुनर्स्थापना के साथ अपरिवर्तनीय संस्करण इतिहास
  • टेम्पलेट स्टोर को कवर करने वाले बैकअप
  • एक पुरानी परियोजना को फिर से खोलने के लिए एक परीक्षण किया गया मार्ग
उत्पादन

सिस्टम क्या छोड़ता है

सर्वर पर हर बार मान्य किया जाता है।

  • HTML या MJML आउटपुट भेजने से पहले मान्य किया गया
  • हर लिंक की जाँच की और निरपेक्ष
  • हर मर्ज टैग हल करने योग्य
  • प्रत्येक छवि URL सार्वजनिक और स्थायी
  • उपयोगकर्ता द्वारा आपूर्ति की गई HTML स्वच्छ
ईमेल

सुपुर्दगी और कानून

वे हिस्से जो डिजाइन के बारे में नहीं हैं।

  • आपके दर्शकों द्वारा उपयोग किए जाने वाले ग्राहकों पर परीक्षण किया गया
  • एक फोन पर चेक किया गया, न कि केवल एक डेस्कटॉप
  • हर भेजने पर सदस्यता समाप्त करना
  • पाद लेख में प्रेषक की पहचान और पता
  • ट्रैकिंग और सहमति के अनुसार क्षेत्राधिकार के अनुसार संभाला जाता है
प्रतिभूति

जहां ईमेल बिल्डरों से समझौता किया जाता है

एक ईमेल बिल्डर उपयोगकर्ता-लिखित मार्कअप स्वीकार करता है और इसे तीसरे पक्ष को भेजता है। वह संयोजन एक विशिष्ट CRUD सुविधा की तुलना में अधिक देखभाल का हकदार है।

  • जोखिम

    संपादक के प्रतिबंधों पर भरोसा करना

    लॉक किए गए क्षेत्र, प्रतिबंधित शैलियाँ और छिपे हुए ब्लॉक ब्राउज़र में रहते हैं। एक तैयार किया गया अनुरोध अपनी पसंद का कोई भी प्रोजेक्ट पोस्ट कर सकता है।

    क्या करना है

    सर्वर पर सहेजे गए प्रोजेक्ट को मान्य करें: आवश्यक क्षेत्र मौजूद, एक अनुमति सूची पर घटक प्रकार, सीमा के भीतर फ़ील्ड।

  • जोखिम

    अस्वच्छ कस्टम कोड भेजना

    कोड-एम्बेड घटक एक सुविधा अनुरोध है जो प्रत्येक ईमेल बिल्डर पर आता है, और यह आपके ग्राहकों के इनबॉक्स पर इंगित एक इंजेक्शन सतह है।

    क्या करना है

    संग्रहीत मार्कअप को सैनिटाइज़ करें और रेंडर पर फिर से सैनिटाइज़ करें। प्रतिबंधित करें कि कोड घटक का उपयोग कौन कर सकता है, और इसके प्रत्येक उपयोग को लॉग करें।

  • जोखिम

    किसी भी अपलोड की गई फ़ाइल को स्वीकार करना

    किसी संपादक से किए गए अपलोड सार्वजनिक URL पर समाप्त होते हैं जो ईमेल के रूप में लंबे समय तक जीवित रहते हैं।

    क्या करना है

    सर्वर पर प्रकार और आकार को मान्य करें, छवियों को फिर से एन्कोड करें, और एक ऐसे डोमेन से संपत्ति परोसें जिसमें कोई सत्र कुकीज़ नहीं है।

  • जोखिम

    भेजें समापन बिंदु को अंडर-संरक्षित छोड़ना

    प्रतिपादन और भेजना महंगे, अपरिवर्तनीय संचालन हैं। वे आमतौर पर संपादक मार्ग की तुलना में कम सावधानी से संरक्षित होते हैं।

    क्या करना है

    प्रति टेम्पलेट और प्रति प्राप्तकर्ता सूची को अधिकृत करें, दर-सीमा भेजती है, और कुछ भी पूर्ण दर्शकों के पास जाने से पहले दूसरी जांच की आवश्यकता होती है।

  • जोखिम

    जो कुछ भी दायरे में है उसके खिलाफ मर्ज टैग को हल करना

    एक अनुमेय टेम्पलेट रेंडरर खुशी-खुशी एक ऐसे क्षेत्र को प्रक्षेपित करेगा जिसे प्रेषक को कभी नहीं देखना चाहिए था।

    क्या करना है

    उस टेम्पलेट के लिए फ़ील्ड्स की एक स्पष्ट अनुमति सूची के विरुद्ध हल करें, और किसी अज्ञात टैग पर रेंडर को उत्सर्जित करने के बजाय विफल करें।

प्रदर्शन

ईमेल बिल्डर को तेज़ रखें

संपादक आपके एप्लिकेशन के अंदर रहने वाली एक बड़ी निर्भरता है। ये ऐसे लीवर हैं जो मायने रखते हैं, जिस क्रम में वे आमतौर पर भुगतान करते हैं।

  • संपादक को आलस्य से लोड करें

    इसे केवल उस मार्ग पर आयात करें जो ईमेल को संपादित करता है, और केवल ब्राउज़र में। संपादक के बारे में कुछ भी सर्वर रेंडर या आपके मुख्य बंडल में नहीं है।

  • आलसी-लोड वैकल्पिक प्लगइन्स

    एक कोड व्यूअर, एक छवि संपादक या एक MJML कंपाइलर तब आ सकता है जब उपयोगकर्ता उस पैनल को खोलता है।

  • ब्लॉक लाइब्रेरी को छोटा रखें

    प्रत्येक ब्लॉक को स्टार्टअप पर पार्स किया जाता है और पैलेट में प्रदान किया गया एक कार्ड होता है। एक क्यूरेटेड सेट तेज होने के साथ-साथ सुरक्षित भी होता है।

  • डिबाउंस autosave

    कीस्ट्रोक के बजाय परिवर्तन गणना द्वारा थ्रॉटल करें, इसलिए टाइपिंग का एक विस्फोट तीस के बजाय एक अनुरोध उत्पन्न करता है।

  • प्रोजेक्ट डेटा को कम रखें

    URL द्वारा संदर्भ संपत्तियां। प्रोजेक्ट JSON के अंदर बेस 64 छवियां हर लोड, सेव और वर्जन कॉपी को भारी बनाती हैं।

  • कस्टम घटक देखें

    Component तर्क जो हर परिवर्तन पर चलता है, एक कैनवास का सामान्य कारण है जो लंबे ईमेल पर सुस्त महसूस करता है।

जानबूझकर यहां कोई आंकड़ा उद्धृत नहीं किया गया है: संख्याएं आपकी ब्लॉक गणना, आपके घटक तर्क और आपके उपयोगकर्ताओं के हार्डवेयर पर निर्भर करती हैं। प्रत्येक परिवर्तन से पहले और बाद में अपने स्वयं के एप्लिकेशन में संपादक मार्ग को मापें।

निर्णय

स्व-होस्टेड ईमेल बिल्डर बनाम होस्टेड प्लेटफॉर्म

अब जब वास्तुकला स्पष्ट हो गई है, तो व्यापार-बंद को बताना आसान है। एक होस्टेड बिल्डर को ग्राहक के सामने रखना तेज़ होता है; आपके पास एक बिल्डर आपके उत्पाद की निर्भरता के बजाय उसकी एक विशेषता है।

होस्ट किया गया ईमेल बिल्डर प्लेटफॉर्म

एक विक्रेता द्वारा संचालित एक एम्बेड करने योग्य संपादक, उनके API और उनके UI के माध्यम से एकीकृत।

आपको क्या मिलता है

  • विक्रेता द्वारा संचालित बुनियादी ढांचा
  • डेटा निवास और प्रतिधारण प्रदाता पर निर्भर करता है
  • UI अनुकूलन उत्पाद और योजना के अनुसार भिन्न होता है
  • कस्टम घटक उत्पाद और योजना के अनुसार भिन्न होते हैं
  • ब्रांडिंग उस योजना पर निर्भर करती है जिस पर आप हैं
  • विक्रेता के API के माध्यम से बैकएंड एकीकरण
  • भेजना प्लेटफ़ॉर्म के मॉडल पर निर्भर करता है
  • संपादक आपके उत्पाद के अंदर एक बाहरी उपकरण बना रहता है

एक कार्यशील संपादक के लिए सबसे तेज़ मार्ग, रोडमैप और किसी और के स्वामित्व वाले मूल्य निर्धारण के साथ।

होस्ट किए गए विक्रेता के साथ तुलना करें

आपका GrapesJS-आधारित बिल्डर

एक ओपन-सोर्स संपादन परत जिसे आप अपने स्वयं के एप्लिकेशन के हिस्से के रूप में कॉन्फ़िगर, विस्तारित और परिनियोजित करते हैं।

आपको क्या मिलता है

  • बुनियादी ढांचा आपका है, जहां भी आप पहले से चल रहे हैं
  • डेटा आपकी नीतियों के तहत आपके डेटाबेस में रहता है
  • UI आपका UI है, पैनल और भाषा तक
  • कस्टम घटक साधारण अनुप्रयोग कोड हैं
  • ब्रांडिंग वह है जो आपका उत्पाद दिखता है
  • बैकएंड एकीकरण आपका अपना आर्किटेक्चर है
  • भेजना उस प्रदाता के पास रहता है जिसका आप पहले से उपयोग कर रहे हैं
  • संपादक एक मूल सुविधा है, एम्बेडेड टूल नहीं

अधिक काम सामने है, और एक संपादक जो आपके उत्पाद के आसपास के बजाय बढ़ता है।

निर्माण शुरू करें

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

एकीकरण

अपने एप्लिकेशन स्टैक के साथ ईमेल बिल्डर का उपयोग करें

GrapesJS एक सादे DOM तत्व में बदल जाता है, इसलिए इसे एकीकृत करना यह सवाल है कि कौन सा जीवनचक्र हुक init को कॉल करता है और किसे नष्ट करता है। आपका ढांचा आपके एप्लिकेशन को शक्ति प्रदान करता है; GrapesJS विज़ुअल ईमेल संपादन परत को शक्ति प्रदान करता है।

GrapesJS ट्यूटोरियल से शुरू करें
FAQ

ड्रैग-एंड-ड्रॉप ईमेल बिल्डर प्रश्न

ड्रैग-एंड-ड्रॉप ईमेल बिल्डर क्या है?

एक विज़ुअल एडिटर जो किसी को पुनः प्रयोज्य घटकों से एक ईमेल इकट्ठा करने देता है - हेडर, टेक्स्ट, इमेज, बटन, पाद लेख - हस्त-लेखन टेबल मार्कअप और इनलाइन CSS के बजाय। ईमेल HTML के नियमों को एक बार एन्कोड किया जाता है, घटकों में, ईमेल लिखने वाले सभी लोगों द्वारा सीखा जाने के बजाय।

क्या मैं GrapesJS के साथ ड्रैग-एंड-ड्रॉप ईमेल बिल्डर बना सकता हूँ?

हाँ। GrapesJS कैनवास, ड्रैग-एंड-ड्रॉप, घटक मॉडल, ब्लॉक लाइब्रेरी, स्टाइल और ट्रेट पैनल, लेयर ट्री, पूर्ववत / फिर से करें और प्रोजेक्ट क्रमांकन की आपूर्ति करता है। आप ईमेल-सुरक्षित घटकों, टेम्प्लेट, स्टोरेज एडाप्टर और सेंड पाइपलाइन की आपूर्ति करते हैं।

क्या GrapesJS ईमेल संपादन का समर्थन करता है?

कोर एक सामान्य वेब बिल्डर फ्रेमवर्क है और कोई ईमेल प्रीसेट नहीं भेजता है। ईमेल समर्थन प्लगइन्स से आता है: grapesjs-preset-newsletter टेबल-आधारित ब्लॉक, एक ईमेल-उन्मुख Style Manager और एक CSS-इनलाइनिंग निर्यात कमांड जोड़ता है, और grapesjs-mjml MJML घटक जोड़ता है। दोनों अलग-अलग BSD-3-Clause पैकेज हैं।

क्या मैं MJML के साथ GrapesJS का उपयोग कर सकता हूँ?

हाँ, grapesjs-mjml प्लगइन के माध्यम से। यह MJML कंपाइलर के ब्राउज़र बिल्ड का उपयोग करके कैनवास में MJML घटकों को लाइव प्रस्तुत करता है। editor.runCommand('mjml-code') MJML स्रोत लौटाता है, और mjml-code-to-html इसे HTML में संकलित करता है।

क्या मैं HTML ईमेल निर्यात कर सकता हूँ?

हाँ। editor.getHtml() कैनवास मार्कअप लौटाता है, और न्यूज़लेटर प्रीसेट gjs-get-inlined-html जोड़ता है, जो HTML CSS इनलाइन के साथ लौटाता है - जो कि आप भेजना चाहते हैं। यदि आप उस स्टेप सर्वर-साइड को रखना चाहते हैं तो आप अपनी स्वयं की बैकएंड पाइपलाइन में भी इनलाइन कर सकते हैं।

क्या मैं अपने डेटाबेस में ईमेल टेम्पलेट्स स्टोर कर सकता हूं?

हाँ, और आपको करना चाहिए। Storage Manager एक इंटरफ़ेस है: अपने API के खिलाफ लोड और स्टोर लागू करें और संपादक आपके डेटाबेस में प्रोजेक्ट JSON बना रहता है। किसी भी तृतीय-पक्ष सेवा पर कुछ भी संग्रहीत नहीं किया जाता है जब तक कि आप इसे वहां रखना नहीं चुनते।

क्या मैं कस्टम ईमेल ब्लॉक बना सकता हूँ?

हाँ। तालिका मार्कअप, traits और अपने इच्छित शैली प्रतिबंधों के साथ एक घटक प्रकार को परिभाषित करें, फिर एक ब्लॉक पंजीकृत करें जो इसे सम्मिलित करता है। यह आपके पास मुख्य लीवर है जो उपयोगकर्ता उत्पादन कर सकते हैं, और यह साधारण एप्लिकेशन कोड है।

क्या मैं किसी ईमेल टेम्पलेट के कुछ हिस्सों को लॉक कर सकता हूँ?

हां, घटक विकल्पों के साथ जैसे removable: गलत, draggable: गलत, copyable: गलत और एक प्रतिबंधित stylable सूची। ध्यान रखें कि ये संपादक UI को नियंत्रित करते हैं - आपके सर्वर को अभी भी यह सत्यापित करना होगा कि सहेजे गए प्रोजेक्ट में वे क्षेत्र शामिल हैं जिन्हें शामिल करना आवश्यक है।

क्या मैं मर्ज टैग और डायनेमिक सामग्री का उपयोग कर सकता हूँ?

हाँ। संपादक {{first_name}} जैसे टैग को साधारण पाठ के रूप में मानता है और इसे अछूता संग्रहीत करता है, इसलिए आप उपयोगकर्ताओं को सिंटैक्स सीखने के बजाय एक विशेषता ड्रॉपडाउन के माध्यम से टैग रख सकते हैं। वास्तविक डेटा के खिलाफ उन टैग को हल करना आपके बैकएंड में रेंडर समय पर होता है - GrapesJS ऐसा नहीं करता है।

क्या मैं SendGrid, Mailgun या Postmark कनेक्ट कर सकता हूँ?

आपका बैकएंड आज की तरह ही कर सकता है: HTML उत्पन्न करें, मर्ज टैग को हल करें, प्रदाता के API को कॉल करें। GrapesJS उस अनुरोध पथ में नहीं है, और न तो GrapesJS और न ही GJS.Market उन प्रदाताओं में से किसी के साथ एकीकरण करता है।

क्या GrapesJS ईमेल भेजता है?

नहीं। यह एक संपादक है। डिलीवरी, बाउंस, शिकायतें, दमन सूची और सगाई की घटनाएं सभी आपके ईमेल सेवा प्रदाता से संबंधित हैं, और अभियान रिकॉर्ड और शेड्यूलिंग आपके आवेदन से संबंधित हैं।

क्या मैं React में बिल्डर का उपयोग कर सकता हूँ?

हाँ। संपादक को एक ref'd कंटेनर के खिलाफ एक प्रभाव में माउंट करें, उस कंटेनर को React के रेंडर पथ से बाहर रखें, और अनमाउंट पर उदाहरण को नष्ट करें। यदि आप मैन्युअल जीवनचक्र हैंडलिंग पर घटकों को पसंद करते हैं तो एक आधिकारिक React रैपर पैकेज है।

क्या मैं इसे Vue या Angular के साथ उपयोग कर सकता हूँ?

हाँ। GrapesJS एक सादे DOM तत्व में बदल जाता है, इसलिए एकीकरण आपके ढांचे के माउंट हुक से init को कॉल करने और इसके टियरडाउन हुक से नष्ट करने का मामला है। कोई आधिकारिक Vue या Angular आवरण नहीं है, और किसी की भी आवश्यकता नहीं है।

क्या मैं ईमेल बिल्डर को व्हाइट-लेबल कर सकता हूं?

हाँ। पैनल, बटन, आइकन, स्टाइलशीट और संपादक के अपने इंटरफ़ेस स्ट्रिंग्स सभी कॉन्फ़िगर करने योग्य हैं, इसलिए संपादक एम्बेडेड तृतीय-पक्ष टूल की तरह दिखने और पढ़ने के बजाय आपके उत्पाद के हिस्से की तरह दिख सकता है।

क्या मुझे स्क्रैच से एक ईमेल संपादक बनाना चाहिए?

केवल तभी जब संपादन इंजन स्वयं आपका उत्पाद हो। यदि आप जो बेच रहे हैं वह एक ईमेल उत्पाद है - टेम्पलेट्स, अभियान, वैयक्तिकरण, वितरण - तो कैनवास, ड्रैग-एंड-ड्रॉप और घटक मॉडल अविभाजित कार्य हैं, और मौजूदा इंजन को अपनाने से ग्राहकों द्वारा वास्तव में नोटिस किए जाने वाले भागों के लिए बजट छोड़ दिया जाता है।
सेवाएं

अपने ईमेल बिल्डर को बनाने में सहायता चाहिए?

यदि आप इस पर शोध करने के बजाय इसे काम करना चाहते हैं, तो हमारी टीम एक सेवा के रूप में GrapesJS-आधारित ईमेल संपादकों का निर्माण करती है - जिसमें इस पृष्ठ के वे हिस्से शामिल हैं जिनके पीछे कोई प्लगइन नहीं है।

  • GrapesJS मौजूदा एप्लिकेशन में एकीकरण
  • कस्टम ईमेल-सुरक्षित घटक
  • MJML एकीकरण और संकलन
  • क्यूरेटेड ब्लॉक लाइब्रेरी
  • भंडारण एडेप्टर और संस्करण इतिहास
  • टेम्पलेट सिस्टम और स्टार्टर लाइब्रेरी
  • टैग और डायनेमिक ब्लॉक मर्ज करें
  • व्हाइट-लेबल संपादक UI
  • कस्टम प्लगइन्स
  • प्रकाशन और अनुमोदन वर्कफ़्लोज़
GrapesJS विशेषज्ञ से बात करें
शुरू हो जाओ

अपना ईमेल बिल्डर बनाएं

अपने उपयोगकर्ताओं को अपनी विकास टीम को स्क्रैच से ईमेल संपादक बनाने के लिए मजबूर किए बिना ईमेल बनाने का एक दृश्य तरीका दें।

निर्माण

GrapesJS के साथ निर्माण शुरू करें

हमें बताएं कि संपादक को क्या करना है और एकीकरण के लिए एक स्कोप योजना प्राप्त करें।

निर्माण शुरू करें

आपके उपयोगकर्ता ईमेल बनाते हैं। आपका उत्पाद अनुभव का मालिक है।