Posterior a observar en diferentes repositorios y foros de internet al concluir hemos hallado la resolución que te enseñaremos ahora.
Solución:
Hay muchas situaciones en las que obtiene texto JSON creado automáticamente por alguna biblioteca. A lo largo de los lenguajes de programación, hay muchas bibliotecas que crean texto JSON (aquí hay un ejemplo).
Cada vez que las bibliotecas agregan algún objeto adicional o array envoltorios, es posible que desee deshacerse de ellos tal vez porque envía el JSON al servidor y su código falla porque espera un valor primitivo en lugar de un objeto (o un array). O, si su JSON es una respuesta del servidor, no desea que el código Javascript resultante tenga que diferir entre objeto/array o no objetar/array. En todos estos casos, el aplanamiento es útil ya que le ahorrará tiempo. Tendrá que implementar menos if/elses, y puede esperar de manera confiable que su estructura de datos sea lo más plana posible.
El otro enfoque para mejorar el código para el escenario mencionado es escribir el código de una manera robusta máxima para que no haya forma de que se bloquee por envoltorios superfluos nunca. Así que siempre espere algunos envoltorios y obtenga su contenido. Entonces, no es necesario aplanar.
Verá, depende de qué está construyendo el JSON y qué lo está analizando. El edificio puede estar fuera de su alcance.
Esto lleva también a preguntas sobre el modelo de datos. Trabajé con código XML que necesitaba ser analizado de forma diferente si había 0 entradas de algún XY, o si había > 0 entradas de algún XY. Tener un contenedor que pueda tener 0 o más entradas de algún XY facilitará la vida. Estas son decisiones del modelo de datos.
En todos los casos en los que el JSON representa una estructura de objeto que he combinado manualmente, espero que no cambiar. Así que aplanar algo que he diseñado en detalle sería perturbador. Las operaciones estándar, hasta donde las he visto, no necesitan aplanarse (por ejemplo, JSON.stringify(), json_encode() etc)
Aquí hay un escenario simple: en una aplicación web, tiene un HTTP POST que está actualizando un objeto relacional complejo.
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
Todo ya está en una estructura plana, entonces, ¿por qué no tener un enlace uno a uno simple? Si tenía una lista de restricciones o requisitos de seguridad que necesitaba hacer cumplir, podía validarlos buscando directamente en el listado ordenado. key lista.
Las estructuras planas son más fáciles de entender para las personas y trabajar con ellas, incluso hay algunos cruces con la desnormalización de la base de datos. También permite que la seguridad y las restricciones específicas del contexto se implementen de una manera legible, pero más detallada.
Al mostrar la vista de un usuario en su totalidad, es posible que desee ocultar la visualización de la vista principal key ID para la lista de habilidades del usuario.
"user.profile.skill.#.id": hidden: true, readonly: true
Pero cuando mira directamente una habilidad (para posiblemente editarla como administrador), es posible que desee ver la ID.
"skill.id": readonly: true
Si estuviera escribiendo una aplicación de CMS de tipo autoservicio/centrada en el usuario, conseguiría que más usuarios participaran y pudieran contribuir utilizando un modelo plano directo (abstracción plana del modelo relacional anidado subyacente) de lo que lo haría solo con el modelo anidado .
TLDR: plano es más fácil de leer que anidado. Si bien los programadores pueden manejar esquemas anidados, análisis y procesamiento recursivos; los usuarios finales y los administradores generalmente prefieren esa parte abstraída.
Aquí tienes las reseñas y valoraciones
Eres capaz de corroborar nuestra investigación exponiendo un comentario o dejando una valoración te damos la bienvenida.