Tío, ¿qué has venido a trabajar, cabrón?
Está haciendo 62.000 dólares al mes.
Cuenta corriente, parece que es 2030.
Muy buenas tardes, ¿qué tal?
Bienvenido, bienvenida.
Hoy son las noticias de JavaScript.
Tenemos el secreto de Google,
un tema muy importante de Google, el SEO y JavaScript.
Github se pasa a React.
Vamos a ver cómo hacer un drag and drop nativo.
Lo vamos a hacer con JavaScript.
Última cosa que os comento.
Estamos haciendo un sorteo
porque hemos llegado a los 200.000 seguidores en Twitter.
Muchas gracias a todos y a todas.
Si eres un seguidor de Twitter, te quiero, ¿vale?
Te quiero directamente.
Y por eso he querido tener un pequeño detalle
que estoy sorteando 5 libros físicos de código sostenible.
Puede todo el mundo participar, ¿vale?
Github se está pasando a React.
No sé si lo has visto, no sé si te has dado cuenta.
Si vosotros vais a Github, ¿vale?
Pues veréis que han cambiado algunas cositas.
Ha cambiado esto, ha cambiado la header también.
Están cambiando cosas.
Durante mucho tiempo parecía, parecía,
que Github estaba apostando muy fuerte por los web components
y mucha gente siempre los ponían como ejemplo
de cómo componentizar una página web
sin utilizar React y todo este tipo de cosas.
Pero no, no.
Ojo, ojo.
Porque ha habido cambios.
Por ejemplo, si vais a cualquier proyecto,
por ejemplo, a este de la Kingsleak,
¿veis que tengo aquí el iconito de React
que ahora está como desactivado?
Esto significa que no está detectando React en ningún sitio.
Pero si, por ejemplo, le dais a una carpeta,
le dais a una carpeta,
¿veis que se ha activado el iconito?
Todo lo que es nuevo de Github
está utilizando React.
Pero todo lo que veáis que es nuevo
está utilizando React.
De hecho, lo podéis ver aquí.
Todo esto, toda esta parte,
está hecha con React.
Y lo tenéis aquí.
He pensado,
a lo mejor solo ha sido esta parte.
A lo mejor, yo que sé,
ha sido esta parte que tampoco es nada del otro mundo.
Yo creo que están haciendo una migración progresiva a React.
Y me da la sensación
que todo lo nuevo que están haciendo
lo están haciendo con React.
O sea, no tengo ninguna duda.
Ya os digo, esta parte de aquí está hecha,
pero hay algunas cosas bastante tontas,
como por ejemplo,
si haces un nuevo repositorio.
Creo que también.
Esta parte, que parece una tontería esta parte,
la han hecho toda con React también.
Toda esta parte, autocheck, no sé qué,
form control,
todo esto lo han hecho con React.
Que ha sido transparente.
Y esto no lo sabíamos.
Pero esta página, que es exactamente igual
a la que tenían antes,
porque no ha cambiado nada.
O sea, la veis y visualmente es la misma.
Lo que significa que ya tienen
todos los componentes hechos con React.
Estarán empezando con páginas pequeñas,
pero lo están migrando a React.
O sea, interesante.
Antes utilizaban,
bueno, y siguen utilizando,
Github utiliza Ruby on Rails.
Y es bastante interesante
porque les está costando.
Antes utilizaba jQuery
y ya empezaron a quitarlo.
Ya os digo,
Github siempre ha sido
uno de los típicos ejemplos
de Web Components, ¿eh?
Y tenían este repositorio muy chulo.
Fijaos que empezaron hace 5 años.
Con un montón de componentes,
todos los elementos que utilizaba Github,
que están súper chulos, ¿eh?
Por ejemplo,
para hacer crop de imágenes,
emojis y tal.
Pero bueno,
¿qué me sorprende?
Amigos,
que se confirma
que Github está migrando a React.
No lo había visto en ningún sitio.
No sé si es exclusiva.
Lo que está utilizando más bien
es un sistema de widget.
Hay gente que a Microfronted ya
cualquier cosa le llaman Microfronted.
Lo que tenemos aquí,
un widget.
Podríamos decir que es un widget.
En el sentido de que esto,
seguramente hay cosas
que sí que se renderizan
en el HTML.
¿Veis?
Aquí tenemos un montón de cosas
que están renderizadas con HTML.
Esto significa que Rubion Rage
lo renderiza directamente
desde el servidor
todo este HTML.
Por ejemplo,
Your Code Spaces.
Pero veis aquí
que pone Loading.
Igual incluso podemos detectar
cuál es la parte.
Todo lo que es...
Mira,
Riaca.
Mira,
aquí tenemos el truquito.
Pues aquí lo tenéis.
Riaca.
¿Qué es lo que hace esto?
Esto lo que hace
es renderizar en servidor
esta parte que veis
y esta parte,
esta parte de aquí,
lo que es el contenido
de la página,
lo estás renderizando
en el cliente.
O sea,
cuando se carga en el cliente
se renderiza y ya está.
No sería un Microfronted,
sino que simplemente...
De hecho,
esto lo vamos a comentar ahora
con los secretos de Google
y el tema del Search Engine Optimization.
Es simplemente
un renderizado en el cliente
de una parte de la página.
Es mucho más simple
de lo que parece.
Siempre en el mundo de la programación
hay un salseo
que se repite constantemente
y suele ser protagonista
este hombre
que está aquí tirado
que seguramente
si fuese verdad
que programa así
todos los días
tendría algún tipo
de problema
en su columna vertebral
porque la verdad
es que muy cómodo
no se ve
las cosas como son.
Aunque sí que tenemos
que decir
que tiene un perrito
bien bonito.
Ojo que dice...
Puedes hacer lo que sea.
Cree en ti mismo.
Hostia,
esto me da bastante grima.
No sé qué es,
pero...
PhotoEye.com
A ver,
le voy a hacer publicidad gratis
porque es que de hecho
vive también un poco
de esto este hombre
en el que sí
que tiene este proyecto
que son como fotografías
con inteligencia artificial
donde tú subes tu fotografía
y te genera
como un montón de fotografías
con inteligencia artificial.
Y aquí tenéis
lo que siempre está diciendo
lanzando básicamente
al mundo de la gente
de la programación y tal
que dice
PhotoEye
tiene 14.000
14.000 líneas
de PHP
mezclado
con
HTML
CSS
y estilos
y JavaScript
todo en línea.
Todo en un solo archivo,
en un solo archivo.
No utiliza TypeScript,
no utiliza Flexbox
o no utiliza Frameworks
excepto jQuery.
Ahora os comentaré
porque esto me parece
también un poco polémico.
Polémico en el sentido
de ir de listo.
Mucho
$.ajax
y float left
y tiene
1.872
clientes
y está haciendo
62.000 dólares
al mes.
Tremendo.
Y aquí podéis ver
un poco del código,
las 14.000 líneas.
Aquí podéis ver
HTML
mezclado de PHP
con el clear box.
O sea,
que esto es más viejo
que el andar para adelante.
Y aquí podéis ver
la página
con un montón de chicas
creadas con inteligencia artificial
y tal, ¿no?
Dice
casi todo el código AJAX
es el cliente
que habla con el servidor
de PHP
muchas veces
incluso consigo mismo.
O sea,
hay veces que como lo tiene
todo en un solo archivo,
¿vale?
Como lo tiene todo
en un solo archivo,
se llama a sí mismo
el archivo
pero utiliza
QueryStrings
para determinar
qué es lo que tiene que hacer.
Por ejemplo,
si en la QueryString
tiene que la acción
es recuperar
la galería de imágenes
de la cámara,
pues ya lo tienes, ¿no?
Entonces devuelve el resultado
utilizando el JSON en code.
O sea,
la API es el mismo archivo.
Y aquí tenemos algunos ejemplos.
¿Veis?
La llamada de AJAX
y esto es a sí mismo
pasándole la acción
no sé qué,
no sé cuánto.
Muy simple.
Dice,
muy simple,
muy simple.
¡Hala!
Toma.
Y aquí sería el PHP
donde podéis ver
que tiene el if
dentro de esas 14.000 líneas
que tendrán muchos if.
Y sigue,
sigue,
porque si te quiere dar explicaciones
y que te haga
y sentirte mal
por tus componentes de React,
este hombre tiene rato
para eso, ¿eh?
O sea,
que tranquilo,
tranquilo que te lo explica.
Los endpoints de AJAX
colocan cosas
en la base de datos
de SQLite,
¿vale?
Está utilizando un SQLite
y está utilizando PDO,
que es built-in PDO.
PDO,
ah,
PDO,
es que esta es la clase
de PHP
para hacer transacciones
de base de datos,
la madre que lo parió.
El cual te permite
con el incorporado de PHP,
claro,
o sea,
con el incorporado de PHP,
qué crack,
que le permite colocar datos
de manera segura
a la base de datos
con variables
que evitan la inyección de SQL.
Y aquí podéis ver
cómo está haciendo con PHP.
Sí, sí,
no,
no es que esté mal,
lo que pasa es que
no sabía que se llamaba PDO,
que se llamaba PDO,
es que PDO
me ha hecho gracia por el nombre,
pero claro que tiene sentido,
hombre,
utilizarlo.
Dice,
luego hay algunos trabajos
de Chrome Jobs
que hace con PHP
que se ejecutan,
que verifican
si la base de datos
tiene nuevos trabajos
de fotos
y entonces los ejecuta.
¡Oh, no!
Y es que,
es que,
es que Dios,
va sobrao,
va sobrao,
porque mira,
amigos,
dice Neo,
dice,
oh, Dios mío,
parece que he ido atrás en el tiempo.
Hola, 2002.
Y le dice,
mi cuenta corriente
parece que es 2030.
Esto está bien,
¿no?
Cuando vas sobrao por la vida,
tío,
o sea,
cuando vas tan sobrao por la vida
que te puedes,
puedes decir estas cosas,
puedes decir estas cosas,
cuando eres tan humilde
que puedes decir estas cosas.
A ver,
vamos por partes,
vamos por partes.
La verdad,
sí que es verdad
que hay una máxima importantísima
en el mundo de la programación
que esto es el mejor ejemplo.
Mejor hecho que perfecto.
Yo reconozco que muchas veces
por intentar sacar las cosas
mejor,
pues a veces o no las saco
o tardo más de lo que debería
o lo que sea.
¿Por qué?
Porque perfecto a veces es nunca.
Porque no existe la perfección.
Entonces,
si tú te agobias
y ahora seguro que a todos os pasa.
Una de las cosas
que hay que darle la razón
a Level Sayo
que es una cosa que demuestra
es,
oye,
hazlo
y tú lo sacas
y ya habrá tiempo total.
Es que fíjate
lo que está ganando.
Seguramente,
si intentaras hacerlo
con las mejores prácticas
de la forma perfecta,
pues fíjate
que estaría perdiendo
60.000 dólares al mes.
¿Sabes?
Es que es brutal.
Ha habido mucho salseo
con el tema de Tailwind,
¿no?
A la izquierda,
HTML y Tailwind
con la idea
que sería más fácil de leer,
¿vale?
O sea,
con desarrolladores
pensando que sería más fácil
de leer lo de la izquierda.
En la derecha
he reescrito el markup
usando clase CSS
y tal, ¿no?
Claro,
el de la izquierda,
fijaos,
es muy difícil de leer
y tiene aquí
un montón de cosas
de Tailwind y tal
y aquí,
pues mira qué bonito parece,
ay sí,
todo más mágico,
más fácil de leer.
Pero también es verdad
que es porque parte
de las cosas
que has hecho aquí
te las ha llevado,
esta complejidad
te la ha llevado
otro archivo.
Claro,
es muy fácil decir
que se lee más fácil
cuando has quitado
la mitad de un archivo
y te la ha llevado
otro archivo
que no aparece.
¿No te jode?
Obviamente,
entiendo su punto,
pero hay que entender
que normalmente
esto se tendría
que componetizar,
no tiene sentido repetir
esta clase aquí,
esta clase aquí,
esta clase aquí otra vez,
o sea,
es la misma todo el rato,
¿no?
Pero el tema,
el punto,
esto,
normalmente lo que hace esto,
mucha gente
lo que hace con esto
es perderse en el punto
y el punto
es que a la gente
le ayuda Tailwind
a desarrollar más rápido
y eso es lo que quiere
la gente,
lo que quiere es
por rápidamente sentarse
a hacer un portfolio
y pim, pam, pum
y que quede bien,
y es normal
y eso no es juzgable,
¿sabes?
Eso no le puede rebatir
una sensación
y ese es el punto,
que te puede gustar o no,
eso es lícito,
pero no entender el punto
de decir,
ostras,
esto lo hacen por algo,
¿sabes?
Pues ya está,
hay gente que le gustará Tailwind
y hay gente que no le gustará.
Así que,
pero a nivel de mantenimiento
y crecimiento,
¿sería mejor con Tailwind
o con CSS Modus
o por el estilo?
Lo malo de Tailwind
es que te puede pasar
como pasó la semana pasada
con Stitches.
El problema que tú tienes
cuando utilizas
un framework,
por una biblioteca,
lo que tú quieras,
¿vale?
Es que te estás atando a algo
que a lo mejor muere.
Imagínate que tienes GitHub
y dices,
voy a utilizar Tailwind
o voy a utilizar Stitches
o Style Components
o lo que sea,
¿vale?
Lo que estás haciendo ahí
es una hipoteca,
una hipoteca
en la que al final
puede ser que te salga bien
y que te dure
los suficientes años
para que la casa no se caiga,
pero también puede ser
que te pase como va a pasar
con esto,
que tú imagínate
que eres GitHub
y te quedas con Stitches
porque tiene muy buena pinta,
porque tiene buen rendimiento,
porque es mejor
que Style Components,
pero ¿qué pasa?
Que Stitches
al final
no es tu proyecto,
por lo tanto,
Stitches
ya no está
en mantenimiento.
Te jodes.
Y bueno,
claro,
¿qué pasa?
Pues ahora ya
todas las empresas
que han utilizado esto
durante un tiempo
podrán sobrevivir,
obviamente no pasa nada.
Habrá otras empresas
que de forma errónea
harán un fork
y crearán un monstruo
y habrá empresas
que empezarán una migración,
habrá un poco de todo,
¿no?
Y este es el problema
sobre lo de Tailwind.
Tailwind o CSS Modules.
Dependiendo de la aplicación
y cómo ves su futuro,
seguramente
vas a querer evitarlo,
¿no?
Porque puedes decir,
oye,
es que Tailwind ahora está de moda,
pero a lo mejor
no siempre está de moda
o no siempre es lo mejor.
Y lo que siempre,
normalmente,
porque ya sabemos
que resultados anteriores
no garantizan
resultados futuros,
muchas veces,
lo que sí que suele pasar
es que la plataforma,
la plataforma web,
no cambia.
O sea,
no cambia,
suele ser una buena apuesta,
no desaparece.
Por lo tanto,
CSS Modules,
para un proyecto
que tenga que vivir
durante largos años,
puede ser buena idea.
Elon Musk,
que el otro día dijo,
oye, chicos,
que vamos a hacer esto.
Para abordar los niveles extremos
de extracción de datos
y manipulación del sistema,
hemos aplicado siguientes
límites temporales.
Cuentas verificadas
están limitadas
a leer 6.000 publicaciones
por día.
Las cuentas no verificadas,
600 publicaciones al día
y las nuevas cuentas,
solo 300.
300 posts
en Twitter,
no es nada.
Luego,
poco a poco,
poco a poco,
porque decía que era temporal,
fue abriendo,
fue abriendo,
iba diciendo,
ahora son 200,
ahora son 300,
ahora son no sé qué.
O sea,
que fue abriendo poco a poco
como el grifo.
Dice,
para prevenir el escrapeo,
hay gente
que parece ser
que comenta
que Twitter tenía
que pagar
la factura
de Google Cloud.
Y al ver la factura,
Elon Musk dijo,
¿What?
¿Cómo?
¿Qué?
¿Qué hay que pagar
todo esto?
¿Una app?
Y aquí lo tenemos.
Twitter ha estado
intentando renegociar
su contrato con Google
desde marzo.
Retrasó los pagos
a AWS.
A este tiempo,
Twitter ha decidido
pagar Google Cloud
desde el hecho
de que Google
era la empresa
que más dinero,
la segunda empresa
que más dinero
se estaba gastando
en Twitter
y que además
estaba pagando
las licencias
para hacer stream
de los tuits y tal.
Y una de las formas
de apretar,
¿no?
De decir,
oye,
quiero pagar menos,
pues decir,
bueno,
pues vamos a pagar menos.
O sea,
tú no quieres
bajarme la factura,
lo que voy a hacer
es evitar
que la gente
pueda ver tantos tuits
para así reducir
mi factura
de forma orgánica
y así pues vas a ver.
No sé si lo habéis visto,
la búsqueda
tampoco funciona muy bien.
Los filtros de búsqueda
ya no funcionan.
Los he estado probando antes
y ya no funcionan.
Puedes buscar,
pero uno,
no buscas muy atrás
en el tiempo.
Dos,
no funcionan los filtros,
muchos de los filtros
ya no funcionan
y bueno,
los cambios en la API
de pago ya,
pues alucinas,
¿no?
No sé si lo sabéis,
pero ya hay mucha gente
que se ha ido
de Twitter,
¿no?
O sea,
que había muchos desarrolladores,
no sé,
decían que había miles,
doscientos,
cincuenta,
no sé qué
y que ahora quedan cuatro.
Dicen,
no sé números exactos,
pero que quedan
muy poca gente ya.
Y ahora ha salido esto
que me parece demasiado gracioso.
Dice en Blind,
no sé si sabéis
que Blind
es una comunidad
bastante tóxica
de programación.
Bastante polémica,
no os digo nada,
pero es un poco polémica
porque uno,
hay veces como que
hay información aquí
confidencial
que se filtra,
hay información
que dicen que es mentira,
hay un poco de todo.
Pero es bastante interesante
a nivel de salseos
e historias bastante chulas.
Requesting female vantage point,
¿cómo me puedo convertir
en un mejor marido?
Y esto lo dice alguien
que trabaja en Amazon.
Desearía nunca haber entrado
en Amazon.
O sea,
es que,
¿a qué alucináis?
Es bastante tóxica
esta comunidad,
o sea,
no os quiero decir,
no os recomiendo,
no,
o sea,
que hay toxicidad,
pero a puertas.
Yo entro de vez en cuando
y luego tengo que hacer yoga
para que se me pase,
o sea,
imagínate,
pero ¿qué es lo interesante?
Que muchas veces
hay historias aquí
de que se filtran
cosas internas de empresas.
De hecho,
en Twitter
se filtraron cosas aquí
que al final
resultaron ser reales,
como aquello de
gente durmiendo
en las salas de reuniones.
Pues vino de aquí,
hay un montón de cosas,
¿vale?
Ken C. Dodds decía
el mayor problema
de performance
es probablemente
de backend,
no de frontend.
No me gusta este tuit,
nada.
No me gusta nada
este tuit,
sinceramente,
lo tengo que reconocer.
Primero,
¿dónde están los datos?
¿Dónde están los datos
que yo los vea?
¿Dónde están los datos?
¿Por qué?
Porque imaginad
que tenéis un problema
de rendimiento
y dices,
ah, no,
probablemente es el backend.
Ya está,
siempre ese problema
es el backend.
Oye,
hay veces que es verdad
que el problema
es el backend
y otras veces
que se frontend
y a veces,
¿sabes qué?
Que son los dos.
A veces el problema
son los dos,
que suele pasar también.
Dice,
no quiero decir
que no debas reducir
un par de docenas,
un par de docenas
encima,
un par de docenas
de milisegundos
de interacciones
realmente lentas.
Esto no tiene sentido
porque no es verdad.
O sea,
ya solo el hecho
de poner una imagen
que cargue
un mega y medio,
como algunos de ustedes
hacen en el porfolio,
cabrones,
eso no es un par
de docenas
de milisegundos,
eso es un montón ya,
puede ser un segundo y medio.
Seguro,
haz eso,
pero tal vez primero
reduce un par de cientos
de milisegundos
de tus llamadas
de API base de datos.
Sinceramente,
Kenzie Dodge,
no digas estas cosas,
tío,
que tienes razón,
o sea,
tienes razón
en el que a veces
puede ser el problema
el backend,
pero no creo
que haya una medida
en el que digas
que la mayoría
de las veces
el problema está
en el backend,
es que no creo
que sea tan fácil
decir algo así,
o sea,
no sé,
me parece un poco
irresponsable y todo,
claro,
mira,
aquí estoy un poco
de acuerdo
como dice Renato,
comparando naranjas
con manzanas,
cada cosa
tiene sus problemas
diferentes de rendimiento,
ya está,
que hay un problema
peor
que me ha recordado
bastante
el tema
que comentaba
Level Sayo,
dice,
el mayor problema
de rendimiento
de tu página
es que no tenga
usuarios,
la verdad,
está chulo
este mensaje
y es verdad,
lo peor
que te puede pasar,
lo peor
que te puede pasar
realmente
es no tener
usuarios,
por más
buen rendimiento
que tengas,
el backend
que esté niquelado
y tal,
lo cierto
es que el peor
rendimiento
que puede tener
es que no tengas
usuarios,
un paper interesante
que le ha puesto
David Bonilla
que es este paper
de Stanford
que vais a ver
que hay polémica,
tenés altísimo
paper de Stanford
sobre trabajo
remoto,
los trabajadores
creen que aumenta
la productividad
pero los managers
lo contrario
y esto es bastante
importante
porque obviamente
quién son los que
toman las decisiones
no van a ser
los trabajadores,
van a ser los managers,
fijaos aquí un poco
la idea
de si el efecto
es correcto,
no es correcto,
si es malo,
no es malo,
lo que podemos ver
es justamente eso,
los managers
creen que no,
que está afectando
a la productividad
de los trabajadores,
los trabajadores
estamos contentos
son más productivos,
así que la pregunta
del millón,
además es de México,
aquí José María Barrero
lo ha hecho de México,
le voy a escribir
a ver si podemos
hablar con él
para que nos explique
un poco todo
porque joder el paper,
fíjate,
esto os habrá pasado seguro,
en medio de la pandemia
todas las empresas,
todos los managers,
todo el mundo
estaba súper contento,
yo lo único que escuchaba
a todo el mundo decir
la productividad
ha aumentado,
todo va genial,
el trabajo remoto
nos ha hecho
mucho más ágiles,
nos ha hecho mejores,
nos ha hecho no sé qué,
nos ha hecho no sé cuánto,
o sea,
cuando estábamos ahí
todos en casita,
yo lo único que veía
es que todo el mundo,
todo el mundo,
las empresas,
las primeras,
estaban como
wow,
todo,
ahorros,
qué rápido,
muy bien la productividad,
hemos sacado más trabajo
que nunca,
no sé qué,
en mi empresa
era como una fiesta
y todo,
o sea,
estaban los managers
en volandas,
pero tú crees,
tú crees que
cuando terminó la pandemia
entonces dejamos de ser
más productivos,
por eso,
porque terminó la pandemia,
mi sensación es como
que hay empresas,
no digo todas,
porque no lo sé,
de que yo me haya encontrado
algunos managers
que por un lado
tenemos empresas
que es un despido blando
en el que en realidad
te quieren despedir
pero dicen,
bueno,
hay que volver a oficina
y así los que se quieran ir
que se vayan,
¿sabes?
y así pues,
y luego por otro lado
está el hecho
de que no sé,
no sé si es por un tema
de que tienen que pagar
las oficinas
y les da rabia
y dice,
joder,
es que estas oficinas
las estoy pagando,
ven a disfrutarlas,
desgraciado,
que vengas a la oficina
y disfrutes,
o un tema
de control,
un tema de control
de que,
claro,
como ahora hay la posibilidad
de ir a la oficina,
un poco de desconfianza,
es que yo no sé
lo que está haciendo
la gente,
no sé qué,
he hecho este drag and drop
porque me sorprende mucho,
me sorprende mucho
que hay gente
que no sabe
que podéis hacer
un drag and drop
nativo con HTML
y JavaScript,
este es el HTML,
aquí tendríamos
el drop zone,
o sea,
la zona de soltar
la imagen
y aquí tengo un image
con la imagen
que quiero cargar,
en este caso
pues no se ve nada
porque no tenemos
el source todavía puesto,
más tiene el display non
porque todavía
no estamos cargando nada,
¿vale?
Por cierto,
sirve con React,
esto lo puedes hacer
con React,
súper fácil,
¿qué es un drag and drop?
A ver,
un drag and drop,
a ver si encuentro
una imagen,
no me está detectando,
me ha dejado fatal,
a ver si lo pongo aquí,
¿qué le pasa a esto?
Ahora sí,
aquí sí,
aquí es que claro,
como de forma nativa,
o sea,
nativa,
como Kodi Link,
aquí en el editor
tienen un drag and drop,
lo que está haciendo
es capturar ese evento,
pero fijaos que aquí
puedo arrastrar la imagen,
¿veis?
Y al arrastrar una imagen
puedo arrastrar otra,
esta,
y cambia aquí.
Lo que estamos haciendo
es capturar el evento
de arrastrar un archivo
y cuando lo capturamos
podemos hacer lo que nos dé la gana.
Entonces,
lo primero que necesitamos
es obviamente
recuperar las referencias
del DOM,
donde queremos soltar
el elemento,
en este caso este,
como donde queremos
renderizar la imagen.
Ahora,
en la zona del drop zone,
que es esto que yo he estilado
así de esta forma
para que se vea visualmente,
tienes que escuchar
el evento de drag over,
esto es cuando terminas
de hacer el arrastre,
no soltar,
todavía no soltar,
sino cuando terminas
de hacer el arrastre.
Aquí no hemos puesto
el prevent default
porque si no por defecto,
fijaos que si quito esto,
aquí por defecto,
esto es lo que hace
el navegador por defecto,
veis que te lo abre
como una pestaña y tal,
pero queremos evitar
nosotros este efecto
que hace el navegador.
Esto lo quitamos,
por defecto,
evitamos tu comportamiento
que tiene el navegador
y lo que vamos a hacer
nosotros es procesar
el archivo,
de forma que cuando
escuchamos el evento
de drop,
evitamos también
el comportamiento por defecto
y de todos los archivos
que se han arrastrado,
porque eso es lo más interesante,
que podéis hacerlo
con más de un archivo,
esto lo estoy haciendo
con uno,
pero lo podéis hacer
con tantos como queráis.
Podéis mirar el tipo
del fichero
y que si es una imagen
que se soporte,
por ejemplo,
si yo intento aquí,
aquí,
intento arrastrar un audio,
ves,
alert,
el archivo no es una imagen
válida,
o sea que solo podéis
arrastrar imágenes,
podéis hacer este tipo
de verificaciones
súper fácil
y utilizando el file reader
que es una API
nativa del navegador
que podéis utilizar
con javascript,
podéis leer
una imagen
súper fácil
como una url,
o sea,
es que no hay que hacer nada,
file reader,
dice leer
el archivo
con una url,
el archivo
este que hemos arrastrado
y ya directamente
tenéis ahí el source
para cargar
como una imagen
y tal,
podéis cargarlo
de diferentes formas
también para leerlo
para poder subirlo
a un backend,
pero tan fácil
como que lo podéis hacer aquí,
podéis poner aquí
subir el archivo
a un backend
y podéis llamar
a un servicio,
podéis hacer mil millones
de historias,
¿veis?
Lo podéis leer
como un stream binario,
como un array buffer,
entonces,
si lo leéis
como un array buffer,
pues es que ya
podríais hacer un fetch
y enviar
el array buffer
al backend que queráis,
pero ya tenéis
un drag and drop
nativo
con javascript,
súper fácil,
¿eh?