Curso Introductorio a Vue.js de GOGODEV de mas de 50 Horas. Dejo contancia de anotaciones para interesados en lo teorico y lo aprendido.
- Reactividad Implicita : La reactividad de los datos es automatica , no es necesario usar referencia ; pero la estructura es distinta y mas declarativa que el "Composite API", hay que declarar los metodos que usemos en apartados distintos (Estructura declarativa) , los datos en otro y demas. De esta manera es mas clara la logica pero es mas trabajo la delcaracion si el proyecto es extenso.
- Estructura Reactiva y Declarativa: La estrucutra es declarativo y reactiva, necesarios importar el ref de "vue" para que los datos sean reactivos. La estructura solo cuenta con el setup en donde metes todo y los metodos y las declaracion de constantes esta mas inclianda hacia la reactivadad ya que la tenes que hacer a mano. Ademas hay que declarar el retorno de los datos al declarar una constante. Es mas flexible esta manera de usar el script y te da mas control de los datos que queremos hacer reactivos y cuales no.
- " Simplicidad y Automatización " -> Para Composite API tenemos la opcion de directamente delcarar el "script" con un setup automatizado donde el retorno y la exportacion del componenete lo hace Vue.
Las directivas son modificadores de etiquetas en el template que te permiten añadir comportamiento dinámico a los elementos del DOM. V-if es una directiva que agrega o elimina elementos del DOM según una expresión booleana.
- Si Sabemos que los datos de los componentes van a estar cambiando constantemente , el renderizado del Dom virtual al Dom no se muestra la opción que no sea pintada por el "script".
- Para el renderizado del v-show , aparece en el Dom pero utiliza una etiqueta para ocultarlo en el template pero esta en el Dom, aparece con un "display none"
- La estrucutura de la directiva del "v-for" , toma la variable del script y la recorre (claramente debe ser un array para poder recorrerla).
-
Solo con Javascript y con la referencencia a si misma, se veria asi.
-
Una version mejorada seria crear una interfaz, a travez de objetos. Ya que estamos trabajando con consumo de APIS.
- Nos sirve para bindear datos de una etiqueta del templeta con las del script(nuestro sistema de datos). Todo lo que vamos a estar viendo es a nivel unidireccional
En la etiqueta "p" usamos el v-bind para que colorie con la clase .danger del styles si es que la variable "hasError" es True.
Caso contrario no resaltaria en rojo y el bindeo no se activaria.
Caso Positivo.
Bindeo Bidireccional: Que es ?
Entre la inforamcaion del "Script" y la vista del "Template"
Si nosotros queremos gestionar la informacion que queremos estar maniupulando en un input , queremos que se vea reflfejado en los datos dentro del componenetes.
Para unidireccional , nuestros datos eran los que gobernanban en la platilla , en el "template". Ahora a su vez la informacion que esta recibe("la plantilla - template") , actualiza tambien el script
Para esot tenemos V-MODEL
V-MODEL
Tendremos un dato de nuestro script vinculado al input de texto , para tener actualizado con el input del template los datos del script.
De esta manera, con la directiva v-model , referencia al inputText , entonces el valor del input del template estara directamente relacionado con nuestros datos (inputText).
Mostramos como lo que escribimos en el for , directamente se ve reflejado en el input text , mostrandolo por el template a travez de una etiqueta "h1" o un "p".
Aqui mostramos el uso de V-MODEL con el nuevo formato de tipo v-model con el uso de "CheckBox". A travez de las Vuetools como extension de Google podemos ver como cambia de estado cada dato del script.
Pryoecto Porfesores:
Uso del const HandleSubject -> A travez de esta funcion , vamos a poder agregar materias al apretar el botton del template con nombre "Añadir Materias"
Aqui añadimos un array con la informacion de profesores con datos no reactivos , ya que mandando el array completo con el .value , cuando querramos limpiar lo que hay en las casillas ya usados de datos , tambien se limpiara lo guardado.
Uso de botton de tipo eliminar y modficar:
Estos apareces una vez que se haya ingresado informacion al array de materias , si no el v-for no se inicia , estas no apareces. La aparecion de estos botones se renederiza en el momento indicado de esta manera.
Estas despeus del {subj} , como todavia no hay un subj dentro del array de materias , no tendria que renderizarse. De esta manera controlamos el renderizado
Y para los modificar , que nos devuelve la informacion que agregamos al teachers al teacher label ,donde hicemos el imput.
Ciclo de vida de Componentes:
A travez de montar nuevos componenetes , van a tener un recorrido a travez de ciertos eventos , y que estos se montan. Van a manternerse en escucha una vez creado, actualizandose (a ala reactividad ) hasta que el componenete sea retirado , es decir , sacado del DOM (que el cleinte salga de alguna seccion a otra) y retirado del navegador para hacer otras acciones.
De esta manera anclaremos ciertas acciones para un cierto momento de vida del componente , solo ahi se ejecutaran (modificaciones / borrado / creacion)
O tambien a antes de retirar el componenete - todo a travez de eventos.
Una vez creado el componente, se inicializa el ciclo de vida y los eventos.
El primer evento seria nuestro "beforeCreate" - primer elemenento. No generado inyecciones , no reactividad.
Despues se hacen y ahi recien se dice que el componente esta creado.
Este es un momento preciso para solicitar informacion , porque los elementos no hay sido cargados
Despues hay ciertas verificaciones para montar el componente y pintalarlo en el navegador. (hay tambien comprobaciones en el montado)
Cambios en el componente , beforeUpdate . Si no , ya en el update ya se veria estos cambios.
Lo mismo cuando se destruye el componenete (before - actual) -- todo lo que pasa antes y despues podemos hacer cosas
Comounicacion entre Componentes:
Con la creación de componentes es una comunicación de forma independiente en la cual todavía los componentes no se comunican entre sí. Todavia no aplicamos una comunicacion seria a pesar de llamarlos dentro de otro.
Podríamos tener llamadas de un componente dentro de otro componente pero si bien su estructura y su lógica eran independientes e individuales entre sí, ind en su comportamiento. ahora aplicaremos una comunicación VERTICAL, de tal manera que podamos mostrar la reactividad del pafre a sus hijos de arriba hacia abajo.
Esta es la información vertical descendente en la cual los Padres pueden pasar información a los hijos y de la misma manera los hijos pueden pasar información a sus hijos y dhica informacion en reactiva de tal manera que si modificamos informacion en el padre , va a bajar la mpdificacion como una cadena descendente.
Ejemplo con epxlicacion de CSS:
Para esta imagen, aplicamos CSS para el PostDetail:
El padidng nos muestra el ancho sobre el donde marcara el color (como una caja). El margin nos muestra la distancia con el titulo , mientras mas , mas lejos.
Uso de PROPS para aplicar la comunicacion Vertical
Queremos que el let y el recorrido que tiene un titulo y un parrafo de texto en el PostList , se ve reflejado en el " hijo " -> el PostDetail , que tambien tiene un titulo y un parrafo , queremos moficarlo con lo del padre.
Estas se etiquetan el la etiqueta html.
Pasamos en cada recorrido del before , le paso la informacion de manera vertical; asi con toda la informacion qur querramos pasar.
Queda ver como el hijo la recoje.
Esta que recibe es de tipo "LECTURA" -> No va a modificar la inforamacion que elige , solo se encarga de leerla.
Para las props en los hijos , defino las props que "espero recibir" , indicando el tipo de informacion.
Asi teniendo disponible las props , tratando de validad que el contenido sea valido (mejor para corroborrar).
Indico si es obligatoria recibir cierta PROPS , para avisar si es o no obligatorio rebir X informacion
: en title y content las uso con : , porque estan bindeada con la infoamacion que tengo
Aca vemos ya como los compoenentes hijos reciben esa informacion.
FINAL PROPS
Arquitectura Vertical Ascendente
La idea con esta Emits , es que los hijos puedan modificar la inforamacion de abajo hacia sus padres (arriba).
Lo hacemos emitiendo eventos , con los cuales el hijo emite un evento para que le llegue al padre. De esta manera este lo escucha y ejecuta el componente padres y recibe al informacion.
A travez del alert , le avisamos al padre que modifque el titulo o contenido. Esa es la manera de comunicarnos.
Resumen de sucesos:
Botton con Habdle click que emite un evento de alerta que le llegua al padre , y de esta manera , lo modifica este en el template.
La alarta como funcion se crea en el padre para poder llamarla y crar el evento ; pero la que nos muestra el evento y a la inforamacion a travez de los enit , es le hijo.
Fin de Clase 5.
...
Nuevo tipo de dato Datos Computados:
Elementos de reactividad de primer orden, elementos vinculados a lareactividad de nuestro componente.
Vamos a tener otros valores que tienen dependencias a otros componentes.
Ejemplo : Cadena de texto como valor de referencia reactiva, cambiante. (Caso de primer orden)
Ejemplo 2 : Reverse de un input (Hola al revés como cadena) , también lo queremos referenciado a ese input para que sea reactivo , pero su contenido depende de la cadena del input que ingresa el usuario. ( dato computado )
De esta manera , estaríamos hablando de un elemento reactivo, relacionado y dependiente del valor del input , decimos que es un dato computado.
Indicamos a Vue , que este dato computado , quiero que sea reactivo pero que no lo escuches a el , si no a los valores de los que este depende y cuando ellas cambien , de paso también cambie el valor de computed.
-Practica- Vamos a hacer una práctica sobre este.
Para estos casos , vamos a necesitar un valor inicial y apartar del cual vamos a generar la dependencia a nuestro valor computado.
Primer caso . Cadena invertida.
Acá podríamos ver como nuestro valor computado , cada vez que calcula el valor de la dependencia , también hace el cálculo del valor computado.
De tal manera que Vue "NO" esta ejecutando una reactividad sobre su valor computado, si no que escuha sus dependencias y cuando son modificadas el valor computado desde ahi/ellas.
Aqui podemos calcular como seria el precio de impuestos que deberiamos pagar de mas.
-Final Clase 6-
Directivas Personalizadas: (Modificar como actua dentro de viertual Dom las etiquetas ya prestablecidas)
Ahora haremos nuestras directivas propias , con un ejercicio de servicios (API).
-Pueden cambiar el aspecto , a tambien acciones mas complejas , v-for , o v-lising. Nuestro tope es la imaginacion.
Donde la codificamos :
En el propio componente , cuando tan solo va a estar definida para el propio componente (Que no es el mejor caso)
La idea es que todos los componenetes puedan utilizarla , por eso hacerlo general para usarla en los majores casos posibles.
La estructuracion va a estar centrada en el main.ts -> Ya que en futuras clases , cuando veamos estructuracion , vamos a hacer el montado a travez del main. (Donde hacemos el montado de nuestra aplicacion)
Paso 1)
Creo una constante App en la cual creamos la aplicaicon y a esa app le asignamos el montado. Lo mismo que antes pero ahora podemos antes de montarla , crearle los diferentes elementos. Ahi entran la directivas propias
Estructura de Directiva:
app.directive
1ro nombre de directiva , 2do objeto con comportamientos de la directiva sobre el virual Dom.
Nos paramos en los argunmentos que recibe.
El famoso nombre de " v- " , lo asigna VUE directamente a todas nuestras directivas.
Arrancamos con directiva de cambio de fuente , vamos a modificar el tamaño concreto sobre hacia uno en concreto.
Paso 2 - pasar el objeto clave -valor
a- Donde el primero es el arguemnto de ciclo de vida donde la directiva actual en su aplicacion. b- Funcion de actuacion cuando a actue.
Asi como unmountes , mounted (hooks / eventos).
Se puede añadir mas de un evento en cada directiva , pero con uno solo en este caso ya basta.
Siempre recibimos el "el" y el "binding"
el : Elemento donde se esta montando el componente , la etiqueta final html que estamos utilizando en app para montarla.
El "el" si lo aplicamos al label , sera esa. Gracias a que la montamos en la app , el "el" va a ser el acceder a nuestras herramientas del DOM.
Binding - Datos recibidos para ejectar acciones o opciones.
La directiva va a poder recibir valores para nuestra directiva , estas llegan aqui , al binding. Toda la configuracion necesario.
Despues del el , es TypeScript o JavaScript normal.
Ya podemos aplicar nuestra directiva declarada en el main.ts y ya van a aparecer las modificaciones sobre el virtual DOM que antes de que se monte , va a cambiar la fuente.
Al label se le aplica el font size. Funciona de manera correcta.
--Fin de primer Ejemplo--
--Incio de Binding Variables - Bindeo Value--
Aca podemos ver como ademas podemos modificar el size segun el bindeo. Ya no es un valor cualquier , el componente nos va a indicar el tamaño dentro del binding.
Como accedemos ? Por el binding.
Funcionaria igual que el "V-MODEL" , donde a aquel se le da un value ; aqui tambien haremos lo mismo para poder modificar el size que le llega al main a travez de binding.
Y aca tenemos como ejemplo como funcionaria la directiva pero con actuaciones distintas en funcion a los valores que se le pasan por el bindeo . value
Ahora le podemos aplicar a nuestras directivas valores ya le le llega al binding.
- Podemos solicitar ademas de los elementos que le pasamos directos a la directiva , podemos solocitar "argumentos"
Ciertos argumentos seran recibidos como parametro, y estos los definimos dentro nuestra directiva con cierto parametro que estaria mostrando o reprensentando.
- Asi como v-bind , vamos a poder a travez de los " : " , solo acepta argumentos del tipo STYLE - KEY - CLASS , y despues recibe un value.
Para este caso , vamos a usar un SWITCH: En funcion al ARG , aplico una fuente o otra.
- Tambien es posible que no reciba un argumento , pero presentamos los distintos casos para cada argumento posible.
El tamaño default es 18 para caundo no haya ningun valor. Ahora le pasamos distintos argumentos a la directiva y vemos como cambian dichas.
- Asi como vimos los Argumentos , ahora tenemos los modificadores:
Vamos a poder tener tantos modficadores querramos , no tenemos que escojer entre ninguno de otro , escojes 1 o ninguno. Ademas con el bindeo podemos recibir modifcadores de tamaño , como aplicar modifcaciones sobre el color y el aspecto. Para ver que podes aplicar 1 o varios o ninguno.
Mostramos tanto como segun el argumento del size , que cargamos antes : sm , mg , xl
- Ademas un punto clave para los modifcadores es que uno puede aplicar 1 o ninguno o todos.
- El orden tampoco importa , es mucho mas flexible que los argumentos desde ese lago
- Usamos la pagina jsonplaceholder , para acceder a una API de contenido con respuestas JSON asi hacemos el consumo de datos y utilizarla para probar nuestras aplicaciones.
- En la seccion de post , esta nuestro ejercicio
- Tomaremos una solicitud de point a este endponit de la API y obtendremos el listado de POST. Depues los pintaremos en un listado (idea es para poder a futuro entrar a enrutado.)
-
La idea es que a travez del array de Post que armamos con TypeScript , podamos guardar todos los datos del JSON al Array Post.
-
De esta manera , con el "axios.get" traemos todos los datos del JSON y los asignamos completos despues de haber montado el componente.
-
Tambien hay un caso ERROR por si no funcionace.
-
Explicacion de ejercicio de ejercicio por el profe
-
Enfoque en estructuracion de datos y codigo , como organizamos la estructura para que sea facil de seguir.
-
A partir de ahora , vamos a empezar a estructurar nuestros componentes de manera distinta , de la manera correcta.
Nos apoyaremos en las estructuras de:
- Defincion : Cuando hacemos un consumo de dato , es decir un consumo de un tercero / desarrollo externo (un backend de un tercero API)
- No hacer el consumo directamente en el componenete !!! Por que si hay cambios en los endpoint en el sistema que estamos consumiendo , vamos a tener que buzear en donde esta el consumo y como lo estamos consumiendo. Va a ser denso y nada va tener sentido
- Es mejor usar una Carpeta de Servicios
- Buscar Datos
- Linedear consumos de datos
- Mandar Datos , etc
No vendria a ser un componenete , por eso lo indicamos con TS.
Nuestro servicio sera una clase que se va a preocupar de servir e ir a buscar los datos , para que cualquier componente que quiera usarlo , el servicio se encarga de hacer las peticiones oportunas.
- Con nuestra variable privada posts solo declarada dentro de la clase.
- Un Constructor -- Inicializo la variable posts como un array vacio , que declaramos arriba.
- Si quiero leer los post , los leo a travez del getter
- Funcion ASYNC que hace el consumo del servicio externo , metodo asyncrono , donde espero la recepcion de datos y mientras la espero obtengo una promesa de retorno.
-
Control para manejar errores , para gestionar errores no de nuestro sistema , si no de la api externa.
-
Dentro de este try vamos a querer recuperar la informacion que estamos solicitando (POST) y guardando en la variable post (en realidad lo que estmaos buscando de la api extena )
POST REACTIVO -> Porque queremos que nuestro servicio actualice la informacion de los post que tiene , esta info se muestre en nuestro contenido y en nuestros componentes quede actualizada
- La funcion que hace el consumo del servicio externo , metodo asyncrono , donde espero la recepcion de datos y mientras la espero obtengo una promesa de retorno.
- Fetch es una funcion que hace una peticion a una url , y devuelve una promesa. Debemos esperar a que la url nos responda , porque si no tendriamos solo la promesa de respuesta.
Después de que la promesa de fetch se resuelve, response contiene la respuesta HTTP completa. Esto incluye tanto los datos que recibes del servidor (el cuerpo de la respuesta) como la metadata, como el estado HTTP (por ejemplo, 200 para "OK", 404 para "No encontrado", etc.).
const data = await response.json()
Este es un método que convierte el cuerpo de la respuesta (que está en formato JSON, una cadena de texto) en un objeto JavaScript. JSON (JavaScript Object Notation) es un formato de intercambio de datos común que representa datos estructurados como objetos de JavaScript.
await response.json()
Aquí, await está esperando a que la conversión del cuerpo de la respuesta en un objeto JSON se complete. Aunque esta operación es relativamente rápida, sigue siendo asíncrona porque puede implicar la lectura y el procesamiento de un flujo de datos, especialmente si la respuesta es grande.
data: Después de que await response.json() se resuelve, data contiene el objeto JavaScript resultante que representa los datos que el servidor envió en la respuesta.
- Despues de tener la carpeta de servicios , ya podes crear nuestro componente para la lectura de nuestro servicio de POST , donde usaremos nuestro servicio de post, es decir ...
Primero en el setup queremos el consumo de nuestro servicio , como ?
-
Con el ciclo de vida de nuestro componente:
-
Vamos a interesarnos en la parte donde el componente solicite la informacion al servicio.
-
Nuestro componente tiene que solicitar al servicio que pida los datos.
-
En que momento se dispara ? Cuando se monta -> A travez del FETCH ALL
- Accion Componente: Aca lo que hacemos es incializamos el service , activamos el constructor del service
- Accion servico : En este , se nos genere el post con una referencia vacia para el componente donde podemos obtener los post del servicio con el get
- El post nos devolvera con el .this lo que tenga el array de post dentro de este.
- Ahi es donde llama con el get a los post del service.
- Y ademas vemos como aplicamos el funcionamiento del asincronico del fetch.
-
El uso de onMounted es crucial aquí porque te asegura que la operación de obtener datos (que puede tomar un tiempo indeterminado) no se inicia hasta que el componente está completamente listo para recibirlos y mostrarlos. También evita posibles errores o condiciones de carrera donde el componente intente acceder o manipular el DOM antes de que esté completamente disponible.
-
Esto asegura una mayor consistencia y fiabilidad en la interacción con APIs externas y en la representación de los datos obtenidos.
Gracias a que esperamos al fetch del service , cuando nuestro componente arriba haga el getPost , ya deberian estar cargados todos los post dentro porque con el onMonted marca la creacion del serivice con await hasta que los fetchie.
- Declaramos en otra carpeta nuestra interfaz para TypeScript y ponemos ? para indicar no saber si se mantiene a lo largo de los elementos.
- Forma de protejerse ante opcionalidad del valor
- Exportamos por defecto
Tipamos el .ts y vemos que arreglamos los any.
- Ejecutar buenas practicas en el codigo para despues en un futuro no tener problemas en la estrucura interna e externa (API).
- Cada vez que tengamos logica mas complejas , va a ser mas complicado mantener todo dentro de un componente.
- Derivar servicio a una estrucutra de servicio con una clase donde cada vez que necesitemos consumir dicho servicio , tendremos rapidametne visible y facil de usar esta.
- El tipado tambien en otras interfaces para definir interfaces.
- Las primeras 8 clases , vimos nuestro "style" desde dentro de nuestro componente de manera scoped y dentro del Vue.app
- Cuando el componenete sea mas grande , y queramos dar mas detalle , el style se disparara y 100 lineas de codigo solo por esta,
- App.vue , puede provocar mas lineas de codigo en algo que es innecesario el style
- Particionar el codigo y dividirlo , para disponer de forma global y usar los estilos. Crear variables para los colores para modificar un color y para cambiar en todo nuestro proyecto. Dividir en carpetas (fuentes , colores , etc)
- Propia estrucutra de contenidos - estilo cascada , entonces codigo muy extenso - por eso uso preprosesado de css (contenido mas pequeño y mas facil de leer)
- Particionar codigo y facil de leer.
- Reutilizacion de codigo a otros clientes.
- Parametrizacion de codigo
- Nuevas funcionalidad y mejoras a estilos
Estos son los 3 tipos de pre-procesadores , Sas es el mas extendido de ellos.
Creamos una variable con el nombre del color y la usamos en el li.
- Vamos a realizar ahora una estructuracion a nivel Global , crearemos archivos CSS para tener a nivel general , una carpeta con nombre CSS
- Podes estructurar aun mas en la carpeta SCSS , e ir a nivel fuete , tamaño , color , tipografia etc (nivel super especifico - mas estructurado y dividido )
Aqui le pasamos el tipo de carga : especificamos que para css usamos scss y que este en x carpeta con el addition data.
- Ahora tenemos a disposicion de nuestro poryecto todas nuestras variables globales.
- Declaracion de varaibles
- Anidamiento - Podes escribir dentro de un selector otro selector (usar postlist y dentro li)
Y nos evitamos el uso del .postlist li
- Distribucion de codigo a travez de importaciones
Nos permite distribuir el codigo scss ante el contenido escalable.
- Intrucciones de control (IF - BUCLES)
Acciones del preprocesador
- El codigo SCSS se trasnpila y se convierte en CSS natural.
- npm install --save bootstrap
- npm install --save @popperjs/core
- De esta manera solo nos queda importarlo en el main.ts
Modo history para prosproduccion
- En el main.ts que es el punto de entrada que crea nuestra instancia de vue , nos muestra un cambio.
- Aqui vemos que el "router" se importa y se le indica que se va a utilizar en el div , esto le da potestad al router para poder controlar las rutas que vamos a estar construyendo en nuestra aplicacion.
Router Record Raw : Utilizo para utilizar una constante de rutas , para poder utilizar un array de rutas
-
El routerRaw nos va a permitir generar diferentes rutas. ** Es un array de Objetos **
-
Este va a contener
- el path - URL -
- el componenete que se va a estar ejecutando cunado entremos a esa ruta.
- Despues aqui se ejecuta lo mismo , pero con ciertas diferencia , otro ejemplo de construccion de ruta para generar code splitting para despues hacer lazy loading de las diferenctes rutasy hacer cargas mas rapidas de cargas , para apoyarse en el web pack para ponerle nombre a cada una de las rutas de darle a mas agilidad a este proceso.
Se define un array de objetos llamado routes, donde cada objeto representa una ruta de la aplicación. Cada objeto en el array routes tiene propiedades como path, name y component.
- path: La URL a la que se accederá.
- name: El nombre de la ruta, útil para la navegación programática.
- component: El componente Vue que se renderizará cuando se acceda a la ruta.
Ejemplo de construcción de una ruta:
La primera ruta tiene el path '/', el name 'home' y el component HomeView. La segunda ruta tiene el path '/about', el name 'about' y usa import() para cargar el componente AboutView de manera diferida (lazy loading).
- Code Splitting: Divide el código en partes más pequeñas para que no se cargue todo de una vez. Esto mejora el tiempo de carga inicial.
- Lazy Loading: Carga las partes del código solo cuando se necesitan. Por ejemplo, AboutView solo se carga cuando el usuario navega a la ruta '/about'.
- webpackChunkName: Este comentario especial (/* webpackChunkName: "about" */) le dice a webpack que nombre este chunk como "about". Esto ayuda en el proceso de carga y hace más fácil identificar los chunks en el navegador.
En main.ts, se configura el router para usar el modo history. Se define un array de rutas en el cual cada ruta tiene un path, un name, y un component. Se muestra cómo implementar el lazy loading con import() para mejorar la eficiencia de carga. Si necesitas más detalles o tienes alguna pregunta específica sobre alguna parte del código, ¡házmelo saber!
- Aca el component es el AboutView - (Igual que el HomeView)
- Tenemos estos dos formatos y ademas la creacion del router
- Reaccionamos a la constante router , la cual la creamos a travez del history de vue , que alli tenemos el control historico de rutas
- Y le asinamos la constante de routes (las distintas rutas) con componentes que las gobiernan.
- Las Views son los padres de una lista de una ruta completa - Llamados por el router , vistas de router -
- Components : Elementos parciales , composiciones parciales para el diseño
-
Utilizacion router link para poder acceder a la carpeta de router donde esta cada vista.
-
Donde montamos la app , como cambio al estructura Uso de menu de navegacion - router link - que nos permite navegar entre las diferentes rutas
-
Y el router view pinta la que este activa, pinta la vista en la que pulsemos y nos mostrara dicha vista. (lo va a aver en el router index) -
- Genenramos nuevas Vistas y las enlazamos al App.vue
- Pero hay un problema ... poner tanto codigo en el app.vue es una mala practica, asi que creamos un componente para el nav-var !!
- Asi atomizamos mas el contenido.
- Creamos un componente con el mismo nav-bar que el App.vue y los estilos propios de este.
- De esta manera , podemos tener una estructura mas atomica y limpia.
#Estilos:
- Si la ruta donde nos encontramos esta activa , se le aplica el route link active y se le aplica el router link exact active
- Para marcer el estilo general del servicio route link active - Hijo de home
- Situacion Concreta del servicio - link exact active - Excatamente la del Home
-
Llamar a la ruta determina y pasar informacion de un componente a otro.
-
Mandar un parametro dentro de una ruta y que esta la reciba
-
Aca le damos el parametro id para que a esta le llegue dicho paramtro y lo reciba. Este elemneto es dinamico
-
De esta manera podemos recuperar la inforamacion y utlizarla.
- Carga solamente si le pasamos un parametro.
- Dejamos el Blog sin id y cramos una View de tipo post view - que utilizaremos para ver el detaller del blog.
- De esta manera , cuando se ingresa un compnente en el blog/ , entramos al post view
-
Vue utiliza el "to" en el router link , ante grandes proyectos vamos a tener multiples enlaces (footer ,etc)
-
Elementos que modifican la navegacion
-
Es decir , no es mantenible
-
Manera correcta:
- De esta manera , solo responde al nombre en vez de la ruta.
