Hello Thunkers,
Here is our Deep Dive series on Modules and Logic Modules
Overview
Modules and Logic Modules are both great at making your components and blocks look clean as well as reduce redundancy.
Modules are a combination of components and blocks that get bundled together as a singular unit that can be used across multiple screens and projects. This means that if you want to develop a feature for your app that requires overlapping components, once built as a module, you don’t have to worry about the components position relative to each other nor having to rebuild it with precision if needed on other screens or projects.
Beyond the components aspect, it also helps reduce the amount of blocks on your screen. Often with advanced features that require many blocks on your screen, it will led to some amount of clutter. With building it out in a module first, only the necessary blocks will be exposed and the background blocks will be hidden away. This will also reduce worry of accidentally changing or moving a block that wasn’t meant to be moved as all the important blocks in the background will be untouchable in a different location.
Here is a short recommendation of how each aspect of the modules/logic modules should be used.
Properties
TLDR; think of properties as the green blocks for all the native thunkable components we have. Properties for your modules should ideally follow similar principles. It should be used for text/simple changeables.
This is best used if you want to have something preset before the app is launched or if you want a label, list, or a component with a text element to be easily changed. For example, if you have a simple module that is structured like a business card, you would want the name, email, business name to changeable depending on the person using the app. Those would then be three properties you would create for your module and you would change the values in the blocks. Alternatively, if you created a module that is a list of all the foods that a vendor is selling, that list of food is typically set ahead of the time. So, here you would type in the all foods in the properties panel of the module once imported into your project, or within the properties section within the modules wizard when creating.
One example advanced use would be having toggleable modes or looks. Using business cards as an example again, there are many templates or business card structure looks. You could have a property that determines what kind of business card is displayed. For example, let’s say the property is called “card_type”, you would have in the blocks something like “if card_type = casual, then [display casual business card blocks here] else if card_type = professional …”.
Events
TLDR; Events lets your module know when you send information to you in your project.
Events lets you trigger an action outside of the module. The best way to think about how to use events would be to consider when you would like your module to report back to you. For example, once your module starts, if you don’t need to hear back from your module, then you don’t need any events. But let’s say that you would like your module to tell you when it’s done or when it’s hit a certain point in its operation, that would be good area to use an event. Alongside reporting to you, it can also pass along information. For example, if you want your module to report to you when it’s done, but you also want the end result, you would add a parameter to the event. This information will then be pass to you to use in your project outside of the module.
Methods
Methods lets you trigger actions inside your modules. Methods are similar to events but just the reverse. You can pass instruction and information via methods.