How to think about scaffolds?

Get Help and Help Others
1

Summary

  • 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 post and the like are still available names, for my real UI components.

How should I think about scaffolds?

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?

Prefix

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? Note and 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?

Thank you

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.

7 Likes
2

Hi @dom, thanks for the thought put into this post! Usually in open source you get a lot of “this is wrong, it should be like this” posts—yours was a very nice contrast to those. :slight_smile:

We borrowed the idea of scaffolds from Ruby on Rails where they’ve been sort of a headline feature for the framework. The interesting thing about them is that, in general, once you become more seasoned in the framework you don’t really use them any more. Scaffolding is almost more of a sales pitch feature—something that looks really impressive in a demo, but isn’t really what keeps you with a framework once you really start developing applications.

Here’s how Rails thinks about scaffolds’ place in the greater scheme of things:

While scaffolding will get you up and running quickly, the code it generates is unlikely to be a perfect fit for your application. You’ll most probably want to customize the generated code. Many experienced Rails developers avoid scaffolding entirely, preferring to write all or most of their source code from scratch. Rails, however, makes it really simple to customize templates for generated models, controllers, views and other source files.

We don’t currently make it possible for those templates to be customized, but if scaffolds are something that people are really drawn to in the framework then I think we should add that ability. (Basically, you create a template in your own code and Rails will look for the presence of that file before resorting to using the default built into the framework.)

I do like your idea of being able to add a --prefix or some other way to alter the general code enough that it doesn’t pollute your namespace, and you’re not the first person to inquire about the ability to do that.

One way may be to simply include a path where you want the generated files to live right in the name of the model itself:

yarn rw g scaffold admin/post

The last part of the path would have to match a model in your database, but everything before that would be up to you. This would put pages, components and routes in the admin subdirectory. So you still end up with PostsCell but when importing it it would be in src/components/admin/PostsCell.

Were you thinking of the --prefix flag doing the same thing? Or would it literally put a prefix in front of the generated names, like AdminPostsCell and AdminPostsPage? And the routes become something like:

<Route path="/admin-posts" page={AdminPosts} name="adminPosts" />

I’m glad this framework came at the right time for you! As a Rails developer I was myself flummoxed by how complex the Javascript ecosystem is and how all the JS developers just seem to shrug and exclaim “This is The Way.” I really pushed for some of the features in Redwood to mirror those in Rails that made the developer experience so nice. Ruby itself enables many features of Rails that will probably never be possible in Javascript, but Redwood is a huge leap in the right direction!

6 Likes
3

@rob of course! That’s the least I can do for you and the team. I’m just always interested in the creators, what their intention was or how they would use feature x.

Thanks for the background, especially as a beginner lacking Rails experience. And scaffolds are a great sales pitch; I’m certainly sold. I guess that’s why I’m interested in what people think about them. Jess Martin shared his thoughts here, and after re-watching him now, I think another way of formulating what I want to know is: is there a redwood spin (to scaffolds)? Or are they going to be the same as in Rails? You did say:

Which sounds like they’ll stay the way they are until they generate some interest?

I was thinking of the --prefix flag literally, like the latter case you mentioned of putting a prefix in front of the generated names, like AdminPostsCell and AdminPostsPages. But the subdirectory sounds better in the admin case. Is this something I could contribute to?

Another question: if the goal is to get some data in the database, is there a case to be made for scaffolds vs seed.js? Is that a fair comparison?

Thanks again; looking forward to the growth of redwood!

4

By all means, we happily accept PRs to add functionality! We’re a pretty small team and most aren’t full-time so we’ll take all the help we can get! :slight_smile:

This is another convention borrowed from Rails, naturally. :wink:

Seeds are the data that your database needs to contain for your site to work at all. So if you were creating a blog that would be something like an Admin user—you need the admin user so that you can get past the login page and actually start creating blog posts! I think of it like if you were white-labeling your app, and a new user installed it from scratch, what do they need so they can use it completely through the UI, without having to go into the database and add records manually? Maybe an initial list of tags, user roles, countries, stuff like that.

The scaffolds provide a way for you, the developer, to easily get some sample data into the database as you’re developing so you can focus on what you’re building at the time (like a simple search for your blog) without having to use the command line and/or write SQL statements. It gets you started as quickly as possible when you create a new table in your database. That sample data isn’t going to be something that future owners of your app will need, so they don’t go in seeds. But you certainly could put that there if you wanted, you may just want to leave a note so that future devs, expecting seeds to be mission-critical data, are wondering why every blog post starts with “lorem ipsum” :smile:

And like the tutorial you may find that the scaffolds provide everything you need for the admin section of your site, so you just move them there and put them behind a login.

1 Like
5

I’m new to contributing on open-source projects but pretty eager (a potentially bad combo?)–should I open an issue on github, or just make things work then submit a PR? I know both can have a back-and-forth, but I wasn’t sure if there was an etiquette/best-practice/antidote to possible-but-by-no-means-intentional toe-stepping on?

I opened and scanned scaffold.js and can kind of see what changes I’d have to make to get the admin/post functionality we threw around working. That’s the right place to make these kind of changes right?

2 Likes
6

You can just open a PR and we can discuss there!

2 Likes
7

@dom Did you open a PR yet?! You should go for it if not. :smile: We have a great community and culture to help you get going and feel comfortable learning the process.

Start with something focused, but don’t hold back because it might not be good/right/valuable – that’s what collaboration is for. :rocket:

3 Likes
8

@dom if that can motivate you to get started, that’s actually a feature I had in mind proposing! I’ll be happy to help & review if you need it :slight_smile:

9

@thedavid @olance thank you both for the encouragement! The only thing from keeping me from opening a PR was my inability to set up a local dev experience–but I think I literally just solved that. @thedavid I saw you posted in Guide on Redwood Package Development! 20d ago so I’ll follow up there to keep the discussion organized. In the future, should I have just opened the PR and worried about configuring my dev experience later?

@olance that sounds great! I’ll try to open the PR asap to get things going.

3 Likes
10

It’s always better to have a good dev environment in place to work efficiently :slight_smile:

You’ll want to add automated tests, run the existing ones to make sure you haven’t broken anything, try your new option locally and so on!

11

The very-much-a-WIP PR is up! @rob @thedavid @olance

1 Like