Add `pretty_generated` option for `code` fields

[Paul-Bob]

Context

Currently, it’s a common pattern to use format_using alongside update_using to render a prettified version of a code field's content while ensuring valid parsing on update. A typical example involves formatting JSON fields like so:

field :body, as: :code,
  format_using: -> {
    JSON.pretty_generate(JSON.parse(value.to_json))
  },
  update_using: -> {
    JSON.parse(value)
  }

This approach, while effective, introduces redundancy and boilerplate code. To streamline this, we propose adding a first-party pretty_generated option, allowing developers to enable this behavior with a simple flag:

field :body, as: :code, pretty_generated: true

[ObiWanKeoni]

Hi @Paul-Bob 👋
Can I suggest a new JSON field that inherits from code_field and has this option?

Thought being that when we render things like custom_css, pretty_generated would have no (or perhaps disastrous) effects when attempting to pretty generate a json value. I think having a json field would also allow us to infer the language as javascript for syntax highlighting and have conditional rendering if, by chance, an app used a text field instead of JSONB and wanted to render it as pretty JSON.

TL;DR instead of:

field :body, as: :code, pretty_generated: true

maybe

field :body, as: :json, pretty_generated: true

What do you think?

[Paul-Bob]

Hi @ObiWanKeoni

Can I suggest a new JSON field that inherits from code_field and has this option?

Suggestions and feedback are always welcome!

Thought being that when we render things like custom_css, pretty_generated would have no (or perhaps disastrous) effects when attempting to pretty generate a json value.

You're right. This option needs to be well-documented in terms of when to use it. It's intended for a specific use case, and the documentation should explicitly clarify that. To be honest, format_using and update_using already provide great flexibility, while pretty_generated is meant to be an option to reduce boilerplate code in a specific, common scenario.

I think having a json field would also allow us to infer the language as javascript for syntax highlighting and have conditional rendering if, by chance, an app used a text field instead of JSONB and wanted to render it as pretty JSON.

Have you encountered such use cases before? Could you elaborate on the scenario?

Thank you!

[ObiWanKeoni]

Have you encountered such use cases before? Could you elaborate on the scenario?

Absolutely, I encounter this regularly. I have JSON fields all over my applications where this pattern would be extremely useful. Currently I'm implementing this boilerplate in numerous places:

field :input, as: :code, stacked: true, theme: 'material-darker', language: 'javascript',
                   format_using: -> { value.is_a?(Hash) ? JSON.pretty_generate(value) : value },
                   update_using: -> { value.is_a?(String) ? JSON.parse(value) : value }

The use case is very common with APIs and data processing applications. We receive JSON data (often as a Hash), need to display it pretty-printed in the UI for readability, but then parse it back when saving - nothing you're unfamiliar with I'm sure.

This pattern repeats so much that I've considered creating a custom field type just for this purpose especially since changing some of this data across json fields is tedious (even if it's a trivial find/replace). But I believe having it upstream would benefit many developers beyond my organization.

The proposed :json field would:

1. Default to JavaScript highlighting
2. Handle pretty printing automatically (or with an option)
3. Manage conversions between strings and Hash objects
4. Provide a cleaner, more semantic API for what is fundamentally a JSON-specific operation

The last item I think is the main point I'm making - if we are going to add options for JSON-specific representations, we might benefit from extracting that into a separate field since JSON carries different semantics than a base code representation anyway.

Ultimately though, I'm comfortable implementing my own version of this if necessary

Thanks @Paul-Bob - as always, really appreciate the work you are doing here. Love the product

[Paul-Bob]

I understand the suggested direction.

We intend to keep the :json field to implement it with an advanced JSON editor.

Thank you for the context.

Default to JavaScript highlighting

The code field already defaults to javascript (source code)

I'm comfortable implementing my own version of this if necessary

A simple way to implement this on your end is to override the field method when as is set to :json. You can achieve this by ejecting Avo::BaseResource and modifying its behavior accordingly.

Here's a suggested approach:

Step 1: Create a Custom BaseResource

Generate the following file:

# app/avo/base_resource.rb
module Avo
  class BaseResource < Avo::Resources::Base
    def field(id, as: :text, **kwargs)
      return super if as != :json

      super id,
        as: :code,
        stacked: true,
        theme: 'material-darker',
        format_using: -> { value.is_a?(Hash) ? JSON.pretty_generate(value) : value },
        update_using: -> { value.is_a?(String) ? JSON.parse(value) : value },
        **kwargs
    end
  end
end

Step 2: Use the Custom Field in Your Resource

Now, you can use this custom behavior in your resource:

# app/avo/resources/city.rb
class Avo::Resources::City < Avo::BaseResource
  def fields
    field :input, as: :json
  end
end

Thanks @Paul-Bob - as always, really appreciate the work you are doing here. Love the product

Thank you for being an awesome community member!

[adrianthedev]

Yeah, @ObiWanKeoni. You make great points with what the code field would look like if it were to render json data.

We'd like to keep the json field to something more specific, and ideally an improved editor like this one. Maybe something even better...

[ObiWanKeoni]

Interesting! Thanks for heads up regarding the JSON Editor! I actually had already done something of that nature early in implementing Avo but have yet to find a json editor that can provide a better UX than just editing the JSON inline (for context, we use really large payloads that make the editor both slow and hard to reason about because we have to scroll a bunch and lose context about what level we're in)

The code field already defaults to javascript

Right, yes - I don't like assuming that will be the case in perpetuity though 😄

Here's a suggested approach

Thank you! This is a really cool implementation. What I ended up doing was:

class Avo::Fields::JsonField < Avo::Fields::CodeField
  def initialize(name, **args, &)
    super

    @theme = args[:theme].present? ? args[:theme].to_s : 'material-darker'
    @format_using = args[:format_using] || -> { value.is_a?(Hash) ? JSON.pretty_generate(value) : value }
    @update_using = args[:update_using] || -> { value.is_a?(String) ? JSON.parse(value) : value }
  end

  def view_component_name
    'CodeField'
  end
end

Which works for what I need 😁

I appreciate you both!

[adrianthedev]

That's awesome as well! Love the hacking!

[zhephyn]

@Paul-Bob Taking this up for assignment