jsoneditor
jsoneditor copied to clipboard
Multiline String in Tree mode
Just went through the options and I could not see any for "supporting" multiline JSON string. (Yes, I am aware there is no such a thing in JSON spec however, I believe a JSON editor could make the experience less techy) Is there trick I can do to make the experience of writing a multiline string a bit more pleasant? The idea is that when editing JSON string newlines are interpreted as such then under the hood the actual JSON being edited contains the \n and \t for tabs and so on.
Thanks for your suggestion Sergio. The editor indeed simply shows characters like return and tab as \n
and \t
, as "raw", escaped characters (especially \t
is tricky in a browser). For unicode characters we do have an option to render them escaped or not. In some cases you would like to see the escaped contents to have full control, in others you would like to see the interpreted contents, requiring a more advanced text editor. Or maybe a color highlighted HTML editor. Or a fancy date picker.
I think a good solution would be to allow rendering the values you want yourself, this is proposed here: #738
Besides that we could think though whether it would make sense to have a mode "raw text contents" vs "interpreted text contents", where in the latter case \n and \r etc is rendered as a new line and a tab character.
Related discussion: #185
How about a optional feature to just ignore the special characters and not trying to escape them as /n. I know CR and LF is not allowed in JSON but I have found that in most cases the entity that consumes the JSON will handle it just fine.
Just "ignoring" it will not work: if you have a string like hello \n world
, and render it in a browser, whitespace characters like \n
are simply not rendered, you have to replace them with <br/>
for example. See the earlier mentioned discussion: https://github.com/josdejong/jsoneditor/issues/185#issuecomment-99768848
Thanks Jos. I have a web admin tool that lets the user edit raw json. But for some of the fields to be more human readable they need to be multiline. In fact some of the fields are SQL like sentences. Today I use
Using textarea
would indeed be much simpler. I've tried this long time ago, at that time I could not make that a success because you can't scale a textarea
to automatically fit its contents (instead of having a fixed size and scrollbars). So I ended up using editable DIV's instead.
Would the proposal in #738 be helpful for you @wilfreds? That would allow you to render certain values with a textarea instead of the default.
@josdejong Yes, I think that would work for me.
👍
Great. Let me know when it's possible to test this.
Sure! Beware though that the issue has been open for a long time though, will not be addressed overnight I expect.