[Consulta] Livewire: Método GET no soportado para esta ruta, métodos soportados: POST
(1/1)
UsuarioZ:
Buenas, estoy aprendiendo Livewire, es la primera vez que lo uso y me tira este error al tomar como entrada archivos PDF en un formulario, según tengo entendido Livewire se encarga del método, por lo que no hace falta ponerlo en el formulario, aunque intente agregándolo también para "forzarlo'', pero no funciono, sigue tirando el mismo error, es como si expirase el archivo, también intente subiendo el tamaño máximo en php.ini de "upload_max_filesize" y a "post_max_size" lo setee sin limite de tamaño, también probe en 1G, por las dudas, pero sigue sin funcionar.`
En la imagen sale la versión de PHP, Laravel y Livewire es la ultima estable.
Formulario:
Código
<form wire:submit.prevent='postularme' class="w-96 mt-5">
<div class="mb-4">
<x-input-label for="cv" :value="__('CV o hoja de vida (PDF)')" />
<x-text-input wire:model="cv" id="cv" type="file" />
<x-input-error :messages="$errors->get('cv')" class="mt-2"/>
</div>
<x-primary-button class="my-5">
{{ __('Btn Texto') }}
</x-primary-button>
</form>
---------------
Estuve buscando y creo que voy a cambiar a otro framework directamente, me hubiese gustado Livewire para proyectos chicos, pero no quiero gastarme en estos errores, porque justamente lo que se busca de un framework es reducir el tiempo de producción, creo que son internos del framework, en todo caso, que opinan de AlpineJs? De momento uso ReactJS para proyectos mas grandes, pero no reemplaza a Livewire en proyectos chicos..
Parado_larga_duracion_ESP:
He usado Laravel antaño, es muy completo. Creo que LiveWire no es una buena opción, y que haces bien cambiando a otra cosa. Déjame ver qué es.
Sí, parece un framework para crear fronts desde el back. Cosa que ya tiene Laravel. Pero le da un poco de magia, para que los datos se sincronicen con el back.
Trampa. Estos frameworks son muy ambiciosos en su objetivo. Supabase, Firebase, lo pongo en el grupo. Yo puedo anticipar qué ocurre. Te quitan cierto trabajo, sí, que podrías hacer con llamadas ajax y eventos dom o del shadow-dom. Pero llegará el día en que quieras alterar antes o después, del renderizado o de la llamada de turno, el formato del dato. Y ahí empezarás a ver por qué no mola tanto usar uno de estos. Esta es la primera casuística. Luego vendrán más. Y por si no bastara, puede pasar que falle y no sepas por qué (efectivamente).
Mi consejo es que aprendas a hacer SPAs con un framework front, el que sea. Y para renderizar plantillas del back (SEO, principalmente), orientar el desarrollo a plantillas con jQuery. Mi consejo. La razón es que te interesa un framework que juegue con el dom en crudo, no que haga shadow-doms. Para el SEO. Y eso significa jQuery, si requieres de plantillas, PHP. Pero ni siquiera EJS para 3l front, porque te jode el SEO. Para partes dinámicas de la web que no interesan como SEO sí tiene sentido EJS o incluso Vue, Angular o React.
Pero estos frameworks no... no los he usado, yo. Pero bueno, puestos a usar, yo usaría alguno más famoso. Creo que todos añaden curva de aprendizaje, y te arrebatan el control del flujo de ejecución. Los evitaría, porque no creo que den tanto como quitan y obligan luego.
Es lo que creo.
Navegación