Four bugs from building a Flutter and Next.js code generator

Underpeaks is a headless CMS that automatically creates Flutter and Next.js applications from shared data models. The author of Underpeaks has encountered a few bugs during early testing, with each issue influencing their approach to building the platform.

1. A UI flag intended to hide a model's primary key field was initially used for both the admin UI and public API responses. This led to a crash in generated Flutter apps when the API returned a null primary key where a string was expected. To resolve this, a new rule was implemented to omit hidden fields from API responses, except for the primary key, ensuring that the primary key is always present in the response.

2. Initially, the generator only generated CRUD routes (create, detail, edit, and delete) for pages displayed in the bottom navigation bar. When a list page wasn't part of the navigation bar, it missed out on these generated routes. This bug was fixed by deriving routes from all pages capable of having CRUD actions, rather than relying on the navigation list, ensuring that routes are generated based on the actual structure of the application.

3. Flutter's NavigationBar expects at least two destinations. When the generator was used to create a single bottom-nav page, it produced code that failed in debug mode, while a page with no navigation resulted in an empty bar. To address this, the generator now only emits the NavigationBar shell when there are two or more destinations.

Material design guidelines recommend a range of three to five destinations, indicating that the generator should adapt based on user input, rather than relying solely on the generator's handling post-creation.

4. The author's theme data, stored as a single row containing colors, typography, spacing, and feature flags, was replaced wholesale upon saving. This approach worked initially as there was only one editor. However, when more editors were introduced, the flags needed to reside independently for easier updates and maintenance. To resolve this, the feature flags were separated into their own page outside the provider, preventing overwriting of other data.

This required updates to the API, endpoint changes, and database migrations to accommodate the new structure. The lesson learned here is that data with independent changes should be stored separately to avoid conflicts and the need for multiple migrations.

The author concludes by advising to clearly define the single responsibility of each flag, derive structural requirements from the application's true structure rather than presentation, place constraints within the editor to guide user behavior, and split data storage according to the frequency of changes to minimize future migration efforts.