Respresso flow conventions

To create a maintainable bunch of flows we agreed on a convention how we will build and structure our flows. We defined a categories for flows and defined sub categories for processors based on their purpose. Let’s see what are theses conventions.

Note

We recommend to you to keep this conventions in your custom flows. This will help you to build an understandable and maintainable system.

Resource category patching process

This process is the most common use case of custom flows. This defines how a Resource Category can be changed and what conversions are needed on the category. This is executed when the Save button is clicked on the web interface or after an import.

Note

For more details view Resource category make flow

Category make flow

This is the entry and exit point of the patching process. It’s responsibility is to execute the conversions and persist the changes. At the end you may add a webhook to notify the change to other systems.

Flow id naming convention: <resource_category>-make-flow

Examples:

  • appIcon-make-flow

  • color-make-flow

  • font-make-flow

Convert all resources flow

This flow is executed in the make flow and it has to convert the multi resource dependent files. (Usually a summary for the category. Eg.: Utility class for typo safe usage of the resources from code.)

Flow id naming convention: <category-name>-convert-all-resources-flow

Examples:

  • color-convert-all-resources-flow

  • localization-convert-all-resources-flow

Convert single resource flow

This flow is executed in the make flow and it has to convert the single resource dependent files. (Usually a file or bunch of files based on a single resource. Eg.: An image in multiple resolutions.)

Flow id naming convention: <category-name>-convert-single-resource-flow

Examples:

  • appIcon-convert-single-resource-flow

  • font-convert-single-resource-flow

  • image-convert-single-resource-flow

  • raw-convert-single-resource-flow

Import process

This process includes the whole make flow. It have to provide a ResourceCategoryChangeStructure which will be passed to the make process.

Basically this process is represented with only one flow as the make flow is executed after this so you don’t have to create it again.

Flow id naming convention: <resource_category>-import-<import_format_name>-flow

Examples:

  • color-import-android-xml-flow

  • color-import-aco-flow

  • localization-import-json-flow

  • localization-import-ios-strings-flow

Utility flows

In some cases you will want to reuse a flow from other flows. Eg.: A common webhook for notifying the developers or to start a CI build.

Flow id naming convention: <what-does-it-do>-utility-flow

Examples:

  • storage-file-read-utility-flow

Preview flows

In some cases the web interface may need to preview the result before executing the real make flow. In this case a preview flow can be executed which should do something similar to the converter flow except it should convert only the formats displayed on the web interface and not persist them.

Flow id naming conventions:

  • <category-name>-convert-single-resource-preview-flow

  • <category-name>-convert-all-resources-preview-flow

Examples:

  • appIcon-convert-single-resource-preview-flow

Processor categories

In these flows we defined a few processor categories based on our usage.

Parser processors

These processors has the responsibility to parse the content of a ResourceCategorySnapshotStructure and provide the parsed, resource category dependent format. This includes mapping file ids to Lazy files which will enable to easily send the file contents to remote servers.

All resources parser processors

These processors has the responsibility to parse the whole category.

Processor naming convention: All<PluralCategoryName>ParserProcessor

Examples:

  • AllLocalizationsParserProcessor

  • AllColorsParserProcessor

Single resource parser processors

These processors has the responsibility to parse a single resource within a category.

Processor naming convention: Single<CategoryName>ParserProcessor

Examples:

  • SingleAppIconParserProcessor

  • SingleRawParserProcessor

Converter processors

These processors have a single conversion responsibility. This means it will convert a well defined data to a similarly defined output format.

All resources converter processors

These processors has the responsibility to convert multiple resources at once.

Processor naming convention: All<PluralCategoryName>To<OutputFormat>ConverterProcessor

Examples:

  • AllColorsToAndroidColorXmlConverterProcessor

  • AllLocalizationsToAppleStringsConverterProcessor

  • AllLocalizationsToObjectiveCClassConverterProcessor

Single resource converter processors

These processors has the responsibility to convert a single resource.

Processor naming convention: Single<CategoryName>To<OutputFormat>ConverterProcessor

Examples:

  • SingleAppIconToAndroidRasterIconConverterProcessor

  • SingleFontToAndroidFontConverterProcessor

Data converter processors

These processors has the responsibility to convert a structure to an other structure.

Processor naming convention: <InputStructureName>To<OutputStructureName>ConverterProcessor

Examples:

  • HttpFilesToFilesConverterProcessor

  • FilesToConversionFileChangesConverterProcessor

Modifier processors

These processors has the responsibility to manipulate the content of a structure without changing it’s structure. This means it will change the content of the data passed through it.

Processors naming convention: <StructureName>[FieldName]ModifierProcessor

Examples:

  • FilesStructureGroupModifierProcessor

Remote processors

These processors has the responsibility to delegate a processing task to a remote server.

Processors naming convention: <Protocol>[ResponseStructureName]RemoteProcessor

Http processors

These processors has the capability to delegate the processing task using http protocol.

Processors naming convention: Http[ResponseStructureName]RemoteProcessor

Examples:

  • HttpFilesStructureRemoteProcessor

  • HttpRemoteProcessor

Importer processors

These processors have the responsibility to process the imported data and provide a category specific ResourceCategoryChangeStructure of the imported data according to the current resource category snapshot.

Processor naming convention: <InputFileFormat>To<CategoryName>ImportProcessor

Examples:

  • AcoToColorImportProcessor

  • AndroidColorXmlToColorImportProcessor

  • JsonToLocalizationImportProcessor

Other processors

In some cases unique processors should be created so no category should be defined for it. In this case the naming convention is only to end the name with Processor.