Scaffold <TextArea>s

Get Help and Help Others
1

Currently all prisma Strings get scaffolded out as <TextField>s. Would it make sense to be able to specify that you want a <TextArea> to be used instead? Would be nice for longer texts like blog posts.

Easiest way to support this that I could think of would be to augment the prisma schema.

model Post {
  id        Int      @id @default(autoincrement())
  title     String
  body      String ///@rw-scaffold TextArea
  readTime  Int
  rating    Float
  isPinned  Boolean ///@rw-scaffold TextField
  createdAt DateTime @default(now())
}

Is this something we would want in RW? Is the extra complexity worth it? Is there a better way to do it?

If Prisma supported a Text type we could default to <TextArea> for that, but they don’t…
There is this related issue open with Prisma

But they don’t seem to be making much progress on it :confused:

(Triple slash comments are preserved and available in the DMMF model we get from the prisma sdk)

1 Like
2

I like it!

I come from Django, which allows specifying widgets right there with the models as well. However this goes for the Django Admin Panel, not for user-facing scaffolds. I’d be curious to see how this is handled in Prisma Studio, if they ever display textareas over inputs as well, and how they configure that.

I think it could also be cool to think about how to specify custom widgets!

3

Rails had something like title:string and body:text

Scaffold would be smart enough to put a textarea

4

I wanted to do this from the start but as you found, Prisma don’t care! If schema.prisma supported some kind of Text vs String identifier we could distinguish TextArea vs Input during scaffolding. Until then I’m not sure how we’d tell (other than make everything a TextArea, which I’m not a huge fan of).

5

The only way I could think of is the way I showed in my original post, with the triple slash comments…

6

Sorry, I was in the mindset that since we’re using Prisma’s (undocumented) getDMMF() function from the SDK those comments wouldn’t get picked up and we couldn’t use them at generation time. We’d have to do some kind of custom parsing on the schema file to read them…<breaks out in cold sweat>

7

For the schema above, looking at model in scaffold.js it looks like this for body

{
      name: 'body',
      kind: 'scalar',
      isList: false,
      isRequired: true,
      isUnique: false,
      isId: false,
      isReadOnly: false,
      type: 'String',
      hasDefaultValue: false,
      isGenerated: false,
      isUpdatedAt: false,
      documentation: '@rw-scaffold TextArea'
    },

So the only custom parsing we would have to do would be of the documentation string

8

Whattttt I didn’t realize that documentation thing was populated! Okay that makes things way easier then.

And you think we should use a custom declaration like that /// @rw-scaffold TextArea vs. something like just /// text which is more of a “this is my intended DB datatype” annotation and then we trigger off that for whether to show a TextField vs TextArea? But I guess that doesn’t work in your other example where you want the Boolean field to be a TextField instead of a CheckboxField.

9

“intended DB datatype” shouldn’t be needed. Better push for those fixes upstream.
@rw-scaffold is instructions for the scaffolder (is that even a word? :slightly_smiling_face:) Just like e.g. @eslint-ignore is instructions for the linter.

Do we even want this cluttering the schema? Maybe it would be better to just add support for passing it to the scaffold cli command --component-mappings "{body: 'TextAreaField', isPinned: 'TextField'}"

10

I’d like to get @mojombo’s take on this syntax!

11

As you only scaffold once, I don’t think it makes sense to put those scaffold hints in the schema, it feels like too much clutter. I like the command line option better, but I’d prefer something like:

--field body:text --field isPinned:text

It feels weird to me to pass JSON into a command line arg.

2 Likes
12

Yeah, that’s what I started thinking too!

Nice! I like that much better than the json stuff. Not sure about the --field naming though. What was your reasoning for the name? I do like that it’s much shorter than --component-mapping :smile:

13

I was thinking that the scaffold is generating a form with a bunch of fields. By default, we’ll assign field types to those fields, but you could override the field types via command line. I suppose an alternative could be:

--type body:text

I could also imagine a way to restrict which fields are included/omitted:

--only body,status
--omit status

Basically, the mental model is a collection of fields and things you might want to change about how we handle those fields.

1 Like
14

Thank you. That makes a lot of sense :slight_smile: And with that in mind I prefer --field to --type. Plus, I think --type is more easily confused with Prisma data types.

15

Any update on this one?

16

Things are moving along on the Prisma side of things. https://github.com/prisma/prisma/issues/3447

I haven’t looked in to updating the RW scaffold cli. Is this something you’d use? What’s your usecase? The generators are fun to work on, so I’d be easy to convince to spend some time on this :wink:

17

Currently redwoodjs is generating divs instead of textarea because there is no way differentiating the difference between a long text and a short one. It would be good to have a temp solution today and when prisma has figured out how to fix this we can slowly migrate to there solution.