¿Qué te parece Next 14?
La verdad es que desde el 13, el 14,
la verdad es que el 14 ha sido
una actualización, digamos
que el 14 ha sido una actualización más o menos aburrida
porque el 13 fue el
que dijo, ok, vengo a hacer esto
y el 14 ya puso estable todo, digamos
bueno, no todo, pero muchas cosas. Next 14
o digamos el nuevo Next, pasa
exactamente lo mismo que habíamos mencionado, bueno
que yo siento que había mencionado que naces
siendo héroe
y creces lo suficiente para hacerte un villano, ¿no?
Ya ves. Entonces, Next
no es que sea un villano ahora, ¿verdad? La verdad es que
Next tiene una idea de cómo optimizar
el código para que tú
cuando programas, automáticamente
todo tu código está optimizado para ser generado
a la hora del servidor y están apostando muchísimo
porque ese es el camino ahora,
¿no? Tenemos súper
bueno, tenemos servidores en la nube que son muy fuertes
hagamos que ellos trabajen y tratemos de
mandar a los clientes la menor cantidad
de código que ellos ejecuten
y eso hace que tengamos en el Lighthouse
números altísimos sin tener
que hacer muchas optimizaciones por nuestro lado
el problema está de que programar
en Next, digamos que 14
con el App Directory, porque puedes trabajar con el
Pages Directory y no pasó nada, es exactamente
lo mismo, pero si quieres
aprovechar lo nuevo, tienes que trabajar con el App Directory
y trabajar con el App Directory ya es un cambio
de mentalidad. Tienes que desechar
todo lo que habías aprendido de Next, porque ya
las funciones no funcionan igual
los componentes no funcionan igual, inclusive
vas a tener problemas con librerías que antes
usabas que
funcionaba muy bien y ahora
ya no funciona, ahora tengo que envolver
mi aplicación enteramente en un provider
y hacerlo use client
y te pasó por ese lado
Entonces, Next está en un punto donde
te está metiendo server components por todo lado
al inicio
yo lo miraba como que, uff, y si yo no quiero
si yo no quiero, no quiero
quiero trabajar como trabajaba antes en Next
pero perdías todas las optimizaciones
que nos están dando el equipo de Next
ya después de estarlo utilizando, pues
ya, como les mencionaba el equipo de detalle
yo estoy cansado de estar trabajando en React
tengo como 3, 4 meses de solo React, React, React, React
ya estoy, pero...
Ya lo quieres ver más React
Sí, ya estoy hasta la coronilla
de todo lo que es React
pero en general, ahora que veo Next
tiene mucho sentido de que
nos fuerce a hacer server components
nuestro código es más rápido, más ligero
más, a la larga funciona
mucho mejor
y vale la pena esa actualización
cuando uno está trabajando
en un componente, una página
y uno quiere que solo sea
una pequeña porción de la página
sea generada al lado del cliente
creas un cliente
o un componente independiente
le pones Use Client
y ya trabajas de la manera tradicional
Los server components
tienen todo sentido del mundo
al final es una mejora de rendimiento
que es que si no, React
bueno, React
que estaba antes enfadado uno
de cómo lo pronunciaba
pero el tema es que
que el cambio ha sido
como demasiado bestia
ha tenido que llevar
claro, por un lado
teníamos los server components
pero es que por otro lado
también el app router
y es que por otro lado
y como que se han juntado
demasiadas cosas
que a lo mejor
si lo hubieran hecho
de una forma más escalonada
hubiera ayudado más
a que la gente
lo tragara mejor
mi sensación ha sido
que se han intentado
adelantar mucho
incluso con Turbo Pack
les ha pasado
que en Alpha
esto es tan Alpha
esto es tan Prueba
esto no sé qué
esto no sé cuánto
y constantemente
lo que ha pasado
es que creo que la gente
ha llegado un momento
en el que se ha agobiado
se ha agobiado
incluso a la vez de todo esto
también tenemos
los server actions
que ahora hablaremos de esto
porque ha sido
una de las grandes polémicas
y que hablaremos
de un tema
que me parece muy importante
sobre el tema
de la escalabilidad
del código
que es algo muy polémico
pero el tema es
que por suerte
en X14
lo que decías tú
que ha sido
un lanzamiento muy aburrido
que no tiene nuevas APIs
y que la idea es
pues hacer que sea estable
todo lo que hasta ahora
nos habían enseñado
también es verdad
que el problema
es lo que tú dices
¿no?
tener que convivir
pages con App Router
exactamente
entonces
porque
funcionan
funcionan entre sí
puedes usar
puedes usar ambas
de manera simultánea
ir migrando
paulatinamente
las nuevas
pero
creo yo
que eventualmente
te van a forzar
bueno quién sabe
porque RIA
todavía soporta
class-based components
entonces no se sabe
pero la verdad
es que yo pensaría
en que todo lo que
ustedes van a hacer
ahora en Next
usan la característica
del App Directory
y acostúmrense a hacerlo
de la nueva manera
porque es
es lo que Next
le está apostando
no van a tener
más mejoras
en
valga la redundancia
más mejoras
pero ya van a tener
más
bueno ya no vamos
a tener mejoras
con el Pages
claro
eso seguro
ya no está
moviéndose para ese lado
server components
no vas a tener
en Pages nunca
o sea
eso no va a pasar nunca
mira
hay una pregunta aquí buena
Liz Android
dice
si hoy tuvieras
que elegir un framework
para empezar un proyecto
desde cero
¿cuál elegirías?
sería bueno que nos dijera
qué tipo de proyecto es
¿no?
para
mira
pensemos
detalles
imagínate que tienes que hacer
la propia
plataforma
de detalles
hay muchas cosas ahí
que si ocupamos
SEO
a fuerza
nos bota la mitad
de las tecnologías
¿no?
ocupamos SEO
a fuerza
y optimizaciones
del lado
del servidor
tenemos candidatos
fuertes
obviamente
sería bueno
irse por un
alguien que tenga
trayectoria
alguien que tenga
mucho tiempo
de existir
en este caso
estaríamos hablando
de Nex
o Remix
por ejemplo
son dos alternativas
que valdría la pena
irse por ese lado
si quieres
ahorita yo estoy terminando
mi sitio web
me cuesta sacar tiempo libre
estoy haciendo todo
con Quick
entonces
Quick me ha gustado mucho
hay que esperar
que Quick crezca
para que
para ver si hace
alguna competencia seria
en el stack
de tecnologías
¿no?
pero yo me iría
por Nex
si me tocara escoger
me iría por Nex
principalmente
por la
por la trayectoria
que ha tenido
por la estabilidad
que ha tenido
por la empresa
que lo respalda
por la comunidad
hay muchas razones
vas a querer
usar una tecnología
que esté bien respaldada
y que la comunidad
sea grande
porque cuando tengas
un problema
porque te vas a enfrentar
a problemas
tú vas a esperar
buscar soluciones
rápidamente
y vas a apoyarte
en la comunidad
y obviamente
digamos que vas a llegar
a ChargyPity
a preguntarle algo
entonces ChargyPity
también se basa
en las preguntas
de la comunidad
entonces es más difícil
resolver problemas
si eres el primero
que te enfrentas
a esos problemas
claro
exacto
claro
porque por ejemplo
la que dice la gente
Svelkit
pero claro
Svelkit
sí
Svelkit
es una opción
interesante
pero justo lo que dice
lo que dice Fernando
que a ver
opciones todas son interesantes
todas tienen un poco de comodidad
Svelkit
Nook
Solidstar
Next Remix
pero yo entiendo
el punto de Fernando
si al final
tienes que crear
una página
para su academia
que es algo
que tiene que
perdurar
en el tiempo
tiene que funcionar
quieres además
contratar a gente
que sea la persona
que mantenga
porque Fernando
no tiene tiempo
para mantener la plataforma
y va a querer gente
que le ayude
va a querer maximizar
la posibilidad
de contratar gente
y por lo tanto
no va
no va a utilizar
una tecnología
Svelkit
puede ser interesante
pero luego
va a ir a ir al mercado
y va a decir
ostras
me va a costar
contratar gente
que sepa
Nex
que sepa Svelkit
claro
es que hay que verlo
de otros puntos de vista
pero
de nuevo
si fuera un proyecto
que es un piloto
o es una demostración
o es un proyecto experimental
que puede que tenga
digamos
contrataciones a futuro
pero no estás
todo seguro
entonces puedes darte
la oportunidad
de probar una nueva tecnología
así la aprendes
así te enfrentas a eso
no digo que esas tecnologías
sean malas
pero es que es diferente
la visión final
a la que vayas
o el objetivo final
al que vayas
y de nuevo
a veces vale más
malo conocido
que malo por conocer
malo conocido
que malo por conocer
dicho así
la frase
malo conocido
que bueno por conocer
claro
si es malo por conocer
no se sabe
tienes toda la razón
es que es verdad
yo estoy haciendo
yo estoy haciendo
el sitio web
mío con Quick
espero
pues cuando termine
la reglación
del curso de Nex
creo que me voy a dar
una semana
para terminar eso
pero con Quick
yo he tenido varios inconvenientes
que he buscado en internet
y a saber
no encuentro ninguna solución
entonces me ha tocado
investigar
y reinvestigar
y hacer unas cosas
que no sé
si están bien hechas
pero me ha funcionado
pero a veces uno sabe
que uno sabe
cuando ve un código raro
dice
esto
esto no está alto
también me ha tocado
investigar mucho
claro
algo interesante
que tiene Quick
es que Quick
hizo los server actions
en producción
antes que Nex
mucho antes que Nex
sí sí sí
que nadie
nadie se quejó
nadie se quejó
por hacer un SQL
directamente en el template
sí sí sí
y hace exactamente
exactamente lo mismo
de hecho
lo mostraron aquí
en directo
en exclusiva
cuando estaba en Alpha
imagínate
ya hace muchísimo tiempo
hace más de un año
diría
y nada no
ahí la gente
no se quejó
nadie
mira
dime
no no
lo que hay que acordar
es que los server actions
de Nex
están bien probados
o sea
uno no va a poder hacer
una inyección de SQL
o un server action
a menos que
tú no estés
sanitizando
tus variables
pero en los ejemplos
que ellos han mostrado
en pantalla
no se hacen inyecciones
de inyección de SQL
ya
ahora hablamos
de los server actions
vamos a unas preguntitas
que han dicho por aquí
para que
que están relacionadas
como por ejemplo
Feral
que dice Fernando
¿le ves futuro a Remix?
porque lo han mencionado
¿lo consideras una buena alternativa
a NexDS?
sí
yo no quiero una buena alternativa
yo no estoy muy
en el lado de Remix todavía
o sea
no estoy tan ahí
de ese lado
pero sí es una muy buena alternativa
desde que se hicieron
open source
es una muy buena alternativa
y también
porque mucha gente
no le gusta
que te metan
server components
a la fuerza
es una buena alternativa
trabajar con Remix
o sea
pero de nuevo
si me tocara hacer un proyecto
entre estos dos
me iría por Nex
¿cómo ves esa polémica?
porque hay una polémica
en la que mucha gente
se queja
que React
o React
React
se ha metido mucho
dentro de Nex
¿no?
que tienes parte del equipo
ahora está dentro de Nex
yo tengo
no sé
no sé bien
perdón
sí
sí
sí
sí
no
o sea
básicamente
que parece que sea Nex
el que toma las decisiones
y la evolución
de React
sí
hasta donde sé
Nex ha jalado muchos
ingenieros
que han participado
en el desarrollo de React
para ser parte de Nex
es que lo que pasa
es que Nex está creciendo mucho
y de nuevo
cuando tú tienes
o necesitas CEO
ya no vas solamente
por React
ya dices
voy a irme por Nex
bueno básicamente
la gente piensa directamente
en Nex
y tiene sentido
de que sea Nex
quien esté moviendo
la parte de React
o sea
es como
uno de los principales
consumidores
de React
entonces
honestamente
a mí me preocupa
de que
todo esto se privatice
que venga una empresa
y que adquiera
digamos
todo
como los de OpenAI
que venga Microsoft
y compre todo el mundo
y ahora está mi burbuja
y se haga un monopolio
¿no?
eso es
algo que no me gusta pensar
pero
yo lo que esperaría
es que React
siga
siga evolucionando
yo honestamente
estoy sorprendido
de que React
todavía no haya metido
lo de las señales
ya eh
bueno es que están en contra
es que no quieren meterlo
es que son cabezones
es que no
eso es una cosa
que no se le puede negar
y es que siempre
tienen muy claro
la dirección a la que quieren ir
otra cosa es que sea
la dirección correcta
o lo que sea
pero los hooks
un montón de gente
estuvo en contra
de los hooks
y tal
pero nada
ellos dijeron
hooks, hooks
y al final mira
los hooks
sí que triunfaron
ahora veremos
con esta decisión
de los signals
que parece que todo el mundo
dice no
y ellos
R que R
que no
yo estaba esperando
de que pronto
los anunciaran
o estuvieran en alfa
o algo
pero
pero nada
no hay forma
mira
por aquí
dice también
bueno vamos a hablar
porque están hablando
ya de los server actions
pues vamos a hablar
de los server actions
y así
porque vamos a hacer una
vamos a mostrar la imagen
la polémica
de la polémica
yo sé cuál es
esa imagen
esta imagen
por cierto
yo estuve probando
bueno
yo obviamente
también probé
ese código
pero
esto
si ese bookmark
fuera un client component
me ha marcado errores
hacer esa sintaxis
por ahí
me pide que la función
que está dentro
ese use server
esa función así
con la que está dentro
del botón
me pide que sea
un archivo independiente
ahora
ya no me permite hacerlo
si es un client component
es decir
use player en el inicio
del archivo
metieron error
en fin
pero lo que pasa
en ese punto
es que lo que
muy poca gente ve
es que ese SQL
que está antes
justo después de la web
eso es un
un paquete propio
que tiene la gente
de Bercel
que hace
la conexión
que hace la sanitización
que previta
la inyección de dependencias
que escapa los valores
o sea
hace más cosas
de lo que parece
y eso evita
la inyección de dependencias
si tú no usas
ese SQL
o sea
es una función
de los simples literales
si no la utilizaras
si puede haber
inyección de dependencias
inyección de SQL
si no estás escapando
la información
pero no
lo interesante
de los server
de los server actions
solo para
las personas
que pues
no están
enterados del todo
es una forma
de poder ejecutar
una función
del lado del servidor
que es llamada
desde el cliente
desde un navegador web
digamos
sin necesidad
de crearse
un RESTful API
sin tener que llegar
a hacer todo el protocolo
de que en el servidor
hay que crearse
alguien que escuche
el endpoint
y validar
el toque
o sea
hacer
infinidad de cosas
ahora tenemos
una posibilidad
de hacer ese llamado
que en lo personal
me gusta
o sea
en lo personal
me gusta
porque es que
si quisiera hacer
eso mismo
hay que crearse
es el pinche
RESTful API
hay ahí
antes no quedaba
de otra
así era
así era
ahí quiero llegar
ahí quiero llegar
porque mucha gente
de lo que se queja
bueno hay diferentes niveles
no está el nivel
que dices tú
de es que aquí
hay una inyección
hay una inyección
de que se están metiendo
aquí algo
no sé qué
y bueno
es verdad
que esto se sanitiza
porque al final
esto es un template
literal y tal
luego hay gente
que dice
bueno
a lo mejor
esto no es un problema
de seguridad
vale
pero
sí que tienes el tema
de que no me gusta
la cadena de texto
yo estoy en ese grupo
yo estoy en ese grupo
yo estoy de acuerdo
de que ese código
no se debe de hacer
o sea
ese código no se debe de hacer así
eso es una demostración
de que se puede hacer
pero no se puede hacer
yo prefiero
en ese caso
tener un
digamos
un
un directorio
un directorio
donde tengamos nuestras acciones
por ejemplo
acciones de autenticación
entonces aquí están
las acciones de autenticación
todas esas
que son con el use server arriba
para que la gente
no vaya accidentalmente
igual no se podrían ejecutar
pero accidentalmente
mandar información
al lado del cliente
exacto
y simplemente la llamo
y queda
el código queda muy limpio
y muy fácil de leer
por ejemplo
ese botón llamaría
a la función
que eso lo que hace
es insertar
en los bookmarks
el slog
o sea
como grabar
en el directorio
de mis favoritos
digamos
el url
de ese
de ese
blog
digamos
pero si los tienes
así agrupados
es fácil de mantener
fácil de leer
se puede reutilizar
fácilmente
entonces no está tan mal
pero hacerlo así
como lo puso ese tipo
así no
no me gusta mucho
claro
y luego tenemos
el punto de
la gente que se queja
por rollo
pues hay un montón
de ataques
de es que esto
parece PHP
es que está mezclando
el código
y luego un tema
de esto tendría que ser
una API
que está bien
porque tú lo has mencionado
justamente
hay gente que se queja
de que con esto
no creas la API
lo cual yo estoy de acuerdo
contigo
de que a mí me parece
algo positivo
porque digo bueno
pero por qué
tengo que crear una API
a veces tener una API
tiene todo sentido
el mundo
pero en este caso
yo o sea
yo me quiero evitar
una API
porque al final
lo único que quiero hacer
es conseguir esto
sin necesidad
pues algo
o sea imagínate
que quieres
cambiar
un corazoncito
de favorito
en un post o no
o sea estás haciendo
algo como medium
y quieres tocar
un botón de un corazoncito
y cambiar favorito o no
y eso no va a ser expuesto
al mundo exterior
es decir
es algo que solo va a tener
esta aplicación
si no teníamos
los server actions
hay que llegar
a crearse
el API
y hay que crearse
la validación
del token
hay que crearse
la parte de recibir
los argumentos
validar los argumentos
dar una
emitir una respuesta
y aparte
tienes que llegar
del lado de react
y que tienes que disparar
la petición
tienes que escuchar
la respuesta
tienes que validar
la respuesta
si la respuesta
es positiva
hacer una cosa
si es negativa
es otra
si da un error
es otra
y solo es para hacer
un toggle de un corazón
que yo le quise dar
a un corazoncito
like o no
entonces con un server actions
haces la función
haces la modificación
si sale bien
retornas algo
si sale mal
retornas algo
y puedes trabajar
como si nunca salieras
de react
con un use state
digamos
mientras estoy haciendo
la petición
entonces cambio el state
que se muestra
un spinner
ya se hace
luego regreso
al use state
es muy fácil
es muy fácil
y al final
lo que nosotros queremos
es ser efectivos
y eficientes
con nuestro tiempo
hacer todo ese
API
para algo tan sencillo
claro
aquí tenemos este ejemplo
aquí sería
como sería antes
donde sí o sí
tenemos que crear
arriba a la izquierda
el handler
que es
aunque por pequeño
que sea ese código
tenemos que crear
justamente
pues eso
tenemos que crear
la API
y abajo tendríamos
la parte del componente
donde además
en el on-summit
tendríamos que hacer
el fetch
habría que hacer
claro
la petición
a esa API
esperar y tal
y enviar la información
este es el ejemplo
como más sencillo
donde lo han hecho
lo más corto posible
y en el after
a la derecha
tendríamos justamente
como sería ahora
y obviamente
hay otro punto
en este código
que ellos también muestran
o sea obviamente
es lo mínimo necesario
porque ahí no hay
no hay
ninguno de los dos
tiene manejo
de excepciones
ni validaciones
ni nada
ni loading
pero si está bien
está bien que sea
lo más pequeño posible
pero hay otra cosa
que pasa con los server actions
porque ellos están llamando
desde un form
el action
y está mandando llamar
el create
que eso está bien
eso manda todo
el formulario
ese form data
y se ve que
en el after
se ve que se manda
todo el form
from data
eso hace que uno
tenga que
controlar también
el estado
del formulario
en el ejemplo
que ellos tienen
de next
en la documentación
en el punto
porque ahorita estoy
casualmente en eso
en el ejercicio
que ellos tienen
de agregar
la autenticación
tienen un hook
o sea
una manera
de estar pendiente
del estado del formulario
para poder bloquear
los botones
en el caso
de que
por ejemplo
si tocas ese botón
ahorita
en la parte del after
y tocas el botón
de submit
el botón no va a reaccionar
si se está posteando
o no
simplemente
lo tocas
y lo puede tocar
un montón de veces
pero si quieres bloquear
ese botón
basado en la acción
del servidor
o sea
en el server action
que se está disparando
tienes que hacer
un poquito más
de boilerplate
claro
tienes que utilizar
si no me equivoco
esto
tienes que poner
el use form status
tienes que saber
si está pending
si
exactamente
con esto
puedes controlar
tienes que importar
pues esto
use form status
ese submit button
tiene que estar dentro
es un componente aparte
que está dentro
del formulario
entonces
claro
tienes que separar
el componente
ahí es donde yo creo
que está el problema
conceptual
que muchas veces
no queda claro
porque esto entonces
te obliga a separarlo
pero esta parte
tiene que ser un use client
porque no puede ser
ya un server
pero de nuevo
esto es como
un camino para hacerlo
porque
yo he probado
dos alternativas
uno es mandar a llamar
el server action
directamente desde el formulario
así como este ejemplo
y pues toca manejarlo
así como ellos lo mencionan
que
igual uno se acostumbra
pero también lo puedes manejar
de la manera tradicional
donde tú tengas
tu propia función
en el componente
la función internamente
llama el server action
y lo manejas
de la manera tradicional
también
de las dos formas
se puede hacer
y de las dos maneras
uno tiene
pro y contras
¿no?
sí
el problema que yo siento
es que
de nuevo es
que ahora tenemos
varias sintaxis
y el tener varias sintaxis
hace complicado
aprenderlo
por ejemplo
las personas que decidan
hoy
aprender Next
pues van a aprender
con el app directory
sería lo mejor
claro
sin problemas
pero
capaz los contratan
a ellos
para darle mantenimiento
a una aplicación
legacy de Next
y no tiene que ser
ni legacy
puede ser de la versión
migrarla
del pages
al app
y eso va a quedar
bueno
y todo esto que es
claro
o viceversa
puede ser que ustedes
sepan Next
pero
ahora que irse al app directory
y van a pensar
ah bueno
y dónde está el get service
de props
o get service
de path
ya nada de eso existe
ya no se usa
y ahí salió otra vez
el botón de ese
el corazoncito
sé que sale
a veces
ojo
vamos a hacer de una captura
de pantallas
ese es el corazoncito
de Next
yes
en fin
la cosa está
de que
eso es un punto complicado
para la gente
que
que está
o sea que
es un punto raro
en el cual nos encontramos
en Next
donde tenemos
esas dos sintaxis
y
cuál aprendemos
hay que aprenderlo
claro
claro hay que aprender las dos
porque las dos tienen trabajo
yo intentaría a día de hoy
aprender la del app router
porque me parece
como que es la más
la que más va a estar utilizando
claro
es que es
la que está ahora
pero es verdad
y para mí es un problema
que me pasa por ejemplo
si estoy utilizando
su pavés
si estoy utilizando
lo que sea
cualquier dependencia
como que me cuesta mucho
saber si el código
que estoy viendo
de ese ejemplo
realmente funciona
para app router
para pages router
eso es un
es un
veren
cualquier librería
que uno quiere instalar
en Next
tiene que verificar
de ok
esto
el ejemplo
que está aquí
funciona en pages
o funciona en app
algunas lo dicen
algunas ya están actualizadas
y lo dicen
pero hay otras que no
hay otras que
andaban
investiga tú
la teoría sería
si hay algo
que se genere
del lado del cliente
tienes que hacer
use client
pero si hay algo
que tienes
o sea
si puede ser generado
del lado del servidor
ahí sí no hay problema
pero si hay algo
que si hay un hook
una regla sería
si hay algún hook
algún use
use client
es lo que tienes que usar
es un client con port
exacto
mira tengo
tengo este
este es el
este es el
justamente lo que te comentaba
¿no?
vale
¿no es un poco spaghetti
mezclar todo esto?
por ejemplo
el front
debe aprender todo
lo relacionado a consultas
de SQL
incluso las complejas
o igual se pueden separar
equipos de front y back
no no
siempre se puede separar
es que lo que pasa aquí
no es que
claro
es que
es que lo que
lo que
o sea
imagínate que tú quieres
trabajar con un server action
pero tú ya tienes montado
tu
tu RESTful API
porque se va a pegar
a los servicios
de la empresa
¿ok?
entonces
tú puedes
o sea
es que
hay de todo
¿no?
pero tú puedes mandar
a llamar un server action
y el server action
es quien hace la comunicación
al RESTful API tradicional
y tú todo lo haces
mediante server action
no necesariamente
es que el del front
tiene que
literalmente hacerse
el pegue
de datos
o sea
nuevamente
un server action
no es más que ejecutar
un código de lado del servidor
eso es todo
el server action
llega al servidor
y lo que quieres hacer
en el servidor
ya es cuestión tuya
si el servidor quiere llamar
un RESTful API
adelante
o quieres
simplemente trabajar
de la manera tradicional
no necesitas hacer
un server action
no los uses
no es a fuerza
no es obligatorio
claro
puedes seguir utilizando
de la manera tradicional
exacto
nadie te obliga
y de hecho
una cosa que veo
que mucha gente se confunde
y hay que tener en cuenta
en la parte de la derecha
en el after
lo que estáis viendo
es que esta parte de aquí
esta del create
este método
no llega al frontend
¿vale?
porque hay gente que decía
pero esa parte
si no se ofusca
no sé qué
es que esta parte
que antes se veía en el SQL
y la gente decía
claro pero el SQL
eso llega al frontend
eso es un método
que se extrae
y que solo se ejecuta
en el servidor
o sea
no llega al bundle
del cliente
esto no llega al cliente
estos códigos servidor
100%
no vais a ver
ese código
en el bundle
del javascript
que llega al cliente
que es súper importante
¿vale?
entonces ni se queda
se ofusca
porque no existe
en el cliente
para que tengas en cuenta
porque todo el server
componen
el cliente llega
solo html
no llega
no llega
ese código
exacto
y luego
lo que
claro
también tenemos
que tener en cuenta
que
que esto
al final se hace
también justamente
para que la latencia
sea menor
porque si haces un fetch
a una app
y que no sé qué
que no sé cuánto
al final la idea
es que
cuando hagáis esto
se ejecuta directamente
del servidor
y lo que hace
es devolver el resultado
que haya habido
de eso
los server components
esa es la idea
los server components
tampoco llegan al cliente
justamente para evitar
enviar javascript
que no necesita
que entiendo
que es complicado
y que
por supuesto
lo que decía es también
de que si tenéis
diferentes equipos
tampoco pasa nada
podríais tener un equipo
que tenga un paquete
de npm
que le puedes llamar
server actions
que todos los server actions
estén en ese paquete
totalmente separado
y entonces
lo que haces aquí
es este método
no lo tendrías aquí
porque esto lo hacen aquí
por un tema de demostración
obviamente
y que importes
por ejemplo
importar
crear usuario
create user
¿vale?
y entonces esta action
tú le envías el create user
y ya está
y esté totalmente separado
es que no hace falta
ni que lo tengas
en el mismo proyecto
obviamente
sí que lo vas a necesitar
en el mismo proyecto
pero que lo tengáis en cuenta
que al final
esto al final
se va a ejecutar
donde queráis
¿vale?
que no necesitáis tenerlo
dentro del componente
que es que
es que lo malo
de los ejemplos
que como siempre
lo hacen dentro del componente
mucha gente se cree
que tiene que estar
por narices
dentro de los componentes
sí a mí no me gusta
sí a mí no me gusta
mezclar esas cosas
de hecho los componentes
trato de que sean
lo más sencillos posibles
el componente
que se
o sea las páginas
tienen que ser
lo más
puras
en cuanto al html
para que uno sea
o sea que uno vea
el componente
y ya sepa lo que es
no debería haber
mucha lógica
en un componente
si hay mucha lógica
hay que separar eso
hay que ponerlo en archivos
independientes
o crearse
hooks
o algo
pero no
los componentes
no tienen que ser
tan pesados
este ejemplo
obviamente pues
es un ejemplo
que se puede hacer
pero no
yo no lo haría así
pero
sí sí
perdón
la verdad
es que había una preguntada
interesante
pero
obviamente lo que
de nuevo
lo que haría yo ahí
con ese after
sería ese create
ponerlo en un directorio
con sus acciones
y eso no sé
que es
create item
o create item
tendría el create item
en un
no sé
una carpeta
que se llame
items
o algo así
si fuera una tabla
y ahí
create item
en la acción
para que
simplemente
desde nuestro formulario
sería create item
y ya
y eso es todo
lo que tendríamos
en el
en ese page
ahí está
pero
mira
hay una pregunta
aquí de Diego
que dice
no se supone
que todos los componentes
por defecto
son de servidor
hasta que uno pone
el use client
para que sea de cliente
para que pongo
el use server
la verdad que eso es
es lo complicado
a mí es una de las cosas
de mis mayores críticas
es que a mí personalmente
no me gusta nada
el magic string que ese
del use client
y el use server
porque me parece muy hacking
y que
y que confunde mucho
y como que me parece
muy complicado
y que al final
es tan fácil
equivocarte
sabes como que me gusta
mucho más
como lo ha hecho
quick
que tienes que importar
si no me equivoco
no sé si tienes que importar
o es una propiedad especial
el símbolo de dólar
que
es el símbolo de dólar
sí pero para server actions
no me acuerdo
como se llama
hay que importar
una función en particular
hay que exportarla
y ponerla al inicio
del archivo
se llama
algo
tiene algo
que me parece
un poquito mejor
que el magic string
de use server
y luego pasa estas cosas
que hay gente
que ya se vuelve
un cacao
porque use client
es a nivel de componente
use server
es a nivel de función
es que lo que pasa
con next
es que por defecto
dejad la pregunta
que tenías
lo que pasa
no para poder ver
el nombre
es diego
ahí lo tengo
aquí lo estoy viendo
lo que pasa aquí
diego
es que
next busca
o sea imagínate
un árbol
un árbol
muy corriente
un árbol
de los que están
allá afuera
entonces
todas las hojas
de ese árbol
están generadas
del lado del servidor
o por lo menos
next
con el app directory
busca de que
todas esas hojas
estén generadas
del lado del servidor
eso hace que
cuando tú entres
a una pantalla
ya esté previamente
generada por ti
cuando ese es el proceso
de construcción
ya todo eso está
generado por ti
y el servidor
se lo manda
y no tiene que procesar
otra vez el componente
porque ya está creado
pero llega un punto
donde hay ciertas
interacciones
que el usuario va a tener
o hay ciertas
acciones
que digamos
que interactividad
que tú quieres añadirle
y el cliente
tiene que renderizarlas
o sea
tiene que renderizar algo
entonces lo que buscan
es que solo ciertas
pequeñas hojas
así bien externas
de ese árbol
sean generadas
del lado del cliente
entonces para eso
es que uno le pone
el use client
en esas páginas
en particular
en esas hojas
entonces sí
es algo
eso es algo
tal vez enredado
de aprender al inicio
cuando usar use client
y cuando usar use server
porque el use server
por defecto
siempre está
o sea
siempre está puesto
automáticamente
aunque no lo quieras
siempre está el use server
pero de repente
cuando tú ya
te das cuenta
de que quieres usar
algún hook
cualquier hook
que quieras usar
no solo de RIA
cualquier use algo
ya necesitas hacer eso
que sea un client component
y lo que hace
es que básicamente
Next le va a mandar
todo el código
al cliente
para que construya
él el componente
y ahí ya vienen
otros rollos
aquí dice
pienso en vez de
use client
o use server
pienso que hubiera sido
mejor decorar el método
con server
se ve menos hacking
estoy bastante de acuerdo
porque al final
un decorador
sí que es parte
del lenguaje
y hubiera sido
mucho más fácil
no sobrecarga esto
el trabajo del servidor
justamente lo decía
Fernando
la idea
la idea es que el servidor
trabaje más
el servidor
es que de nuevo
el servidor
no es que va a trabajar
más
porque cuando ustedes
hacen el build
de la aplicación
de Next
mucho código
ya está
ya está creado
sería
la mayor parte
del servidor de Next
va a ser
ok me está pidiendo
esta información
yo la tengo creada
este es el archivo
alguien más me lo solicita
es este mismo archivo
y hay que tener cuidado
porque si uno no le pone
la revalidación
a los componentes
Next va a manejar
el caché
y te lo va a regresar
estático siempre
toda la vida
entonces le va a pasar
mandando los componentes
que ya han sido creados
y solo son
los que son realmente
dinámicos
lo que ustedes dicen
este componente
es altamente dinámico
entonces le vamos a poner
el revalidar en SEO
o el force dynamic
que es que siempre
que lo haga la solicitud
al servidor
lo genere el servidor
pero usualmente Next
su trabajo va a ser
enviarle contenido
estático al cliente
y eso hace que trabaje
trabaja lo mismo
que cualquier otro servidor
y además es que
la idea además
lo que tenemos que entender
es que
queremos que trabaje
el servidor más
porque
lo peor que tenemos
son los dispositivos
pensar que en un móvil
no sabéis
la potencia que tiene
la conectividad que tiene
lo que queréis
es evitar a día de hoy
que el dispositivo
haga ese trabajo
porque va a tener
una peor experiencia
de usuario
va a ser mucho mejor
que el servidor
que conoces
la potencia que tiene
la conectividad que tiene
lo haga lo antes posible
y ya le dé el resultado resuelto
es como cuando hacemos
un renderizado en el servidor
lo hacemos
porque justamente sabemos
que el servidor
va a ser mucho más rápido
que lo que va a hacer
en el cliente
pese a que esté
en una máquina bovestia
porque al final
tú no puedes controlar
la conectividad que tiene el usuario
ni la potencia que tiene
y ya después
es más fácil poner
un balanceo de carga
digamos vamos a tener
dos servidores
dependiendo de quien se conecte
dependiendo del trabajo
que esté uno
vamos a hacer que uno responda
o el otro
entonces es
es más fácil escalarlo
pero
de nuevo aquí queda mucho
a discreción
de lo que
de tu objetivo
si tienes una aplicación
altamente transaccional
obviamente vas a querer
tratar de manejar
lo más posible
en caché
para que tus servidores
no estén
procesando cada petición
pero si es una aplicación
por ejemplo
de la intranet
que no le importa
el CEO
entonces ahí puedes hacerlo
puramente en React
y lo pones en
o sea vas a tener
que 10.000 usuarios
20.000 usuarios
eso no es nada
para un servidor
y le mandas todo el spa
toda la aplicación
sin Lazy Lobe
que es cargar un mega
por red local
es nada
ahí estás controlando
más el dispositivo
que es
porque no lo van a utilizar
un móvil
porque están en la oficina
porque tienen buena conexión
es que
a ver qué más
dicen por aquí
vale este ya lo hemos leído
el problema de esto
esto no lo he entendido
el problema de esto
es que solo servirá
para proyectos
que solo tienen cliente web
en caso de que el proyecto
tenga un cliente mobile
no se podría usar
este backend
bueno en mobile
también tienes conexión
a
solo servirá
para proyectos
que tienen un cliente web
o sea es que
lo que lo que pasa
es que Next
propiamente
es para crear
una página web
una aplicación web
si lo que estás pensando
es usar React
para hacer una aplicación
nativa
así como bueno
como con Electron
una cosa así
ahí sí
es otra cosa
dice por aquí
hombre pues yo prefiero
que sirvió de trabajo
menos
sobre todo si el proveedor
de nube me cobra
exactamente
ese es otro punto
claro
esto es verdad
pero es que hoy en día
por ejemplo
Bersel
pongamos Bersel
¿cuánto te cobra Bersel?
si es que
para tu proyecto
Hack on Dalbert
por ejemplo
es que
es que es irrisorio
hoy en día
el coste que tienes
de trabajar en la nube
no es el que teníamos antes
incluso para
grandes
grandes empresas
puedes mirar
por ejemplo
las Clover Workers
si es que vas a ver
el precio que tiene
y es irrisorio
entonces
muchas veces
las empresas
que realmente hacen plata
les va a interesar
comerse ellos el coste
en el servidor
que no entregar
una mala experiencia
de usuario
porque al final
en la conversión
que van a tener
va a ser mucho mejor
como dice Fernando
obviamente hay casos y casos
pero hay casos
en el que no te des a la cuenta
es que el servidor
no es que va
o sea
si va a trabajar
un poco más
pero realmente
no es una
no es tan diferente
porque
aunque tengas tu aplicación
desplegada en la web
siempre va a haber
una solicitud de un cliente
que va a solicitar
tu página web
esa solicitud
siempre está
entonces
si el contenido
de tu página web
está estático
el servidor va a tener
menos procesamiento
porque no tiene que
construir la página
o sea no tiene que usar
procesador
para construir la página
porque ya está creada
eso es lo que hace Next
y le manda código estático
ya creado por ti
y solo son ciertas partes
de las que sí va a ocupar
el servidor interactuar
los server actions
siempre van a
hacer una mínima petición
HTTP
que es mucho más pequeña
que la petición HTTP
tradicional que haces
con un RESTful API
o sea solo va a extraer
la data
y lo regresa
en lugar de mandar
tantos headers
las cookies
que puede ser un montón
de datos
o sea
la información que viaja
en un server action
siempre hace una petición HTTP
pero es mucho menor
a crearse todo el API
y ahí trabaja menos
entonces como es
el tiempo lo va a decir
si realmente Next
tiene la visión correcta
de esto
exacto
funciona
¿no?
No
難é
¿no?
K
que
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K
K