This repo is designed to show how to the sample Flutter Counter App works with code generation from Parabeac-Core. You can go through the hello world guide here.
Before trying to understand how this project works, be sure you are already aware of the following technologies:
https://www.figma.com/file/Ysnjcij14HaE98ucq1iwW1/Parabeac-Counter-App-Demo?node-id=0%3A1
The main thing to understand with using Parabeac generated code is that static UI code should be owned by the designer, business logic and state management should be owned by the developer. Parabeac prints out .g files for the static UI code and sends changes to these files continously. Parabeac also generates non .g widget files but only one time and only for widgets that will contain business logic. To do this, in your design program you must label a UI group or element as <custom>. This generates the boilerplate needed to add functionality. Once this non .g file is generated or exists, it will never be re-generated from Parabeac.
With this in mind, we need to seperate UI from business logic and state management as much as possible (which is usually a good thing anyways). You'll often see your codebase follow the following pattern:
If you need to create some value, or "App State" that a clicked button will modify. You can do that by wrapping the generated UI in a provider. In the provider you can create the value that the button can then access. By labeling the button as <custom> in the design file, we have generated boilerplate for us to write code as a developer to communicate with the provider. In this project, you can see this pattern broken down in the following image:
For a deeper look, let's look at the specifics in this project example. In this project you will find the following files that were gerenated from Parabeac-Core.
- my_app_screen.g.dart
- counter_value_text.g.dart
- responsive_orientation_builder.g.dart For this example we will ignore this file
- counter_button.dart
- counter_value_holder.dart
- counter_cubit.dart
- main.dart
We will now go over each file and touch on what's going on here.
This screen contains references to counter_button.dart & counter_value_holder.dart, these references were generated by a designer calling the UI elements <custom>.
This screen also contains a reference to counter_value_text.g.dart. You'll notice as we dig through the files that this reference won't be used, but it's useful that the UI component itself was seperated into it's own component to be reused anywhere in the codebase. We'll specifically revisit this in counter_value_holder.dart
This component was generated because there is a shared element (component/symbol) in the design file. This is powerful because it be used by both existing .g files & by any of the developer written files.
This is the first non-generated dart file that we, the developer created. It's a simple cubit designed to hold the state value and have a function to increment it.
This is the main dart file for the Flutter project. It contains the MyAppScreen widget & it's wrapped in our CounterCubit for children widgets to utilize.
This is the first generated but non .g file that we are going over. Originally, this widget is printed out in the build method as the following:
Widget build(BuildContext context) {
return widget.child;
}
Because this widget is supposed to be a button, we wrap it in a GestureDetector(). In our onTap() we call the increment() function from the CounterCubit. We don't change the visual output of this button, we just wrap widget.child.
This is another widget that was originally generated by Parabeac but was then edited by Parabeac. In this case, unlike the CounterButton() we don't reutilize widget.child because we need to override this code. Luckily, because we seperated the UI that was going to be placed here in a shared element (Component/Symbol), we can still utilize this in a reusable way.
Rather than returning widget.child we return similar code to what's written in the original my_app_screen.g.dart file. First, a LayoutBuilder() because components sizing needs to be based on a relative (Eddie please confirm here) context. Then as the child of the LayoutBuilder() a CounterValueText() except rather then setting a default value like '0', we provide it the value from the CounterCubit. This now allows designers to change the look of the CounterValueText component and have it reflected through the use of Parabeac without breaking developer logic.
Be sure to join us in our Discord server & let us know what you think!