React is just an abstraction of a State -> View function.
While not universally applicable, it's very convenient during development to focus on State without thinking about View, or focus on View without thinking about State.
The concept itself has nothing to do with the actual renderer: HTML, TUI, or whatever. You can render your state to a text file if you want to.
So the flickering is caused either by a faulty renderer, or by using a render target (terminal) that is incompatible with the UI behavior (frequent partial re-renders, outputting a lot of text etc.)
We're doing something similar using Prisma.
We have a script that queries Postgres database periodically and generates a Prisma schema for the tables/columns.
Then the script diffs previous schema with a newer one and if any changes are detected, it creates an SQL migration and commits it to the git repo.
That way we have a history of all changes in a very readable way, and an always up-to-date Prisma schema and TypeScript typings for the DB client.
If you describe the workflow for the production DB, then yes, that's exacly how it works.
But we also need a way to fiddle with the dev environment, while keeping track of everything that happened during development phase and making sure that it can be applied to the production DB in a single command with little room for errors.
Having a git repo in sync with the DB and a full history of changes in commit log helps a lot.
While not universally applicable, it's very convenient during development to focus on State without thinking about View, or focus on View without thinking about State.
The concept itself has nothing to do with the actual renderer: HTML, TUI, or whatever. You can render your state to a text file if you want to.
So the flickering is caused either by a faulty renderer, or by using a render target (terminal) that is incompatible with the UI behavior (frequent partial re-renders, outputting a lot of text etc.)