मैंने व्यक्तिगत रूप से जिनमें से इस्तेमाल किया है, उनमें यह सबसे सुविधाजनक लगा और इसे विस्तार देना भी सबसे आसान लगा।
Slate से एडिटर बनाते समय जो असुविधाएँ महसूस हुई थीं, उनमें से बहुत-सी यहाँ सचमुच हल हो गईं।
क्या आप यह साझा कर सकते हैं कि Slate editor इस्तेमाल करते समय आपको किस तरह की असुविधाएँ हुईं?
मैंने तो सिर्फ़ Tiptap ही इस्तेमाल किया है, लेकिन Slate अच्छा है ऐसा सुना है, इसलिए मेरी इसमें दिलचस्पी बनी है!!
बाहरी components बनाने वाला हिस्सा कहीं ज़्यादा सुविधाजनक है। खासकर React जैसे मामलों में, जहाँ अपना खुद का DOM इस्तेमाल होता है, वहाँ HTML नहीं बल्कि component के रूप में rendering चाहिए होती है, और शुरू से ही modularization को ध्यान में रखकर बनाया गया tiptap संशोधित करना ज़्यादा आसान लगा।
कुल मिलाकर मुझे Slate के दस्तावेज़ समझने में कठिन लगे, और वह इतने raw थे कि जिन फीचर्स को मैं बनाना चाहता था, उनके लिए मुझे लगा कि सीखने के लिए और भी बहुत कुछ है.
यह लगभग 2 साल पहले की याद है, इसलिए थोड़ा अलग हो सकता है, लेकिन मुझे ऐसी समस्याओं का सामना करना पड़ा था.
मोबाइल वातावरण में Hangul इनपुट की समस्या: यह कहाँ हो रही थी, इसका पता लगाना बहुत मुश्किल था; कस्टमाइज़ करते समय हुई थी, इसलिए ठीक से याद नहीं है.
select से जुड़े कंट्रोल की कठिनाई: चुने गए अक्षरों पर attributes प्रोसेस करने वाला फीचर जोड़ना बहुत जटिल था. (ऑब्जेक्ट खुद ही जटिल है)
प्लगइन डेवलपमेंट की कठिनाई: मैंने map आदि के प्लगइन खुद बनाने की कोशिश की थी, लेकिन tiptap इस तरह बनाया गया था कि अतिरिक्त प्लगइन डेवलप करना आसान और सुविधाजनक था.
व्यक्तिगत रूप से मुझे लगता है कि इसकी documentation काफ़ी अच्छी है, लेकिन बीच-बीच में paid subscription की ज़रूरत वाले elements भी मिले-जुले हैं.
दस्तावेज़ पढ़ने में यह इतना असुविधाजनक नहीं है, लेकिन ज़रूरत भी नहीं है फिर भी खरीदने का मन करा देते हैं—इस लिहाज़ से कमाल भी है और थोड़ा खीझ दिलाने वाला भी.. काफ़ी mixed feelings हैं.
दस्तावेज़ीकरण काफ़ी अच्छा है, इस बात से सहमत होना मेरे लिए मुश्किल है। मुझे लगता है कि getting started docs और API docs के बीच का अंतर बहुत बड़ा है, इसलिए learning curve ऊँचा है। हमारे React प्रोजेक्ट में हमने यह आकलन किया कि Prosemirror और react-prosemirror की documentation style ज़्यादा user-friendly और परिपक्व है, इसलिए हमने react-prosemirror चुना और tiptap नहीं चुना।
हमारी requirements के लिए POC sample code बनाने हेतु React examples को समझते समय हमें निम्न समस्याएँ हुईं।
StarterKit जोड़ने पर कौन-कौन से elements उपलब्ध होते हैं? इसके लिए package name से अलग documentation ढूँढनी पड़ती है। tiptap examples चलाकर जो focus बना होता है, वह टूट जाता है।
ListItem StarterKit में शामिल है, फिर example में ListItem को दोबारा project में क्यों शामिल किया गया है? extension की configuration करने के लिए।
editor().chain().focus() जैसी syntax क्यों इस्तेमाल करनी चाहिए? method chaining के design principle या explanation पर कोई जानकारी नहीं है।
Bubble menu और Floating menu React examples में नहीं हैं। यह Try it live page (https://templates.tiptap.dev/pjrwkQtNpq) में दिखी functionality से अलग तरह से काम करता है, इसलिए यह सुविधा क्यों गायब है, यह समझने के लिए documentation देखनी पड़ती है।
Table feature नहीं है, इसलिए Extensions page में table keyword से search करते हैं। Search results में Table, TableCell, TableHeader, TableRow आते हैं। क्या इन्हें सबको जोड़ना होगा?
किसी तरह Table और तरह-तरह के extensions जोड़ दिए। अब यह जानने के लिए कि feature ठीक से काम करता है या नहीं, पहले table insert करना होगा। Toolbar command कैसे लिखें? editor toolbar में इन commands के लिए functions कहाँ जोड़ी जाएँगी? इसका बिल्कुल कोई hint नहीं है।
एक requirement है कि table के अंदर दूसरी table nest नहीं होनी चाहिए। यह पता लगाने की logic कैसे implement करें कि cursor table के अंदर है या नहीं? इसका बिल्कुल कोई hint नहीं है।
मुझे याद था कि Color को extension के रूप में package किया गया है, तो जिज्ञासा में source code खोलकर देखा। src directory में सिर्फ़ दो files देखकर आह निकल गई। इतना छोटा module बनाने का इरादा क्या था, यह समझ नहीं आता। इतनी छोटी functionality को भी package बना देने से reusability से ज़्यादा dependency version management का बोझ नहीं बढ़ता क्या?
1-3, 4-6, 8 में मुझे बिल्कुल भी कोई सवाल या असुविधा महसूस नहीं हुई, इसलिए मेरे लिए सहमत होना मुश्किल है.
1-2
StarterKit, जैसा कि नाम से ही स्पष्ट है, Starter के लिए Kit है, इसलिए वास्तविक उपयोग के समय इसका बहुत ज़्यादा मतलब नहीं लगता.
ListItem के मामले में भी, जैसा आपने कहा. यह Color extension की सेटिंग के लिए एक तत्व है. इसी तरह, अगर StarterKit का उपयोग न करें तो बात वहीं खत्म हो जाती है, ऐसा मुझे लगता है.
3
chain().something().run() सिर्फ syntax sugar जैसी चीज़ है, लेकिन मुझे लगता है कि यह batteries-included library के concept के अनुरूप फीचर देता है.
मोबाइल environment में, जहाँ bold के बाद focus जैसी actions लगभग अनिवार्य होती हैं, मैं इसे बहुत उपयोगी तरीके से इस्तेमाल कर रहा हूँ.
4
मैंने यह फीचर इस्तेमाल नहीं किया है, इसलिए ठीक से नहीं जानता.
(मुझे लगता है कि यह उस कमी के बदले मिलने वाला एक फ़ायदा भी है जिसका आपने 1 नंबर में ज़िक्र किया था कि इससे focus state टूट जाती है, क्योंकि मुझे उन फीचर्स की जानकारी ज़बरदस्ती नहीं देखनी पड़ती जिन्हें मैं इस्तेमाल ही नहीं करूँगा.)
5-6
यह हर extension के दस्तावेज़ में अच्छी तरह दिया गया है, और सामान्य तौर पर editor implement करने से इसमें बिल्कुल कोई फ़र्क नहीं है.
ईमानदारी से कहूँ तो, 6 नंबर में आपने जो कहा, उसमें मुझे यह भी ठीक से समझ नहीं आ रहा कि क्या मैंने savvykang की बात सही समझी है या नहीं... बार-बार यही सोच आता है, 'यह सवाल क्यों है...? आखिर किस तरह के hint की ज़रूरत है...?'
7
"दूसरे nodes की तरह ही" editor.isActive('table') से focus जाँचा जा सकता है.
लेकिन मुझे नहीं लगता कि सिर्फ focus node पहचान लेने से यह समस्या हल हो जाएगी. यह ऐसी requirement लगती है जिसमें paste पर filtering, developer tools के ज़रिए insertion आदि कई बातों पर विचार करना होगा.
8
मैं इस बात से सहमत हूँ कि dependency version management बोझ बन सकता है, लेकिन मुझे लगता है कि ज़रूरी न होने वाले फीचर्स का code साथ में न रखना भी एक फ़ायदा है.
ठीक हमारे case में भी आपने जिस Color extension का ज़िक्र किया, उसे इस्तेमाल न करने की स्थिति थी. लगता है हर तरीके के अपने-अपने फ़ायदे और नुकसान हैं.
.
मुझे लगता है कि आपने जिन react-prosemirror और tiptap का ज़िक्र किया, उनका concept पूरी तरह अलग है.
एक ऐसा जो prosemirror को React-style में इस्तेमाल करने लायक बनाता है
vs
एक ऐसा जहाँ prosemirror-based है या नहीं, यह महत्वपूर्ण नहीं है; बस मेरे service के लिए उपयुक्त editor implement करने के लिए जो कुछ चाहिए, वह सब इकट्ठा करके दिया गया है
Vue की तरफ यह पहले से ही काफ़ी लोकप्रिय है, इसलिए इसे लिखूँ या नहीं इस पर सोच रहा था,
लेकिन इस बार SvelteKit में लागू करके इस्तेमाल किया तो काफ़ी संतोषजनक लगा, इसलिए साझा कर रहा हूँ.
Svelte इकोसिस्टम में अब तक ऐसा कोई WYSIWYG एडिटर नहीं मिला था जिसे देखकर लगे कि बस यही है!, इसलिए इस बात को लेकर दुविधा थी,
अगर आप भी ऐसी ही समस्या का सामना कर रहे हैं, तो इसे एक बार आज़माना अच्छा विकल्प हो सकता है.
9 टिप्पणियां
मैंने व्यक्तिगत रूप से जिनमें से इस्तेमाल किया है, उनमें यह सबसे सुविधाजनक लगा और इसे विस्तार देना भी सबसे आसान लगा।
Slate से एडिटर बनाते समय जो असुविधाएँ महसूस हुई थीं, उनमें से बहुत-सी यहाँ सचमुच हल हो गईं।
क्या आप यह साझा कर सकते हैं कि Slate editor इस्तेमाल करते समय आपको किस तरह की असुविधाएँ हुईं?
मैंने तो सिर्फ़ Tiptap ही इस्तेमाल किया है, लेकिन Slate अच्छा है ऐसा सुना है, इसलिए मेरी इसमें दिलचस्पी बनी है!!
बाहरी components बनाने वाला हिस्सा कहीं ज़्यादा सुविधाजनक है। खासकर React जैसे मामलों में, जहाँ अपना खुद का DOM इस्तेमाल होता है, वहाँ HTML नहीं बल्कि component के रूप में rendering चाहिए होती है, और शुरू से ही modularization को ध्यान में रखकर बनाया गया tiptap संशोधित करना ज़्यादा आसान लगा।
कुल मिलाकर मुझे Slate के दस्तावेज़ समझने में कठिन लगे, और वह इतने raw थे कि जिन फीचर्स को मैं बनाना चाहता था, उनके लिए मुझे लगा कि सीखने के लिए और भी बहुत कुछ है.
यह लगभग 2 साल पहले की याद है, इसलिए थोड़ा अलग हो सकता है, लेकिन मुझे ऐसी समस्याओं का सामना करना पड़ा था.
ओ.... धन्यवाद~!
https://tiptap.dev/docs/editor/installation/react#7-the-complete-setup पर काम करने वाले एडिटर का उदाहरण देखा जा सकता है.
व्यक्तिगत रूप से मुझे लगता है कि इसकी documentation काफ़ी अच्छी है, लेकिन बीच-बीच में paid subscription की ज़रूरत वाले elements भी मिले-जुले हैं.
दस्तावेज़ पढ़ने में यह इतना असुविधाजनक नहीं है, लेकिन ज़रूरत भी नहीं है फिर भी खरीदने का मन करा देते हैं—इस लिहाज़ से कमाल भी है और थोड़ा खीझ दिलाने वाला भी.. काफ़ी mixed feelings हैं.
दस्तावेज़ीकरण काफ़ी अच्छा है, इस बात से सहमत होना मेरे लिए मुश्किल है। मुझे लगता है कि getting started docs और API docs के बीच का अंतर बहुत बड़ा है, इसलिए learning curve ऊँचा है। हमारे React प्रोजेक्ट में हमने यह आकलन किया कि Prosemirror और react-prosemirror की documentation style ज़्यादा user-friendly और परिपक्व है, इसलिए हमने react-prosemirror चुना और tiptap नहीं चुना।
हमारी requirements के लिए POC sample code बनाने हेतु React examples को समझते समय हमें निम्न समस्याएँ हुईं।
editor().chain().focus()जैसी syntax क्यों इस्तेमाल करनी चाहिए? method chaining के design principle या explanation पर कोई जानकारी नहीं है।tablekeyword से search करते हैं। Search results में Table, TableCell, TableHeader, TableRow आते हैं। क्या इन्हें सबको जोड़ना होगा?srcdirectory में सिर्फ़ दो files देखकर आह निकल गई। इतना छोटा module बनाने का इरादा क्या था, यह समझ नहीं आता। इतनी छोटी functionality को भी package बना देने से reusability से ज़्यादा dependency version management का बोझ नहीं बढ़ता क्या?1-3, 4-6, 8 में मुझे बिल्कुल भी कोई सवाल या असुविधा महसूस नहीं हुई, इसलिए मेरे लिए सहमत होना मुश्किल है.
1-2
StarterKit, जैसा कि नाम से ही स्पष्ट है, Starter के लिए Kit है, इसलिए वास्तविक उपयोग के समय इसका बहुत ज़्यादा मतलब नहीं लगता.
ListItem के मामले में भी, जैसा आपने कहा. यह Color extension की सेटिंग के लिए एक तत्व है. इसी तरह, अगर StarterKit का उपयोग न करें तो बात वहीं खत्म हो जाती है, ऐसा मुझे लगता है.
3
chain().something().run() सिर्फ syntax sugar जैसी चीज़ है, लेकिन मुझे लगता है कि यह batteries-included library के concept के अनुरूप फीचर देता है.
मोबाइल environment में, जहाँ bold के बाद focus जैसी actions लगभग अनिवार्य होती हैं, मैं इसे बहुत उपयोगी तरीके से इस्तेमाल कर रहा हूँ.
4
मैंने यह फीचर इस्तेमाल नहीं किया है, इसलिए ठीक से नहीं जानता.
(मुझे लगता है कि यह उस कमी के बदले मिलने वाला एक फ़ायदा भी है जिसका आपने 1 नंबर में ज़िक्र किया था कि इससे focus state टूट जाती है, क्योंकि मुझे उन फीचर्स की जानकारी ज़बरदस्ती नहीं देखनी पड़ती जिन्हें मैं इस्तेमाल ही नहीं करूँगा.)
5-6
यह हर extension के दस्तावेज़ में अच्छी तरह दिया गया है, और सामान्य तौर पर editor implement करने से इसमें बिल्कुल कोई फ़र्क नहीं है.
ईमानदारी से कहूँ तो, 6 नंबर में आपने जो कहा, उसमें मुझे यह भी ठीक से समझ नहीं आ रहा कि क्या मैंने savvykang की बात सही समझी है या नहीं... बार-बार यही सोच आता है, 'यह सवाल क्यों है...? आखिर किस तरह के hint की ज़रूरत है...?'
7
"दूसरे nodes की तरह ही" editor.isActive('table') से focus जाँचा जा सकता है.
लेकिन मुझे नहीं लगता कि सिर्फ focus node पहचान लेने से यह समस्या हल हो जाएगी. यह ऐसी requirement लगती है जिसमें paste पर filtering, developer tools के ज़रिए insertion आदि कई बातों पर विचार करना होगा.
8
मैं इस बात से सहमत हूँ कि dependency version management बोझ बन सकता है, लेकिन मुझे लगता है कि ज़रूरी न होने वाले फीचर्स का code साथ में न रखना भी एक फ़ायदा है.
ठीक हमारे case में भी आपने जिस Color extension का ज़िक्र किया, उसे इस्तेमाल न करने की स्थिति थी. लगता है हर तरीके के अपने-अपने फ़ायदे और नुकसान हैं.
.
मुझे लगता है कि आपने जिन react-prosemirror और tiptap का ज़िक्र किया, उनका concept पूरी तरह अलग है.
एक ऐसा जो prosemirror को React-style में इस्तेमाल करने लायक बनाता है
vs
एक ऐसा जहाँ prosemirror-based है या नहीं, यह महत्वपूर्ण नहीं है; बस मेरे service के लिए उपयुक्त editor implement करने के लिए जो कुछ चाहिए, वह सब इकट्ठा करके दिया गया है
Vue की तरफ यह पहले से ही काफ़ी लोकप्रिय है, इसलिए इसे लिखूँ या नहीं इस पर सोच रहा था,
लेकिन इस बार SvelteKit में लागू करके इस्तेमाल किया तो काफ़ी संतोषजनक लगा, इसलिए साझा कर रहा हूँ.
Svelte इकोसिस्टम में अब तक ऐसा कोई WYSIWYG एडिटर नहीं मिला था जिसे देखकर लगे कि बस यही है!, इसलिए इस बात को लेकर दुविधा थी,
अगर आप भी ऐसी ही समस्या का सामना कर रहे हैं, तो इसे एक बार आज़माना अच्छा विकल्प हो सकता है.