En esta lección vamos a instalar una nueva aplicación de Laravel y a configurar lo necesario para comenzar a trabajar. En la terminal creamos un nuevo proyecto con el instalador de Laravel. Y lo primero que hago al instalar cada aplicación es inicializar Git, agrego todo al stage y agrego el primer commit.
Bien, la versión que utilizaremos será 7.11 de Laravel. Si quieres seguir el curso con esta versión puedes instalarla con Composer, Create Project. laravel slash laravel, el nombre de la app, seguido por la versión 7. Aunque te recomiendo siempre instalar la versión más reciente al comenzar un nuevo proyecto. En fin, tengo varios aliases que quiero mostrarte, que utilizaré durante el curso para trabajar más rápido. Por ejemplo, en lugar de phpArtisan tengo un alias que es nada más art, y me devuelve el mismo resultado.
Otro que utilizo también es migrate, que equivale a phpArtisan migrate. En lugar de ejecutar phpArtisanMigrateFreshSeed, utilizo MFS y varios otros más que iremos viendo durante el curso. El editor que voy a utilizar es phpStorm y voy a utilizar la terminal que viene aquí incluida que la podemos abrir con F12.
Bien, como vimos en la primera lección, el ejemplo de API que vamos a construir contiene artículos, autores y categorías. Vamos a crear los modelos necesarios para comenzar a trabajar. Podemos crear uno por uno con phpArtisanMakeModel y que nos cree la migración, el factory, el controlador o el resource controller. Pero para acelerar un poco el proceso voy a utilizar una muy buena herramienta de desarrollo llamada Blueprint que nos ayuda con la creación de archivos. Vamos a requerirla con Composer, Require, Latable Shift, Blueprint y solo vamos a utilizarla durante el desarrollo.
Bien, una vez que termine la instalación del paquete, voy a publicar la configuración del mismo, Vendor Publish, y el número 10 es el que necesitamos. Vemos que nos ha creado este archivo, vamos a abrirlo para modificar un par de cosas. El namespace está correcto.
El namespace de los modelos por lo general es App, pero me gusta ubicar los modelos dentro de su propia carpeta para que haya un poco más de orden. Pero es opcional. App Path está bien.
No queremos que nos agregue documentación. Use Constraints. Vamos a cambiarle a verdadero para que sí nos agregue los constraints de las llaves foráneas.
Fake Nullable. Está bien. Y por último, Use Guards. Le cambiamos a verdadero para que al momento de crear los modelos, la propiedad guarded sea un array vacío. Y listo.
Ahora necesitamos crear un archivo YAML llamado draft. Lo abrimos. Vemos que está en la raíz del proyecto.
Y aquí vamos a definir los modelos. Necesitamos el modelo Article. Van a tener un Title de tipo String, un Slug de tipo String también y que sea único en la base de datos.
El contenido será un Long Text, un campo Category ID que será de tipo ID y como cambiamos la configuración de los Constraints a Verdadero, no hay necesidad de especificar que es una llave foránea. Hacemos lo mismo con el User ID. Y aquí podemos ver claramente que un artículo pertenecerá a un usuario y a una categoría.
Definimos también el modelo Category, que tendrá un nombre de tipo String, un Slug también de tipo String, único, y vamos a definir la relación HasMany con el modelo Article. Acá arriba no es necesario definir la llave Relationships, ya que el paquete es lo suficientemente inteligente para saber que CategoryID y User son relaciones. Así que con esto es suficiente. El modelo User viene por defecto en Laravel, así que no hay necesidad de crearlo.
Bien, una vez que tenemos esta estructura, vamos a la terminal y ejecutamos phpArtisanBlueprintBuild. Y aquí vemos todos los archivos que nos ha creado, las migraciones, los modelos y los factories. También podemos crear controladores, resource controllers, o podemos agregar cada método individualmente con reglas de validación y más. Y aparte de eso nos va a crear también las vistas y va a modificar el archivo de rutas web. Es muy útil para ahorrarnos tiempo.
Te recomiendo que le eches un vistazo a este paquete. Pero en este caso con esto es suficiente. Vamos a revisar rápidamente los archivos generados. En la carpeta Models tenemos el modelo Article. Aquí vemos la relación predefinida.
Y la relación con el usuario tiene un problema y es que el modelo User no se encuentra bajo el namespace Models. Ya lo vamos a mover en un momento. Acá tenemos el modelo Category y aquí debajo vemos la relación HasManyArticles.
Ok, volviendo al modelo Article, aquí tenemos dos opciones para arreglar este problema. Podemos modificar este namespace y dejar el modelo user bajo el namespace app o podemos mover el modelo user al namespace models. Cualquiera de las dos está bien, yo voy a elegir la segunda. Abrimos el modelo user y con la ayuda de phpStorm voy a darle clic derecho en el nombre de la clase, luego en refactor, move class o también podemos presionar F6 y vamos a moverlo a la carpeta models o al namespace models. Nos aseguramos de que estos checkboxes estén seleccionados ya que hay otras referencias al modelo user que queremos que se cambien también al nuevo namespace.
Le damos clic en refactor y aquí nos indica que hay dos usos de la clase user. Le damos a do refactor y listo. Aquí vemos que se ha cambiado correctamente. Si revisamos el archivo config auth, aquí vemos la referencia actualizada y si abrimos el user factory. Vemos que también cambia la importación.
Ok. Y hablando de factories, Blueprint también los ha creado para los modelos que definimos. El Article Factory contiene el título de prueba, un slug, un contenido e incluso nos ha creado las relaciones.
Y también tenemos el Category Factory con sus datos de prueba. Por último, si revisamos la carpeta Database Migrations, aquí tenemos la migración de la tabla Articles. con un ID que se agregó sin necesidad de definirlo, al igual que los timestamps.
El string title, el string slug con el índex único, long text para el contenido, foreign ID para el category ID, con el constraint indicando que hace referencia al ID en la tabla categories, y que se elimine el artículo en caso de eliminar la categoría asociada. Y lo mismo con el campo user ID. En la migración de la tabla categories tenemos el string name, y el string slot con el index único.
Por último, vamos a crear la base de datos. Vamos a utilizar SQLite, en este caso. Para ello, creamos un nuevo archivo dentro de la carpeta Database, llamado Database SQLite. Y este es el nombre de la dirección de la base de datos que va a utilizar Laravel por defecto cuando utilicemos la conexión SQLite.
Vamos al archivo.env para cambiarla. En lugar de MySQL, le cambiamos a SQLite y comentamos el resto. Puedes utilizar MySQL si quieres, yo voy a utilizar SQLite por simplicidad y para desarrollo. Ejecutamos las migraciones y listo.
Como gestor de bases de datos voy a utilizar TablePlus. Aquí vemos nuestra base de datos con la estructura correcta y listo. Para terminar, vamos a ejecutar el comando phpArtisanStabPublish para modificar el stab de los featureTest, ya que vamos a escribir bastantes tests. Utilizamos el Trade Refresh Database, quitamos esta importación, que se utilice la anotación test, esto lo quitamos, cambiamos el nombre, ordenamos y esto mejor que esté vacío. Y listo, de ahora en adelante cada vez que creemos un nuevo test va a contener esta estructura.
Bien, con esto ya tenemos todo configurado, en la siguiente lección vamos a ver cómo listar recursos.