Structuring Component Translators

How to structure your Component Translator projects is critical to fast, scalable development. Before taking a look at the details of Lua, it’s good to understand how to organize functions and modules in the Translator.

Each Translator project is made up of different types of files. Knowing how those files relate to each other and using the concept of separation of concerns is key to determining how to structure your projects.

In general, what files make up a Translator project?

Main.lua is called when you start a component. Every other file in your project is called from main.lua. Best practice is to keep this like a table of contents, as small and easy to read as possible.

Local files are used for creating functions that are specific to a single component. They help separate concerns ensuring your project remains easy to read and maintain.

Keep local files small.

Give them descriptive names.

Every project has a config.json file you can use to create custom fields. This is where you should store component or environment-specific configurations.

For more details, see Configuration Management.

Libraries contain common code that can be used by multiple components - a key strategy in creating component templates and speeding up interface development.

In general, if you use a function in more than one interface, it belongs in a library.

If you have any libraries added to a project, a .gitmodules file automatically updates to list any referenced libraries.

The Samples folder holds all of the sample messages you need to use to develop and test your interfaces. The sample data also powers other Translator development tools like the annotations and auto-complete.