📓 🔏 🍾 स्केच + Node.js: कई प्लेटफार्मों और ब्रांडों के लिए आइकन उत्पन्न करते हैं। भाग २ ⬇️ 🤾🏿 👩🏽‍🍳

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

आप लिंक से पहला भाग पढ़ सकते हैं।

पिछली बार, हमने स्केच फाइलें तैयार की थीं जिसमें सभी आइकन सही शैलियों में और सही नामों के साथ थे। यह कोड लिखने की बारी है।

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

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

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

ब्रांडों के लिए उपयुक्त डिज़ाइन के टोकन लेते हैं (हमें रंग मूल्यों की आवश्यकता है)।
क्लोन ब्रांड-संबंधित स्केच फाइलें, उन्हें आंतरिक 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   }); }); }

वास्तव में, पाइपलाइन कोड बहुत अधिक जटिल है। इस जटिलता का कारण तैयार prepareSketchFiles , getSketchMetadata और getSketchMetadata generateAssets[format][platform] कार्य। नीचे मैं उन्हें और अधिक विस्तार से वर्णन करने का प्रयास करूंगा।

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

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

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

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

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

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

दूसरा महत्वपूर्ण कदम स्केच फ़ाइलों से या बल्कि आंतरिक JSON फ़ाइलों से सभी आवश्यक मेटाडेटा निकालना है। जैसा कि हमने ऊपर देखा, ये दो मुख्य फाइलें हैं ( document.json और meta.json ) और पेज फाइलें ( पेज / pageUniqueId.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, }; });

अब हम met.json फ़ाइल पर जाते हैं और पृष्ठों की एक सूची प्राप्त करते हैं। हम उनकी unique-id और name में रुचि रखते हैं:

 { "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 फ़ाइलों को पढ़ते हैं (मैं दोहराता हूं कि फ़ाइल नाम प्रपत्र [पेजUniqueId] .json ) के हैं और इस पृष्ठ पर संग्रहीत संसाधनों का अध्ययन करते हैं (वे परतों की तरह दिखते हैं)। इस प्रकार, हम प्रत्येक आइकन का नाम , चौड़ाई / ऊंचाई प्राप्त करते हैं, इस परत के आइकन के लिए स्केच मेटाडेटा , और यदि हम एक प्रयोग पृष्ठ के साथ काम कर रहे हैं, तो ए / बी परीक्षण का नाम और इस आइकन का एक संस्करण ।

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

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

संसाधित किए जा रहे प्रत्येक ब्रांड- assetsMetadata स्केच फ़ाइल के लिए, हम एक assetsMetadata ऑब्जेक्ट बनाते हैं जो इस तरह दिखता है:

 { "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 फ़ंक्शन में, हम assetsMetadata फ़ाइल के रूप में एक समय में एक assetsMetadata वापस नहीं करते हैं। इसके बजाय, हम वस्तुओं का एक गहरा मर्ज करते हैं - हम उन्हें जोड़ते हैं और एक एकल assetsMetadata वस्तु वापस करते हैं।

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

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

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

जैसा कि आप generateAssets[format][platform] गए मापदंडों की संख्या से लेकर generateAssets[format][platform] कार्यों तक देख सकते हैं, पाइपलाइन का यह हिस्सा सबसे जटिल है। यह वह जगह है जहां प्रक्रिया मंच के आधार पर टूटने और बदलने लगती है। नीचे आपको पूरी तरह से स्क्रिप्ट का तार्किक पाठ्यक्रम दिखाई देगा और संसाधन निर्माण से संबंधित भाग को तीन समान लेकिन विभिन्न प्रक्रियाओं में विभाजित किया गया है:

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

एंड्रॉइड के लिए फ़ाइलों को उत्पन्न करने के लिए, आपको एक अतिरिक्त कार्रवाई करने की आवश्यकता है (इसके बारे में थोड़ी देर बाद): हम प्रत्येक परत की fill-rule संपत्ति को even-odd से non-zero (यह JSON ऑब्जेक्ट की windingRule गुण द्वारा नियंत्रित किया जाता है, जिसमें 1 का अर्थ "विषम / सम" है , और 0 "शून्य के बराबर नहीं है")।

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

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

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

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

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

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

IOS के लिए PDF

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

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

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

वेब के मामले में, हम एसवीजीआर लाइब्रेरी नोड का उपयोग करते हैं, जो आपको एसवीजी को रिएक्ट घटकों में बदलने की अनुमति देता है। हालाँकि, हम अचानक कुछ करना चाहते हैं: "गतिशील रूप से रंगीन" आइकन को रनटाइम पर (रंगों को टोकन से लिया जाता है)। ऐसा करने के लिए, परिवर्तित करने से पहले, हम वैक्टर के लिए fill मूल्यों को बदलते हैं, जिसमें सामान्य शैली को पहले इस शैली के अनुरूप टोकन से मूल्यों पर लागू किया गया था।

तो अगर स्केच से निर्यात की गई बैज-फीचर- like.svg फाइल इस तरह दिखती है:

 <?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> ); };

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

यह प्रतिस्थापन स्केच मेटाडेटा के लिए धन्यवाद है परिसंपत्तियों की संपत्ति के लिए assetsMetadata ऑब्जेक्ट: पुनरावर्ती रूप से परतों के माध्यम से जा रहे हैं, आप एक डोम चयनकर्ता बना सकते हैं (ऊपर दिए गए उदाहरण के लिए, #badge-feature-like #circle #Icons #badge-feature-like #circle ) और इसका उपयोग एसवीजी पेड़ में एक नोड की खोज करने और इसके मूल्य को बदलने के लिए करें। fill विशेषता (इसके लिए हमें जयकार पुस्तकालय की आवश्यकता है)।

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

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

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

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

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

लेकिन यह भूलना और गलती करना आसान है। इसलिए, हमने एंड्रॉइड के लिए प्रक्रिया में एक अतिरिक्त कदम जोड़ने का फैसला किया, जिस पर JSON में सभी वैक्टर स्वचालित रूप से non-zero परिवर्तित हो जाते हैं। ऐसा इसलिए किया जाता है कि एसवीजी को आइकन निर्यात करते समय वे पहले से ही आवश्यक प्रारूप में होते हैं, और प्रत्येक बनाए गए वेक्टरड्राएबल ऑब्जेक्ट को एंड्रॉइड 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>

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

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

JSON शब्दकोश एक संसाधन पुस्तकालय के रूप में

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

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

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

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

शब्दकोश ब्रांड और मंच के लिए गंतव्य फ़ोल्डर में JSON प्रारूप में सहेजा गया है । यहाँ, उदाहरण के लिए, मोबाइल वेब के लिए Blendr एप्लिकेशन के लिए बनाई गई संपत्ति ।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 फ़ोल्डरों की उपस्थिति दिखा रहा है:

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

प्लेटफ़ॉर्म कैसे प्राप्त करते हैं और संसाधन संसाधित करते हैं (इस उद्देश्य के लिए विशेष रूप से बनाई गई कस्टम स्क्रिप्ट का उपयोग करके) इस लेख के दायरे से परे नहीं जाते हैं। और यह प्रश्न संभवतः मेरे सहयोगियों में से किसी एक पोस्ट में शामिल किया जाएगा।

निष्कर्ष (और सबक सीखा)

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

मैं, कई अन्य लोगों की तरह , इस तरह की (आदर्श) प्रक्रिया के लिए हमेशा तैयार रहता हूं:

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

इसलिए, इस परियोजना ने मुझे आश्वस्त किया। पूरी तरह से नहीं, लेकिन कई मायनों में।

यद्यपि स्केच अपने एपीआई को नहीं खोलता है, लेकिन इसकी फ़ाइलों की आंतरिक संरचना का बहुत ही उपकरण एक प्रकार का "अनौपचारिक" एपीआई के रूप में कार्य करता है। निर्माता JSON ऑब्जेक्ट्स में एन्क्रिप्ट किए गए नामों का उपयोग कर सकते हैं या चाबियाँ छिपा सकते हैं, लेकिन इसके बजाय वे एक स्पष्ट, पठनीय और वैचारिक नामकरण सम्मेलन का पालन करते हैं। मुझे नहीं लगता कि यह कोई दुर्घटना है।

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

( , ) , Sketch- Cosmos « » — - Cosmos. , ( ; , — ). , — , , .

, Sketch- , , MVP-, . , , . , , -, — , . , .

: , . , .

, , — . , , , (, A/B-), Node.js Sketch.

! .

(Mobile Web), , (Android) (iOS), .

, ! .

स्केच + Node.js: कई प्लेटफार्मों और ब्रांडों के लिए आइकन उत्पन्न करते हैं। भाग २