🤟🏿 👨‍⚖️ 👎🏻 मल्टी-ब्रांड मल्टी-प्लेटफ़ॉर्म आइकन स्केच और एक नोड.जेएस स्क्रिप्ट के साथ उत्पन्न करना

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

आप पोस्ट का पहला भाग यहाँ पढ़ सकते हैं।

स्केच फाइलें, एकत्र किए गए सभी आइकन, स्टाइल और ठीक से नाम के साथ, तैयार थे। अब कोड लिखना शुरू करने का समय था।

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

स्क्रिप्ट का निर्माण

बिल्ड स्क्रिप्ट - Node.js में लिखी गई - अपने प्रवाह में अपेक्षाकृत सीधी है: एक बार निर्भरता को आयात करने के बाद, स्केच फ़ाइलों की सूची को प्रक्रिया के लिए घोषित किया (ब्रांडों की सूची के रूप में, और प्रत्येक ब्रांड के लिए उस ब्रांड की फ़ाइलों की सूची) और जाँच की जाती है कि स्केच क्लाइंट पर स्थापित है, स्क्रिप्ट ब्रांड के सरणी पर लूप करती है, और इनमें से प्रत्येक के लिए यह इन चरणों को अनुक्रम में निष्पादित करता है:

ब्रांड के लिए डिज़ाइन टोकन प्राप्त करें (हमें रंग मूल्यों की आवश्यकता है)
ब्रांड से जुड़ी स्केच फ़ाइलों को क्लोन करें, आंतरिक JSON फ़ाइलों को उजागर करने के लिए उन्हें अनज़िप करें, और इन JSON फ़ाइलों के आंतरिक मूल्यों में से कुछ में हेरफेर करें (इस पर बाद में)
स्केच JSON फ़ाइलों ( document.json , meta.json और पृष्ठों / pageUniqueID.json ) से प्रासंगिक मेटा-डेटा पढ़ें; विशेष रूप से हमें साझा शैलियों की सूची और फाइलों में निहित संपत्ति / आइकन की सूची की आवश्यकता है
स्केच JSON फ़ाइलों के कुछ और जोड़तोड़ के बाद, उन्हें ज़िप करें और, (क्लोन और अपडेटेड) स्केच फ़ाइलों का उपयोग करके, तीन प्लेटफार्मों (iOS, Android, Mobile Web) के लिए अंतिम आउटपुट फ़ाइलों को निर्यात और उत्पन्न करें

आप मुख्य बिल्ड स्क्रिप्ट के प्रासंगिक भागों को यहाँ देख सकते हैं:

// ... modules imports here const SKETCH_FILES = { badoo: ['icons_common'], blendr: ['icons_common', 'icons_blendr'], fiesta: ['icons_common', 'icons_fiesta'], hotornot: ['icons_common', 'icons_hotornot'], }; const SKETCH_FOLDER_PATH = path.resolve(__dirname, '../src/'); const SKETCH_TEMP_PATH = path.resolve(SKETCH_FOLDER_PATH, 'tmp'); const DESTINATION_PATH = path.resolve(__dirname, '../dist'); console.log('Build started...'); if (sketchtool.check()) { console.log(`Processing Sketch file via ${sketchtool.version()}`); build(); } else { console.info('You need Sketch installed to run this script'); process.exit(1); } // ---------------------------------------- function build() { // be sure to start with a blank slate del.sync([SKETCH_TEMP_PATH, DESTINATION_PATH]); // process all the brands declared in the list of Sketch files Object.keys(SKETCH_FILES).forEach(async (brand) => { // get the design tokens for the brand const brandTokens = getDesignTokens(brand); // prepare the Sketch files (unzipped) and get a list of them const sketchUnzipFolders = await prepareSketchFiles({ brand, sketchFileNames: SKETCH_FILES[brand], sketchFolder: SKETCH_FOLDER_PATH, sketchTempFolder: SKETCH_TEMP_PATH }); // get the Sketch metadata const sketchMetadata = getSketchMetadata(sketchUnzipFolders); const sketchDataSharedStyles = sketchMetadata.sharedStyles; const sketchDataAssets = sketchMetadata.assetsMetadata; generateAssetsPDF({ platform: 'ios', brand, brandTokens, sketchDataSharedStyles, sketchDataAssets }); generateAssetsSVGDynamicMobileWeb({ platform: 'mw', brand, brandTokens, sketchDataSharedStyles, sketchDataAssets }); generateAssetsVectorDrawableDynamicAndroid({ platform: 'android', brand, brandTokens, sketchDataSharedStyles, sketchDataAssets }); }); }

दरअसल, पूरे पाइपलाइन कोड की तुलना में बहुत अधिक जटिल है, और जटिलता तैयार हैसैटचेकफाइल्स , गेटस्कैचमेटेटा और जेनरेटसेट्स [प्रारूप] [प्लेटफॉर्म] कार्यों में निहित है। मैं उन्हें नीचे और अधिक विस्तार से समझाने की कोशिश करूंगा।

स्केच फ़ाइलों को तैयार करना

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

ब्रांड से जुड़ी फाइलें - ब्लेंडर के लिए, उदाहरण के लिए, फाइलें icons_common.sketch और icons_blendr.sketch - शुरू में एक अस्थायी फ़ोल्डर में क्लोन की जाती हैं (अधिक सटीक, ब्रांड के नाम पर एक सबफ़ोल्डर जिसे संसाधित किया जा रहा है)।

फिर आंतरिक JSON फ़ाइलों को संसाधित किया जाता है, एबी प्री टेस्टिंग से गुजरने वाली परिसंपत्तियों में एक उपसर्ग जोड़ा जाता है, ताकि जब निर्यात किया जाए तो उन्हें एक पूर्वनिर्धारित नाम (प्रयोग का अनूठा नाम) के साथ एक सबफ़ोल्डर में सहेजा जाएगा। यह समझने के लिए कि परीक्षण के लिए कौन सी संपत्ति है, हम बस यह जांचते हैं कि स्केच में जिस पृष्ठ में उनका नाम संग्रहित है वह "XP_" के साथ उपसर्ग है।

परत के नामों की तुलना, स्केच फ़ाइलों के अंदर, अपडेट से पहले और बाद में।

ऊपर दिए गए उदाहरण में, जब निर्यात की गई संपत्तियां एक फ़ाइल नाम "आइकन-नाम [संस्करण-नाम] .ext" के साथ सबफ़ोल्डर "this__is_an_experiment" में सहेजी जाएंगी ।

स्केच मेटाडेटा पढ़ना

इस प्रक्रिया का दूसरा महत्वपूर्ण चरण स्केच फ़ाइलों से संबंधित सभी प्रासंगिक मेटा-डेटा प्राप्त करना है, विशेष रूप से उनकी आंतरिक एलसन फ़ाइलों से। जैसा कि ऊपर बताया गया है, ये फाइलें दो मुख्य फाइलें ( document.json और meta.json ) और पेज फाइलें ( पेज / pageUniqueId.json ) हैं।

Document.json फ़ाइल का उपयोग साझा शैलियाँ की सूची प्राप्त करने के लिए किया जाता है, जो कि लेयरसेंटल्स ऑब्जेक्ट प्रॉपर्टी के अंतर्गत दिखाई देती हैं:

 { "_class": "document", "do_objectID": "45D2DA82-B3F4-49D1-A886-9530678D71DC", "colorSpace": 1, ... "layerStyles": { "_class": "sharedStyleContainer", "objects": [ { "_class": "sharedStyle", "do_objectID": "9BC39AAD-CDE6-4698-8EA5-689C3C942DB4", "name": "features/feature-like", "value": { "_class": "style", "fills": [ { "_class": "fill", "isEnabled": true, "color": { "_class": "color", "alpha": 1, "blue": 0.10588235408067703, "green": 0.4000000059604645, "red": 1 }, "fillType": 0, "noiseIndex": 0, "noiseIntensity": 0, "patternFillType": 1, "patternTileScale": 1 } ], "blur": {...}, "startMarkerType": 0, "endMarkerType": 0, "miterLimit": 10, "windingRule": 1 } }, ...

प्रत्येक शैली के लिए, हम एक कुंजी-मूल्य ऑब्जेक्ट में कुछ बुनियादी जानकारी संग्रहीत करते हैं। इसका उपयोग बाद में किया जाएगा जब भी हमें इसकी विशिष्ट आईडी (स्केच, do_objectID संपत्ति) के आधार पर किसी शैली का नाम प्राप्त करने की आवश्यकता होती है:

 const parsedSharedStyles = {}; parsedDocument.layerStyles.objects.forEach((object) => { parsedSharedStyles[object.do_objectID] = { name: object.name, isFill: _.get(object, 'value.fills[0].color') !== undefined, isBorder: _.get(object, 'value.borders[0].color') !== undefined, }; });

इस बिंदु पर, हम पृष्ठों की सूची प्राप्त करने के लिए meta.json फ़ाइल पर चलते हैं, विशेष रूप से हमें उनकी विशिष्ट आईडी और नाम की आवश्यकता है :

 { "commit": "623a23f2c4848acdbb1a38c2689e571eb73eb823", "pagesAndArtboards": { "EE6BE8D9-9FAD-4976-B0D8-AB33D2B5DBB7": { "name": "Icons", "artboards": { "3275987C-CE1B-4369-B789-06366EDA4C98": { "name": "badge-feature-like" }, "C6992142-8439-45E7-A346-FC35FA01440F": { "name": "badge-feature-crush" }, ... "7F58A1C4-D624-40E3-A8C6-6AF15FD0C32D": { "name": "tabbar-livestream" } ... } }, "ACF82F4E-4B92-4BE1-A31C-DDEB2E54D761": { "name": "XP_this__is_an_experiment", "artboards": { "31A812E8-D960-499F-A10F-C2006DDAEB65": { "name": "this__is_an_experiment/tabbar-livestream[variant1]" }, "20F03053-ED77-486B-9770-32E6BA73A0B8": { "name": "this__is_an_experiment/tabbar-livestream[variant2]" }, "801E65A4-3CC6-411B-B097-B1DBD33EC6CC": { "name": "this__is_an_experiment/tabbar-livestream[control]" } } },

फिर, हर पेज के लिए हम पेज फ़ोल्डर के तहत संबंधित JSON फाइल को पढ़ते हैं (जैसा कि पहले ही कहा गया है, फ़ाइल नाम [pageUniqueId] .json ) है, और हम उस पृष्ठ में निहित संपत्तियों से गुजरते हैं (वे परतों के रूप में दिखाई देते हैं)। इस तरह, हर आइकन के लिए हमें उसका नाम, उसकी चौड़ाई / ऊँचाई, उस लेयर आइकन के लिए स्केच मेटा-डेटा, और यदि वह किसी प्रयोग पृष्ठ पर है, तो प्रश्न में AB परीक्षण का नाम, और संस्करण का नाम उस आइकन के लिए।

सूचना : "page.json" ऑब्जेक्ट बहुत जटिल है, इसलिए मैं यहां नहीं जाऊंगा। यदि आप उत्सुक हैं और यह देखना चाहते हैं कि यह कैसा दिखता है, तो मैं आपको एक नया, रिक्त स्केच फ़ाइल बनाने का सुझाव देता हूं, इसमें कुछ सामग्री जोड़ें, और इसे सहेजें; फिर ज़िप में इसके एक्सटेंशन का नाम बदलें, इसे अनज़िप करें और "पेज" फ़ोल्डर के तहत दिखाई देने वाली फ़ाइलों में से एक में देखें।

आर्टबोर्ड को संसाधित करते समय, हम प्रयोगों की एक सूची भी बनाते हैं (उनकी संबंधित संपत्तियों के साथ) जिनका उपयोग बाद में यह निर्धारित करने के लिए किया जाएगा कि कौन से आइकन विकल्प का उपयोग किया जाता है और किस प्रयोग के लिए, आइकन विकल्पों का नाम "आइकन बेस" ऑब्जेक्ट के साथ जोड़कर।

प्रत्येक स्केच फ़ाइल को संसाधित किया जा रहा है जो ब्रांड के साथ जुड़ा हुआ है, हम एक संपत्तिमाताटाटा वस्तु का उत्पादन करते हैं जो इस तरह दिखता है:

 { "navigation-bar-edit": { "do_objectID": "86321895-37CE-4B3B-9AA6-6838BEDB0977", ...sketch_artboard_properties, "name": "navigation-bar-edit", "assetname": "navigation-bar-edit", "source": "icons_common", "width": 48, "height": 48 "layers": [ { "do_objectID": "A15FA03C-DEA6-4732-9F85-CA0412A57DF4", "name": "Path", ...sketch_layer_properties, "sharedStyleID": "6A3C0FEE-C8A3-4629-AC48-4FC6005796F5", "style": { ... "fills": [ { "_class": "fill", "isEnabled": true, "color": { "_class": "color", "alpha": 1, "blue": 0.8784313725490196, "green": 0.8784313725490196, "red": 0.8784313725490196 }, } ], "miterLimit": 10, "startMarkerType": 0, "windingRule": 1 }, }, ], ... }, "experiment-name/navigation-bar-edit[variant]": { "do_objectID": "00C0A829-D8ED-4E62-8346-E7EFBC04A7C7", ...sketch_artboard_properties, "name": "experiment-name/navigation-bar-edit[variant]", "assetname": "navigation-bar-edit", "source": "icons_common", "width": 48, "height": 48 ...

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

इसलिए हमने प्रत्येक विशेष ब्रांड से जुड़ी स्केच फ़ाइलों को एक सरणी के रूप में घोषित किया:

 const SKETCH_FILES = { badoo: ['icons_common'], blendr: ['icons_common', 'icons_blendr'], fiesta: ['icons_common', 'icons_fiesta'], hotornot: ['icons_common', 'icons_hotornot'], };

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

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

एक ही आइकन के "ओवरराइडिंग" का तार्किक स्कीमा विशेष रूप से सफेद-लेबल के लिए डिज़ाइन किए गए आइकन और आइकन के एक आम / साझा सेट के बीच काम करता है (एबी परीक्षण के मामले पर भी विचार करता है)

विभिन्न प्लेटफार्मों के लिए विभिन्न स्वरूपों में अंतिम फ़ाइलों का निर्माण

प्रक्रिया का अंतिम चरण अलग-अलग प्लेटफार्मों के लिए अलग-अलग प्रारूपों (आईओएस के लिए पीडीएफ, एसवीजी / जेएसएक्स वेब के लिए पीडीएफ, और एंड्रॉइड के लिए वेक्टरड्रावेबल) के साथ आइकन फ़ाइलों की वास्तविक पीढ़ी है।

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

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

एंड्रॉइड पीढ़ी के लिए, एक अतिरिक्त हेरफेर की आवश्यकता है (बाद में इस पर अधिक): हम हर परत की भरण-नियम संपत्ति को सम-विषम से गैर-शून्य में बदल देते हैं (यह JSON ऑब्जेक्ट में "विंडरिंग" संपत्ति द्वारा नियंत्रित किया जाता है, जहां " 1 "का अर्थ है" सम-विषम "और" 0 "का अर्थ है" गैर-शून्य ")।

इन जोड़तोड़ों को पूरा करने के बाद, हम स्केच JSON फ़ाइलों को एक मानक स्केच फ़ाइल में संकुचित करते हैं, ताकि इसे अद्यतन गुणों के साथ परिसंपत्तियों को निर्यात करने के लिए संसाधित किया जा सके (क्लोन और अपडेट की गई फाइलें बिल्कुल सामान्य स्केच फ़ाइलें हैं: इन्हें स्केच में खोला जा सकता है। , देखा, संपादित, सहेजा गया, आदि)।

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

 sketchtool.run(`export slices ${cloneSketchFile} --formats=svg <i>--scales=1 </i>--output=${destinationFolder} --overwriting`);

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

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

जैसा कि ऊपर उल्लेख किया गया है, हमें विभिन्न प्लेटफार्मों के लिए अलग-अलग अंतिम स्वरूपों की आवश्यकता है। IOS के लिए हमें पीडीएफ फाइलें चाहिए, और हम उन्हें सीधे स्केचटूल कमांड के साथ निर्यात कर सकते हैं। जबकि, मोबाइल वेब के लिए हम JSX फाइलें चाहते हैं, और Android के लिए हम वेक्टरड्राएबल फाइलें चाहते हैं; इस कारण से हम एसवीजी प्रारूप में परिसंपत्तियों को एक मध्यवर्ती फ़ोल्डर में निर्यात करते हैं, और फिर हम उन्हें आगे की प्रक्रिया के अधीन करते हैं।

IOS के लिए पीडीएफ फाइलें

अजीब तरह से, पीडीएफ (केवल?) वेक्टर संपत्तियों के आयात और प्रतिपादन के लिए Xcode और OS / iOS द्वारा समर्थित प्रारूप है ( यहां Apple द्वारा इस पसंद के पीछे तकनीकी कारणों का संक्षिप्त विवरण दिया गया है)।

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

वेब के लिए प्रतिक्रिया / JSX फ़ाइलें

वेब के मामले में, हम svgr नामक एक नोड लाइब्रेरी का उपयोग करते हैं जो सादे एसवीजी फाइलों को रिएक्ट घटकों में परिवर्तित करती है। लेकिन हम कुछ और भी अधिक शक्तिशाली करना चाहते हैं: हम रनटाइम पर आइकन को "गतिशील रूप से पेंट" करना चाहते हैं, डिजाइन के टोकन से आने वाले रंगों के साथ। इस कारण से, रूपांतरण से ठीक पहले, हम एसवीजी में उन रास्तों के भराव मूल्यों को प्रतिस्थापित करते हैं जो मूल रूप से एक साझा शैली लागू थे, उस शैली के साथ संबंधित टोकन मूल्य के साथ।

तो, अगर यह फ़ाइल बैज-फ़ीचर-जैसे । स्केच से निर्यात किया गया:

 <?xml version="1.0" encoding="UTF-8"?> <svg width="128px" height="128px" viewBox="0 0 128 128" version="1.1" xmlns="<a href="http://www.w3.org/2000/svg">http://www.w3.org/2000/svg</a>" xmlns:xlink="<a href="http://www.w3.org/1999/xlink">http://www.w3.org/1999/xlink</a>"> <!-- Generator: sketchtool 52.2 (67145) - <a href="http://www.bohemiancoding.com/sketch">http://www.bohemiancoding.com/sketch</a> --> <title>badge-feature-like</title> <desc>Created with sketchtool.</desc> <g id="Icons" fill="none" fill-rule="evenodd"> <g id="badge-feature-like"> <circle id="circle" fill="#E71032" cx="64" cy="64" r="64"> <path id="Shape" fill="#FFFFFF" d="M80.4061668,..."></path> </g> </g> </svg>

अंतिम बैज-फीचर- like.js संपत्ति / आइकन इस तरह दिखाई देगा:

 /* This file is generated automatically - DO NOT EDIT */ /* eslint-disable max-lines,max-len,camelcase */ const React = require('react'); module.exports = function badge_feature_like({ tokens }) { return ( <svg data-origin="pipeline" viewBox="0 0 128 128"> <g fill="none" fillRule="evenodd"> <circle fill={tokens.TOKEN_COLOR_FEATURE_LIKED_YOU} cx={64} cy={64} r={64} /> <path fill="#FFF" d="M80.4061668,..." /> </g> </svg> ); };

जैसा कि आप देख सकते हैं, हमने एक गतिशील एक के साथ, सर्कल के भरण रंग के लिए स्थैतिक मूल्य को बदल दिया है, जो डिज़ाइन टोकन से इसका मूल्य लेता है (ये संदर्भ <Icon /> घटक के लिए कॉन्टेक्ट एपीआई के माध्यम से उपलब्ध कराया जाएगा) लेकिन यह एक और कहानी है)।

मेटाडेटा ऑब्जेक्ट में संग्रहीत परिसंपत्ति के लिए स्केच मेटा-डेटा के माध्यम से यह प्रतिस्थापन संभव है: संपत्ति की परतों के माध्यम से पुन: लूपिंग, एक डोम चयनकर्ता बनाना संभव है (उपरोक्त मामले में, यह #Ic # बैज-फीचर होगा) #circle की तरह ) और SVG ट्री में नोड खोजने के लिए इसका उपयोग करें, और इसकी भराव विशेषता के मूल्य को बदलें (इस ऑपरेशन के लिए हम चीयरियो लाइब्रेरी का उपयोग करते हैं)।

Android के लिए VectorDrawable फ़ाइलें

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

विभिन्न पुस्तकालयों और उपकरणों को देखने के बाद, हमने svg2vectordrawable नामक एक पुस्तकालय का उपयोग करने का निर्णय लिया। न केवल इसे सक्रिय रूप से बनाए रखा जाता है (कम से कम, जो हमें मिला है उससे बेहतर) लेकिन यह भी अधिक पूर्ण है।

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

संभावित रूप से, डिजाइनर मैन्युअल रूप से ऐसा कर सकते हैं:

लेकिन यह आसानी से अनदेखी हो सकती है, और इसलिए मानव-त्रुटि का खतरा हो सकता है।

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

इस मामले में अंतिम बैज-फीचर-like.xml फ़ाइल इस प्रकार है:

 <!-- This file is generated automatically - DO NOT EDIT --> <vector xmlns:android="<a href="http://schemas.android.com/apk/res/android">http://schemas.android.com/apk/res/android</a>" android:width="128dp" android:height="128dp" android:viewportWidth="128" android:viewportHeight="128"> <path android:fillColor="?color_feature_liked_you" android:pathData="M64 1a63 63 0 1 0 0 126A63 63 0 1 0 64 1z" /> <path android:fillColor="#FFFFFF" android:pathData="M80.406 ..." /> </vector>

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

Android Studio में आयात किए जाने के बाद वेक्टरड्रावबल ऐसा दिखता है:

Android Studio में आयात किया गया वेक्टरड्राइव आइकन का एक उदाहरण

इस मामले में एक बात ध्यान देने योग्य है: एंड्रॉइड स्टूडियो के पास संपत्ति को व्यवस्थित करने का एक बहुत सख्त और निर्धारित तरीका है: कोई नेस्टेड फ़ोल्डर और सभी लोअरकेस नाम! इसका मतलब है कि हमें उनके आइकनों के नामों के लिए थोड़ा अलग प्रारूप बनाना होगा: प्रयोग के तहत एक संपत्ति के मामले में, इसका नाम ic_icon-name__experiment-name__variant-name जैसा कुछ होगा।

JSON संपत्ति पुस्तकालय के रूप में

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

आइसेटमाटाटा ऑब्जेक्ट से आइकनों की फ्लैट सूची निकालने के बाद, हम उस पर लूप करते हैं और प्रत्येक आइटम की हम जांच करते हैं:

यदि यह एक सामान्य संपत्ति है (उदाहरण के लिए। टैब्बर-लिवेस्ट्रीम ), और यदि यह है, तो हम इसे बनाए रखते हैं
यदि यह AB परीक्षण में एक प्रकार है (उदाहरण प्रयोग / tabbar-livestream [variant] ) तो हम इसके आधार, संपत्ति (इस मामले में, tabbar-) के संपत्ति abtests के लिए इसका नाम, पथ, AB परीक्षण और भिन्न नाम जोड़ते हैं livestream ), और फिर हम सूची / ऑब्जेक्ट (केवल "आधार" मायने रखता है) से भिन्न प्रविष्टि को हटाते हैं;
यदि यह "भूत" संस्करण है, तो हम फ़ाइल को हटा देते हैं, और फिर सूची / ऑब्जेक्ट से प्रविष्टि को हटा देते हैं।

एक बार लूप पूरा हो जाने के बाद, शब्दकोश में सभी और केवल "आधार" आइकन (और उनके एबी परीक्षण, यदि प्रयोग के तहत) की सूची होगी। इनमें से प्रत्येक के लिए इसका नाम, आकार, पथ होगा और, यदि कोई आइकन एबी परीक्षण के तहत है, तो परिसंपत्ति के विभिन्न विकल्पों की जानकारी।

यह शब्दकोश तब JSON प्रारूप में ब्रांड और प्लेटफ़ॉर्म के लिए गंतव्य फ़ोल्डर में सहेजा जाता है । यहाँ, उदाहरण के लिए, "मोबाइल वेब" पर "ब्लेंडर" एप्लिकेशन के लिए बनाई गई संपत्ति ।json फ़ाइल है:

 { "platform": "mw", "brand": "blendr", "assets": { "badge-feature-like": { "assetname": "badge-feature-like", "path": "assets/badge-feature-like.jsx", "width": 64, "height": 64, "source": "icons_common" }, "navigation-bar-edit": { "assetname": "navigation-bar-edit", "path": "assets/navigation-bar-edit.jsx", "width": 48, "height": 48, "source": "icons_common" }, "tabbar-livestream": { "assetname": "tabbar-livestream", "path": "assets/tabbar-livestream.jsx", "width": 128, "height": 128, "source": "icons_blendr", "abtest": { "this__is_an_experiment": { "control": "assets/this__is_an_experiment/tabbar-livestream__control.jsx", "variant1": "assets/this__is_an_experiment/tabbar-livestream__variant1.jsx", "variant2": "assets/this__is_an_experiment/tabbar-livestream__variant2.jsx" }, "a_second-experiment": { "control": "assets/a_second-experiment/tabbar-livestream__control.jsx", "variantA": "assets/a_second-experiment/tabbar-livestream__variantA.jsx" } } }, ... } }

बहुत अंतिम चरण में सभी संपत्ति फ़ोल्डर को संपीड़ित करना है। फ़ाइलों को ज़िप करें, ताकि उन्हें अधिक आसानी से डाउनलोड किया जा सके।

अंतिम परिणाम

ऊपर वर्णित प्रक्रिया - स्केच फ़ाइलों के प्रारंभिक क्लोनिंग और हेरफेर से, प्रत्येक समर्थित प्लेटफॉर्म के लिए वांछित प्रारूप में संपत्ति के निर्यात (और रूपांतरण) से, एक परिसंपत्ति पुस्तकालय में एकत्र मेटा-जानकारी के भंडारण के लिए - है बिल्ड स्क्रिप्ट में घोषित प्रत्येक ब्रांड के लिए दोहराया गया।

नीचे एक स्क्रीनशॉट है जो निर्माण प्रक्रिया पूरी होने के बाद src और dist फ़ोल्डरों की संरचना कैसी दिखती है:

बिल्ड प्रक्रिया के पूरा होने के बाद "src" और "dist" फ़ोल्डरों की संरचना।

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

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

निष्कर्ष (और जिस तरह से सीखा सबक)

मैंने हमेशा स्केच से प्यार किया है। सालों से यह वेब और ऐप डिज़ाइन (और विकास) के लिए "डे-फैक्टो" विकल्प है। इसलिए मुझे html-sketchapp या इसी तरह के औजारों जैसे संभावित एकीकरण का पता लगाने के लिए बहुत दिलचस्पी और उत्सुकता थी, टोपी जो हम अपने वर्कफ़्लो और पाइपलाइनों में उपयोग कर सकते हैं।

यह (आदर्श) प्रवाह हमेशा मेरे ( और कई अन्य ) के लिए पवित्र कब्र रहा है :

एक डिज़ाइन टूल के रूप में स्केच को कोडबेस के संभावित "लक्ष्य" के रूप में कल्पना की जा सकती है।

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

खैर, इस परियोजना ने मेरा विचार बदल दिया। पूरी तरह से नहीं, लेकिन निश्चित रूप से बहुत कुछ।

हो सकता है कि स्केच आधिकारिक तौर पर अपने एपीआई को उजागर नहीं कर रहा है, लेकिन निश्चित रूप से जिस तरह से उन्होंने अपनी फाइलों की आंतरिक संरचना का निर्माण किया है, वह एक प्रकार का "अनौपचारिक" एपीआई है। वे क्रिप्टिक नामों का इस्तेमाल कर सकते थे, या JSON ऑब्जेक्ट्स में कुंजियों को बाधित कर सकते थे; इसके बजाय उन्होंने एक स्पष्ट, आसानी से पढ़े जाने वाले, मानव-पढ़ने योग्य, शब्दार्थ नामकरण सम्मेलन का विकल्प चुना है। मुझे नहीं लगता कि यह केवल आकस्मिक है।

तथ्य यह है कि स्केच फ़ाइलों में हेरफेर किया जा सकता है ने मेरे दिमाग को संभावित भविष्य के विकास और सुधारों की एक विस्तृत श्रृंखला खोल दी है। माउस के लिए परतों के नामकरण, स्टाइलिंग और संरचना को मान्य करने के लिए प्लगइन्स से, हमारे विकी और हमारे डिजाइन सिस्टम प्रलेखन (दोनों दिशाओं में) के साथ संभव एकीकरण करने के लिए, इलेक्ट्रॉन या कार्लो में होस्ट किए गए नोड ऐप्स के निर्माण के माध्यम से कई की सुविधा के लिए। दोहराए जाने वाले कार्य जिन्हें डिजाइनरों को करना है।

इस परियोजना का एक अप्रत्याशित बोनस (कम से कम, मेरे लिए) यह है कि अब "कॉस्मॉस आइकन" के साथ स्केच फाइलें एक "सच्चाई का स्रोत" बन गई हैं, इसी तरह कॉस्मॉस डिजाइन सिस्टम के साथ भी हुआ। यदि कोई आइकन नहीं है, तो यह कोडबेस में मौजूद नहीं है (या बेहतर है, यह मौजूद नहीं होना चाहिए: लेकिन कम से कम हम जानते हैं कि यह एक अपवाद है)। मैं जानता हूं कि यह अब स्पष्ट है, लेकिन यह मेरे लिए कम से कम पहले नहीं था।

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

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

लेकिन जो मेरे लिए महत्वपूर्ण है, और जो मैं साझा करना चाहता था, वह यह है कि यह किया जा सकता है। शायद अलग-अलग तरीकों से, अलग-अलग दृष्टिकोणों और अलग-अलग आउटपुट प्रारूपों के साथ, शायद कम जटिलता शामिल है (यानी: आपको मल्टी-ब्रांडिंग और एबी परीक्षण की आवश्यकता नहीं हो सकती है)। लेकिन अब आप अपने आइकॉन को कस्टम Node.js स्क्रिप्ट और स्केच के साथ वितरित करने में शामिल वर्कफ़्लो को स्वचालित कर सकते हैं।

इसे करने का अपना तरीका खोजें। यह मज़ेदार (और अपेक्षाकृत आसान) है।

क्रेडिट

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

मल्टी-ब्रांड मल्टी-प्लेटफ़ॉर्म आइकन स्केच और एक नोड.जेएस स्क्रिप्ट के साथ उत्पन्न करना - भाग # 2