javascript 为什么以及何时需要展平 JSON 对象？
声明：本页面是StackOverFlow热门问题的中英对照翻译，遵循CC BY-SA 4.0协议，如果您需要使用它，必须同样遵循CC BY-SA许可，注明原文地址和作者信息，同时你必须将它归于原作者（不是我）：StackOverFlow
原文地址: http://stackoverflow.com/questions/24833379/
Warning: these are provided under cc-by-sa 4.0 license. You are free to use/share it, But you must attribute it to the original authors (not me):
StackOverFlow
Why and when do we need to flatten JSON objects?
提问by wilbeibi
I am surprised that no one on StackOverflow asked this question before.
我很惊讶之前 StackOverflow 上没有人问过这个问题。
Looking through the JSON object documentation and a quick google search did not yield satisfactory results.
查看 JSON 对象文档和快速谷歌搜索并没有产生令人满意的结果。
What's the advantage of it? How does it work?
它有什么好处？它是如何工作的？
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.
谢谢你。
采纳答案by peter_the_oak
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).
在许多情况下，您会获得由某个库自动构建的 JSON 文本。在整个编程语言中，有许多构建 JSON 文本的库（此处为一个示例）。
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.
每当库添加一些额外的对象或数组包装时，您可能想要摆脱它们，这可能是因为您将 JSON 发送到服务器并且您的代码在那里崩溃，因为它需要原始值而不是对象（或数组）。或者，如果您的 JSON 是服务器响应，您不希望生成的 Javascript 代码在对象/数组或对象/数组之间有所不同。在所有这些情况下，展平都很有帮助，因为它可以节省您的时间。您将不得不实现较少的 if/elses，并且您可以可靠地期望您的数据结构尽可能平坦。
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.
你看，这取决于构建 JSON 的内容以及解析它的内容。该建筑物可能超出您的范围。
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.
这也会导致数据模型问题。我使用过 XML 代码，如果某些 XY 有 0 个条目，或者某些 XY 有 >0 个条目，则需要以不同的方式安静地解析这些代码。拥有一个允许有 0 个或多个 XY 条目的包装器将使生活更轻松。这些是数据模型决策。
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.)
在 JSON 代表我手动组合的对象结构的所有情况下，我希望它不会改变。所以把我详细设计的东西弄平会令人不安。就我所见的标准操作而言，它们不需要展平（例如JSON.stringify()，json_encode()等）
回答by Louis Ricci
Here's a simple scenario: In a web app you have an HTTP POST that is updating a complex relational object.
这是一个简单的场景：在 Web 应用程序中，您有一个更新复杂关系对象的 HTTP POST。
POST
update=1
&user.id=12345
&[email protected]
&user.profile.name=Mr. Test
&user.profile.age=42
&[email protected]
&[email protected]
&[email protected]
&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.
完整显示用户视图时，您可能希望隐藏用户技能列表的主键 ID 的显示。
"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.
但是当直接查看技能时（可能以管理员身份对其进行编辑），您可能希望看到 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.
如果您正在编写以用户为中心/自助服务类型的 CMS 应用程序，与仅使用嵌套模型相比，您将获得更多用户参与并能够使用简单的平面模型（底层嵌套关系模型的平面抽象）做出贡献.
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.
TLDR：Flat 比嵌套更容易阅读。虽然程序员可以处理嵌套模式、递归解析和处理；最终用户和管理员通常更喜欢抽象掉的那部分。
