[Suggestion] Generate Editor.js with field_partial

[Natblow]

Hi folks,

It would be nice to have another field_partial that is based on json data type.

Why

There is some js libraries that have a more robust feature set and enhanced functionality when compared to a standard rich text editor, such as Editor.js (free & OS) .

Idea

It is a common thing for certain business to produce their own billing / contract / proposals etc.

Therefore it makes sense for bullet_train, a SaaS builder, to have jsonb field_partial that will automatically setup Editor.js with stimulus.

Thoughts ?

[gazayas]

Since we have a rich editor partial in place, I can see the argument to add something like Editor.js to provide JSON output. I don't think it's priority right now, but we can wait for what other people on the team have to say. In the meantime, feel free to write up a pull request to add the new feature!

[jagthedrummer]

@Natblow I don't fully follow what you're wanting to do here, could you give an example of how you're wanting to use this? Are you specifically wanting a json data type field, or is it just that you want to use editor.js and it happens to output json?

[Natblow]

@jagthedrummer Yes, to have Editor.js automatically used.

Currently, you would do something like this to get json data type : bin/super-scaffold crud Post Project,Team content:text_area{multiple}

Then setup Editor.js to work with stimulus.

What I think would be good is: bin/super-scaffold crud Post Project,Team content:json_field or bin/super-scaffold crud Post Project,Team content:editor_field (to imply more that it will use Editor.js by default).

and voilà no need to setup the library, you'll have some default setup generated for you.

[jagthedrummer]

OK, thanks for the clarification @Natblow. I think editor_field would be better than json_field. I feel like json_field should mean something like "you get a blob of json in a text area or code editor". I think it's too general for this particular use case.

(And fwiw editor_field also seems a little too generic, but that's mostly about the far too generic naming of editor.js.)

Like @gazayas said, I don't know that we'll be able to prioritize implementing this in the short term, but we'd definitely review a PR to add it.

[jagthedrummer]

Just spit ballin' here, but with editor_field being too generic to adequately let people know what this would mean, I wonder if we should do something similar to what we did with image field.

In that case image is a kind of generic front-end to either cloudinary_image or active_storage_image depending on your configuration.

For this case I'm wondering if we should have a generic rich_text type that is a front-end to either trix or editor depending on your configuration.

(I'm also not sure that we want to build in support for every rich text editor under the sun, so maybe this isn't a great idea. Or maybe we could just build out some hooks that would allow people to implement this kind of thing more easily for themselves.)

[gazayas]

I'm also not sure that we want to build in support for every rich text editor under the sun, so maybe this isn't a great idea.

This is my main concern as well, and I think staying with the native Rails form helpers as closely as possible aligns more with the Bullet Train philosophy. Again I'm not 100% opposed to adding a new partial, but there are two reasons which would prevent me from moving forward.

1. It might not be a big issue, but I don't want to throw another dependency on our stack for field partials.
2. Since @Natblow mentions stimulus with Editor.js, I'm not sure if adding the stimulus logic will be as simple as just adding data attributes to our scaffolded partial markup, or if we'd have to do some more heavy lifting with controllers themselves.

I can't really speak to 2 without digging in myself or seeing a PR.

Or maybe we could just build out some hooks that would allow people to implement this kind of thing more easily for themselves.

This sounds more ideal from a Bullet Train perspective (at least to me). I'm not entirely sure right now what that would look like, but I'd rather opt in for this route as opposed to settling down on one specific dependency.

[jagthedrummer]

I'm 100% with you on concerns about adding more dependencies to the app, which people may or may not use.

Maybe we could establish a pattern for how to add a new field type via a gem? Like if there were a bullet_train-editor_js gem or something?

And/or it might be nice to have a generator/super-scaffold-command that would allow you to generate a new field type for your own app, and then allow you to use it in subsequent super scaffolding commands.

Like imagine you wanted to let people draw on a <canvas> object, and then you wanted to capture the contents of the canvas. And imagine this was going to be something that your app does all over the place, so you want it to be a proper field type.

It would be cool if you could generate the partials that would be used in a form by doing something like this:

rails g super_scaffold:field_type canvas_field
  # The command above would generate stuff like:
  # app/views/fields/_canvas_field.html.erb
  # app/javascript/controllers/fields/canvas_field_controller.js

And then in a later super scaffold command you could do:

rails g super_scaffold Project Team name:text_field drawing:canvas_field

[gazayas]

And/or it might be nice to have a generator/super-scaffold-command that would allow you to generate a new field type for your own app, and then allow you to use it in subsequent super scaffolding commands.

This sounds the most plausible to me (as opposed to a gem), I'm starting to get ideas now :bulb:

[Natblow]

I like the idea of a custom super-scaffold command too.

For this case I'm wondering if we should have a generic rich_text type that is a front-end to either trix or editor depending on your configuration.

and also, if we still want an Editor.js, I think I like that idea of generating through rich_text and then chose btw trix or editor.

What a nice brainstorming here :)

[olbrich]

Another editor that might be useful for textareas is https://rhino-editor.vercel.app/.