Why and when do we need to flatten JSON objects?

问题:

I am surprised that no one on st asked this question before.

Looking through Json object documentation and a quick google search did not yield satisfactory results.

What's the advantage of it? How it works?

---

Edit: To make it clear, take a look at this flatten/un-flatten example.

Fastest way to flatten / un-flatten nested JSON objects

Thank you.

回答1:

There are many situations where you get JSON text that was automatically built by some library. Throughout the programming languages, there are many libraries that build JSON text (one example is here).

Whenever libraries add some additional object or array wrappings, you might want to get rid of them maybe because you send the JSON to the server and your code there crashes because it expects a primitive value instead of an object (or an array). Or, if your JSON is a server response, you don't want the resulting Javascript code having to differ between object/array or not object/array. In all these cases, flattening is helpful as it will save you time. You will have to implement lesser if/elses, and you can reliably expect your data structure to be as flat as possible.

The other approach to improve code for the scenario mentioned is to write the code in a maximal robust way so there is no way for it to crash by superfluous wrappings ever. So always expect some wrappers and get it's contents. Then, flattening is not needed.

You see, it depends on what is building the JSON and what is parsing it. The building may be out of your scope.

This leads also to data model questions. I've worked with XML code that needed to be parsed quiet a different way if there where 0 entries of some XY, or if there were >0 entries of some XY. Having a wrapper that is allowed to have 0 or more entries of some XY will make live easier. These are data model desicions.

In all cases where the JSON represents an object structure that I've combined manually, I expect it not to change. So flattening something I've designed in detail would be disturbing. Standard operations as far I've seen them do not need flattening (e.g. JSON.stringify(), json_encode() etc.)

回答2:

Here's a simple scenario: In a web app you have an HTTP POST that is updating a complex relational object.

POST
update=1
&user.id=12345
&user.email=[e-mail]
&user.profile.name=Mr. Test
&user.profile.age=42
&user.profile.friend.0.email=[e-mail]
&user.profile.friend.1.email=[e-mail]
&user.profile.friend.2.email=[e-mail]
&user.profile.skill.0.id=100
&user.profile.skill.0.name=javascript
&user.profile.skill.1.id=200
&user.profile.skill.1.name=piano

Everything is already in a flat structure, so why not have a simple one-to-one binding? If you had a list of constraints or security requirements that you needed to enforce you could validate them by searching directly on the sorted key list.

Flat structures are easier for people to understand and work with there's even some cross-over with database de-normalisation. It also allows for context specific security and constraints to be implemented in a readable, but more verbose way.

When showing a user's view in full you may want to hide the display of the primary key ID for the user's list of skills.

"user.profile.skill.#.id": { hidden: true, readonly: true }

But when looking directly at a skill (to possibly edit it as an administrator) you may want to see the ID.

"skill.id": { readonly: true }

If you were writing a user-centric/self-service type CMS application you'd get more users on board and able to contribute using a straightforward flat model (flat abstraction of the underlying nested relational model) than you would with just the nested model.

TLDR: Flat is easier to read than nested. While programmers can handle nested schemas, recursive parsing and processing; end-users and admins usually prefer that part abstracted away.