:format as text needs a checkbox to disable JSON formatting

Hi, hoping some people can upvote my ideaboard post: Bubble | Build Powerful Full-Stack Apps Without Code

:format as text adds \n. This is a phenomenal pain in the ass when using format as text to structure arrays of objects in API calls.

For example:


After constructing this JSON structure for an API call, Bubble rubs salt in the wound and requires me to remove all of the line breaks that are inside any :format as text operators else the call won’t work! Seems like a checkbox to disable this behaviour would be such a simple solution.

The current best way to do it for me is to:

  1. Open the :format as text text inside the rich text editor
  2. Copy the contents of the RTE into a tool that removes line breaks
  3. Paste the line break removed content back into RTE
  4. Save
3 Likes

Is it the :format as text doing the /n or is it the API Connector?

It would make sense if the API connector was trying to preserve the line breaks.

Which is rlly annoying because it should behave like adding line breaks directly in the API Connector body or have a checkbox

Yep, I agree with you !

Had a similar issue using Algolia’s API. I wanted to use :formatted-as-text as it would have made me gain a lot of time, but kept getting error.

Turns out the error were coming from the :formatted-as-text that adds a bunch on characters that were breaking my API Call.

Idea upvoted !

:format as text

If you have [List]:format as text with the following inside the format as text:

This
Is
An
Example

then :format as text returns

This\n
Is\n
An\n
Example

or

This\nIs\nAn\nExample

I haven’t worked out exactly which one of those it is but either way it breaks the JSON formatting.

1 Like

You know what makes it even worse?

This :format as text has a line break after the final }, but Bubble will only show you that when you click on it.

Well that explains why in a plugin I had to do :find&replace on /n among other things… never knew why i needed to add it until now

Maybe I should’ve just done that instead of finding all of the line breaks :man_facepalming:

Disagree, because 1. additional runtime processing, and possible 2. would nuke valid \n inside multiline fields with JSON-safe

Haha, I was joking - this wouldn’t matter for my use case though. I’m generating resumes which don’t need multi-paragraph inputs:

(For anyone that happens to search ‘resume’ or ‘CV’ on this forum for advice and finds this post, Getting Started — JSON Resume is a wonderful place to start)

Out of interest, do you think this would be significant? A simple find-and-replace on about 5000 characters would be pretty negligible no? I’ve never tested but I know you work a lot with plugins where you’ve probably worked out how much processing time this requires…

1 Like

Haha I missed the joke, but still a net gain considering you wrote some more :grin:

Yes it’s small, but why waste a small number of WU when they cost something :laughing:

1 Like