- How should I think about scaffolds? What should my mental model be, or what’s their intended use case? Do they have a long lifespan? I know they’re easy CRUDs and could stay that way for the life of our app, but it seems like we could also refactor them into our real UI.
- If our intention isn’t to refactor them but to keep them as CRUDs, is it possible to specify a prefix? E.g. instead of
yarn rw g scaffold post, I could run
yarn rw g scaffold post --prefix admin, that way
postand the like are still available names, for my real UI components.
Scaffolds look amazing. The tutorial gets that across, especially coming from npx create-react-app land, which is where I hail from.
I know scaffolds are easy CRUDs, but it seems like they’re for a lot more. Pulling from the tutorial (here, after we
yarn rw g scaffold post–and a scaffold’s name has to be a table name right?), there seems to be two post-generate lives they could lead:
We can start replacing [the pages generated by
yarn rw g scaffold post] one by one as we get designs, or maybe move them to the admin section of our site and build our own display pages from scratch.
So they could 1) be refactored or 2) moved to the admin section. Is there a 3? And what does maybe moving them to the admin section comprise? Just renaming them, changing routes? Scaffolds aren’t just training wheels to be shed as soon as we get some data in are they?
I think one of the things that leads me to write this is, after making a
model Note in my
schema.prisma file, I ran a
yarn rw g scaffold note (after saving and upping the db), and yes, that gave me a great CRUD for adding some notes, but now, as I go to work on my app’s real UI, I have to make a new, fake name for my components?
Notes.js are already taken by the scaffold. And I don’t want to refactor those just yet because they’re my CRUD.
So I thought if we could add a prefix to the scaffold name, that’d be a problem solved. Or am I missing something?
Thanks for all the great work! This framework came at a great time for me as an aspiring, albeit pretty-confused developer who doesn’t really know how to think about, let alone build a backend for the various-possible and ever-growing frontend frameworks that seem to rule the web today.