feat: Add new ReactPureJsonView component

[pgliang001]

Background
The react-json-view component is used more for displaying json data, that is, viewing mode, and often the displayed data comes from json files, json strings returned by APIs, etc.

Currently, the react-json-view component prop src only supports objects (including arrays), which requires external personnel to convert data through JSON.parse(json string). In addition, a recent commit provides big number support. The current display (JSON) data (processing results in other languages) may contain big numbers, such as 9223372036854775807, 0.0060254656709730629, etc. These are out of bounds in javascript and need to rely on third-party special packages (json-bigint, bignumber.js) for processing.

Solution
Currently, the ReactPureJsonView component (newly added) is provided, which can greatly improve the part of users who only display json data and avoid big number special processing logic. The prop src supports objects and strings. When it is an object, it is equivalent to the react-json-view component. When it is a string, (json-bigint, bignumber.js) parsing is automatically enabled by default.

Note
This component ReactPureJsonView is recommended for static data presenting. It is more friendly to this scenario. This is one of the reasons why the name contains "pure"

Code Example

 // Fetch data source(json string) from remote json file
const data: string = await fetch('data/data.json')

// Put the above result into prop `src`
return <ReactPureJsonView src={data} />

That is so easy!

Expecting to your feedback. Thank you.

[vercel]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
react-json-view	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Mar 15, 2025 4:27am

[Kikobeats]

@pgliang001 sorry for delaying the review!

Can we extend README to explain there how to import ReactPureJsonView and where to use it?

[pgliang001]

@pgliang001 sorry for delaying the review!

Can we extend README to explain there how to import ReactPureJsonView and where to use it?

Ok, i have update README file.

[Kikobeats]

@pgliang001 Thanks for adding the docs, I really appreciate that 🙏

I have some time to spend on this. Now that I understand better what you are trying to achieve, I have some concerns about making the library less immediate to use for users. Although this is necessary, I was wondering if we can reshape it to be enabled in a more direct way.

What do you think about the following implementation changes:

• When the src is a string, we just use JSON.parse (the current behaviour). We don't take advantage of non-native constructors, such as BigNumber.
• When the src is not a string, we use this approach!

In that way:

• We don't need to introduce a new constructor.
• We can drop BigNumber or any other special treatment in the code; it's not necessary anymore.

Maybe that's the thing you proposed to me at the beginning, but I didn't get it (apologies)

Waiting for your opinion 🙂

[pgliang001]

• When the src is a string, we just use JSON.parse (the current behaviour). We don't take advantage of non-native constructors, such as BigNumber.

@Kikobeats Sorry, i am busy recently.

JSON.parse cannot handle the string that a field with a big number (not BigNumber lib) in there. It is limitted !

See here

Input:

var json = '{ "value" : 9223372036854775807 }';
console.log('Input:', json);
console.log('');

console.log('built-in JSON:');
var r = JSON.parse(json);
console.log('JSON.parse(input).value : ', r.value.toString()); 

console.log('\n\nbig number JSON:');
var r1 = JSONbig.parse(json);
console.log('JSONbig.parse(input).value : ', r1.value.toString()); 

Output:

Input: { "value" : 9223372036854775807 }

built-in JSON:
JSON.parse(input).value :  9223372036854776000 

big number JSON:
JSONbig.parse(input).value :  9223372036854775807

so <ReactPureJsonView src='{"value":9223372036854775807}' /> will be parsed right, but <ReactJsonView src={JSON.parse('{"value":9223372036854775807}')} /> will not be.

More test cases:

<ReactPureJsonView src='{"value":92233720368547758071234567890123456789 }' />
<ReactPureJsonView src='{"value":92233720368547758071234567890123456789368547758071234567890123456789 }' />
<ReactPureJsonView src='{"value":92233720368547758071234567890123456789368547758071234567890123456789 }' />
<ReactPureJsonView src='{"value":0.0060254656709730629}' />

[Kikobeats]

@pgliang001 Correct, but that's the thing I'm saying: the user should be aware of that behaviour.

So if the input is a string, a simple JSON.parse will be used, with the limitations there.

If that it isn't enough, then input should be parsed by yourself, providing an object as input.

So you can control the data shape for BigNumber, Set, Map, etc, out of this library.

WDYT?

[pgliang001]

The react-json-view component is used more for displaying json data, that is, viewing mode, and often the displayed data comes from json files, json strings returned by APIs, etc.

I mentioned earlier The react-json-view component is used more for displaying json data, that is, viewing mode, and often the displayed data comes from json files, json strings returned by APIs, etc.

In many cases, the real users of this component are probably not JavaScript experts or proficient people, they may be half-baked front-end developers. When used to display an external file source, such as: a json file processed by another back-end language (Go language), who knows whether it is suitable for JSON.parse or not?

The reason for providing this component encapsulation is that I emphasized earlier that it is convenient for many users who only use it to display data.

Although different languages ​​have digital upper limits and limited precision problems, few people pay attention to the differences in data upper limits between different programming languages, and as a back-end developer, this blind spot is often ignored.

This PR introduces the possibility of processing big number, but it requires the user to determine whether the data source has big number (or other) problems. But even without this PR, providing a method to directly make json file content as component prop is also beneficial to general users.

Example (read an external JSON file)

1. Traditional:

const jsonString = readFile('...')
const data = JSONbig.parse(jsonString) // Should use 3rd party lib to parse data firstly

return <ReactJsonView src={data} bigNumber={...} />

2. New (external processing) method:

const jsonString = readFile('...')
const data = JSONbig.parse(jsonString) //  Should use 3rd party lib to parse data firstly

return <ReactPureJsonView src={data} bigNumber={...} />

3. New simple method:

const jsonString = readFile('...')

return <ReactPureJsonView src={jsonString} />

Which is more convenient? It's clear at a glance! Option 3, be out-of-box

Although the built-in bignumber.js and json-bigint third-party libraries increase the size of the entire package, as currently unable to parse string json data (including big numbers, digital precision, etc.). It provides a holistic solution to simplify the complexity of using this component.

Under certain conditions, developers hate this language limitation. Directly passing the json string to the component to "automatically" process it correctly and simplifying external intermediate conversions can reduce the unfriendliness to developers.

Make it simple and convenient !

What do you think of the above? @Kikobeats

[pgliang001]

• We don't need to introduce a new constructor.
• We can drop BigNumber or any other special treatment in the code; it's not necessary anymore.

ReactPureJsonView, the name contains Pure, which means it is more suitable for the scene, json string. At first I wanted to make it support only string (prop src). This new component(ReactPureJsonView) should be prefer for <ReactPureJsonView src={<json string not object>} /> !

Because JSON.parse or JSONbig.parse cannot parse functions, regular expressions, etc., it is also an objective fact.
This is also the limitation of this component, but it does not prevent it from solving most problems. But refer Introducing JSON, json data should be serializable and deserializable. This is also the impression held by most people, isn’t it?

If very concerned about the package size, should provide independent distribution for different scenarios? Provide a separate bundle of ReactPureJsonView. But I don't recommend it.

Ok, do we bundle ReactJsonView.js/index.js for traditional (the current behaviour) and ReactPureJsonView.js/ReactPureJsonView.esm for ReactPureJsonView isolated, that should be a good choice?

Expanding new components in the existing library only increases user convenience. If you care about third-party dependencies, we can consider expanding and publishing in another repository.

Using bignumber.js and json-bigint is just one option. We can choose other simpler general solutions (recommend the solution you think is good).

[pgliang001]

• When the src is a string, we just use JSON.parse (the current behaviour). We don't take advantage of non-native constructors, such as BigNumber.

const data = '{"value":0.0060254656709730629}'

This picture shows a data accuracy problem exposed by one of our products that is used to display data from any source (by external files or etc). Difference in the last few digits of floating point numbers

Our product provides data display (via ReactJsonView) and download (via backend API). One user found that the downloading and the displaying are different. That user seems to be confused!

[Kikobeats]

In your las example, you are passing a big int as string

Why not just provide this way?

/* check https://github.com/flightcontrolhq/superjson */
import superjson from 'superjson';

/* if your payload contains map, set, bigint, etc, use your own parser that returns an object */
<ReactJsonView src={superjson.parse(payload)} />

/* if the payload is a simple json, then you can pass it as string */
<ReactJsonView src={payload} />

What I'm interested is into make the library easier to use, not more complex.

[pgliang001]

In your las example, you are passing a big int as string

Why not just provide this way?

/* check https://github.com/flightcontrolhq/superjson */
import superjson from 'superjson';

/* if your payload contains map, set, bigint, etc, use your own parser that returns an object */
<ReactJsonView src={superjson.parse(payload)} />

/* if the payload is a simple json, then you can pass it as string */
<ReactJsonView src={payload} />

What I'm interested is into make the library easier to use, not more complex.

Yes, the new component can support your scenario in a friendly way.

Earlier, I mentioned that many people use this component to display data (json), and the source of the data is a black box for them. And they rarely pay attention to issues such as floating point precision and big number. It is a good idea to provide an internal automatic parsing to lower the user threshold.

If you need to split it into two, use external parsing for big number(or etc), and the rest are self-consistent, it is not easy. For example, in a file content viewing system, the file content is dynamic, and developer don’t know what scenario it is at any time (the above approach).

[Kikobeats]

super, then let's rename ReactPureJsonView into ReactJsonView and ship it 🙂

[pgliang001]

Show our system's simplified resource folder sample: resource_data.zip

The files with green arrows represent normal data, and the others are big number (or etc) :

[pgliang001]

super, then let's rename ReactPureJsonView into ReactJsonView and ship it 🙂

Yeah, this is the approach I hoped for and recommended the most in the early days, but when I researched and considered that parse and stringify (json) are only for serializable data types and cannot support functions(function_in_src), etc.,

So the introduction of ReactPureJsonView naming (against ReactJsonView, let pure only for seriazable data) also makes it easier for subsequent users not to be confused by the impression of traditional practices.

A new option! A new component to assist, expand, and extend. I strongly recommend that this new component be independent, Keeping the old (ReactJsonView) as it is.

Let ReactJsonView be used as it was thought in the past, and still keep it working in some scenarios, while ReactPureJsonView is more recommended for static data display (such as json file, json string, etc.), recommended for pure data display only

What do you think? @Kikobeats

[Kikobeats]

Moving the parsing responsibility out of the library not only provides more flexibility, but it also makes the library smaller.

I really don't want to expose ReactJsonView and ReactPureJsonView because keeping two implementations for something very similar does not make sense: more stuff to maintain, more bytes and ultimately it introduces user friction to understand which constructor should be use.

The data should be provided as parsed, and in case it's not passed parsed, it will be parsed using JSON.parse to maintain the old behaviour.

Additionally, we can ship this as v2, so users can continue using v1 with no disruption.

[pgliang001]

Moving the parsing responsibility out of the library not only provides more flexibility, but it also makes the library smaller.

I really don't want to expose ReactJsonView and ReactPureJsonView because keeping two implementations for something very similar does not make sense: more stuff to maintain, more bytes and ultimately it introduces user friction to understand which constructor should be use.

The data should be provided as parsed, and in case it's not passed parsed, it will be parsed using JSON.parse to maintain the old behaviour.

Additionally, we can ship this as v2, so users can continue using v1 with no disruption.

Earlier, I also wanted to extend ReactJsonView and (expect you) release it as v2 (the new major release). This PR doesn't go against such a choice (only rename ReactPureJsonView into ReactJsonView)

But if I can't simplify the process of automatically parsing JSON strings (simplifying the use of red tape, make it easier to solve all the problems involving big number, floating point out-of-bounds, etc), it defeats my main purpose.

If not, I totally agree that you can make improvements based on this PR without violating your philosophy.
Make this repository even better!

Well, thank you for communicating and learning with you these days. All the best! @Kikobeats