Discusión y Decisión sobre: Modelo y Entidad para Home-Page

[RominaRomano]

En esta issue debemos participar todos, debido a que los datos son una herramienta a la cual todos debemos tener acceso, ya sea para el armado de una vista (front estático), para darle el tipo a una variable receptora de ellos mediante un servicio (front dinámico), o para operar internamente y resolver requerimientos (back- end). Me interesa dar un ejemplo sobre este tema que pude experimentar yo misma (aunque no exactamente operé datos en el back sino que lo hice como front dinámico en mi portfolio). En el portfolio aparece mi edad. Para el front estático, esta sería una variable traída mediante un binding, para el front dinámico sería una variable de la interfaz que usará para tipar a los datos traídos para la persona, para el back, sólo será un return que calculará el resultado de años en relación a la fecha de nacimiento y la fecha actual, es decir que el modelo del back no necesariamente va a ser igual al del front. Ya que mientras el back cuenta con el atributo fecha de nacimiento en la entidad de su capa modelo (la cual procesa para retornar la edad), el front cuenta con una variable edad para recibir allí la cuestión ya resuelta. Me tomo el trabajo de ejemplificar esto, pues es importante que todos aportemos nuestras necesidades de datos desde nuestro area de trabajo, teniendo en cuenta esta decisión ya tomada de procesar datos y retornar info desde el back (lugar donde debe hacerse realmente, a mi criterio). Quiero recordarles que de esta issue NO deben sacar ninguna rama sino únicamente debatir y decidir, en esta oportunidad sobre interfaces y entidades para cargar la home page y los shareds components. Definiendo nombre, tipos, dimensiones, etcs y sobre todo explicando a qué se destina cada variable o atributo, a fin de que todos tengamos en claro qué es cada cosa cuando nos referimos a ella. Desde hoy y hasta el día viernes tenemos el tiempo para dejar definido este tema. Aprovechemos, también, para trasladar esta issue a "en proceso" y a "hecho" en cada oportunidad, como lo mostró Juanjo en el video que preparó y que está en el drive del proyecto. Una vez determinadas las interfaces y los atributos para la home page y los shareds components, cada responsable deberá tomar la issue asignada: creación de interfaz y archivo json en home, desarrollo de servicio e inyección a los TypeScripts correspondientes, el front estático deberá incluir los bindings en las respectivas vistas y el back dejar definidas las entidades con sus atributos (y métodos que surjan de este consenso, si es que surge alguna nueva necesidad).

[RominaRomano]

Dejo abierto el debate, @ArgLogan o @ArgLogan2 o juanjo jaja, necesito que agregues como colaboradores a Juanpi y a Dami del back, para que opinen y participen de este acuerdo.

[RominaRomano]

Bueno, hago el aporte desde lo que yo veo y entiendo:

Las home page y los shareds components necesitan los siguientes bindings:

nroContacto (header, wsp, footer) emailContacto (footer) horarioContacto (footer) logoGold (header) iría la url supongo logoBlack (footer) iría la url supongo logoWhite (footer2) iría la url supongo arrayFotos (home) son 12 fotos, irían las urls supongo experiencia (home) varchar larguito trayectoria (home) varchar larguito respaldo (home) varchar larguito hasta acá el front estaría completo para armar la home page y los shareds components.

---

luego, supongo que para contar con información referida a la inmobiliaria en la base de datos:

nombreInmobiliaria nombrePropietario direccionFisica (para cuando exista) nroContacto2 (por si luego quiere agregar otro teléfono) (datos que se les ocurran que deberíamos incluir en la base de datos)

los nombres son los que se me ocurrieron mientras escribía pero definan si serán en inglés, si en camelCase o UpperCamelCase, o cual otro formato. Dejo disparado para definir necesidades, estilos de nombres, tipos de variables/atributos, tamaños de variables/atributos, etcs.

[ArgLogan2]

Ya están invitados

[ArgLogan2]

Como representante del back end digo que nosotros nos adaptamos a las necesidades del front. Así que nos dicen que necesitan y nosotros hacemos un end point con esas características en la API

[ArgLogan2]

Otra cosa. Como primera medida desde el front olvídense de la base de datos. Para ustedes en el front debería ser. Necesito que la api me de estos datos en este formato. Y de la base nos ocupamos en el back. Esto va a hacer que no estén pensando en relaciones y cosas así. Creo que es mejor que piensen en que datos necesitan. Después pueden ver si quieren para no tener que consumir tantas cosas a la api si hay datos que pueden reutilizar pero eso ya es otra cosa. Piensen en datos y no en estructura de back end. Para eso separamos las tareas

[RominaRomano]

Coincidiendo con Juanjo, entonces invito al Front-end a que definan estas necesidades, fíjense que algo puse ya en el primer comentario. Talvez lo puedan usar de base para agregar, sacar, cambiar y definir exactamente los datos que van a necesitar. 😉

[miguellvc]

interface inmobiliaria { id? : Number, tel : String, email: String, contactTime logo : String[]; urlImgBanner : String[], titleBanner : String, about : About[] }

interface About{ urlImg : String, title : String, description : String }

Aquí sólo la interfaz inmobiliaria sería una entidad en la base de datos. La otra interfaz que propongo, sólo sería un campo de la interfaz inmobiliaria

• experiencia (home) varchar larguito trayectoria (home) varchar larguito respaldo (home) varchar larguito

A esto lo llamo About. El campo en la base de datos considero que debería llamarse about, allí alojaríamos un array de json, para que podamos guardar los datos de: -La imagen. -El título. -La descripción.

[RominaRomano]

que

Buenísimo Miguel, gracias!! Es necesario que opinen los demás, así van definiendo la cuestión. 😉

[miguellvc]

Seguiendo con lo que dice Juan. En principio, según lo que imagino, la data desde el back tiene que venir así:

inmobiliaria[ { id: 01 tel : 3804-99999, email : inmobiliariafrancolujan@gmail.com, contactTime: 08:00 a 17:00 logo : [urlImgLogoGold, urlImgLogoBlack, etc], urlImgBanner : [urlImg1, urlImg2, urlImg3], titleBanner : ¡Tenemos lo que buscás!, about [{ urlImg : XXXXX, tite : XXXXX, description: XXXX, }, { urlImg : XXXXX, tite : XXXXX, description: XXXX, }] } ]

Claro que habría que probar primero esa estructura y para ello necesitariamos el json local.

[leoolmedo]

Hola a todos. recién acabo de terminar de ver los videos sobre la estructura de la página. Siguiendo la filosofía de que cada componente debería ser independiente, creo que deberíamos hacer que las consultas al backend también lo sean. Por ejemplo cuando voy a mostrar el componente about, debo traer los datos de about, y no toda la inmobiliaria. Cuando cargo o muestro el componente Banner, necesito las fotos y textos ( si ponemos alguno) y no todos los datos. Yo esto lo noté cuando hice mi porfolio, pero no me dio el tiempo para dividirlo en el backend. (de pedo lo terminé).

Otro dato mínimo es que para qué queremos el campo ID si no tenemos más de una inmobiliaria. Se que es una pelotudés el planteo, no influye en lo más mínimo, pero no quería que se me pase. (si tengo toc con esas cosas)

Lo de los array dentro de los campos de las bases, al principio me pareció raro, pero no es descabellado, los JSON después de todo son texto. Quizás soy más de la idea de una tabla de imágenes y que consultemos por las que necesitamos, por ejemplo /webaddress/get_img/about y el back nos manda la lista de imágenes que son del about. (Cómo maneja el back la relación ente "propiedad <-> imágenes" es tema del backend y se lo dejamos a ellos.

Con respecto a los bindings del front, sí es necesario que hagamos un JSON.txt para cada componente, ¿porqué?, porque cuando terminemos nuestros issues, debemos estar seguros de que esta funcionando todo el front. y después es problema del back mandarnos los datos como los queremos, ya sabiendo que todo funciona y no teniendo que volver a modificar el front cuando el back termine el modelado de datos. Si ya sabemos que el front esta funcionando y probado con datos del txt, lo único que resta de la issue una vez terminado el back es cambiar una url en el servicio, y no volver a verificar todo el front a ver dónde dejamos algún texto que tengo que hacer dinámico. Es más si nosotros dejamos todo andando con el txt, ese txt le sirve al back de ejemplo de cómo queremos los datos. La otra forma quizás más rápida, es definir de antemano bién qué datos necesitamos, formato de los mismos y trabajar en paralelo, pero la estructura de datos tiene que estar definida al 100%, ya que cualquier cambio hace que el desarrollo de la contraparte vuelva para atrás o se retrase. (Supongo que éste es el método que estamos queriendo implementar, por lo cual suponemos y decimos que no sería necesario el json, pero no creo que nos salga, debido a nuestra falta de experiencia). Yo plantearía hacer un mix. Planificamos las estructuras de datos, las planteamos en un JSON para probar bien el front y en paralelo el back va desarrollando la api. Si todo coincide sale funcionando, de lo contrario podemos verificar de forma rápida quién tiene que adecuarse a lo predefinido.

Bueno, creo que ya opiné y es solo eso, una opinión.

[RominaRomano]

Bueno, habiendo leído todas las opiniones: La estructura que plantea Miguel me parece acertada, esto en primera medida será llevado al archivo json y probado en el front, tanto los servicios como las vistas. Tambén es óptimo esto de solicitar al back únicamente aquello que se va a cargar, ejemplo: header, footer y wsp sólo necesitan cargarse una vez, lo demás sí es variable de acuerdo a la ruta. Es decir, cuando la ruta es la de inicio sólo traer los datos necesarios para la parte del body de la home page.