@quenti77 Bonsoir, je suis ce sujet car cela m'intéresse également.
Je ne connais pas React, c'est sans doute pour cela que je me pose la même question. Pourrais-tu expliciter "En fonction de la complexité du front"?
Je sais que Réact se base sur des composants réutilisable, mais j'ai du mal à me représenté quel serait un exemple de besoin. si ce n'est d'effectuer des traitements coté front pour ne pas trop solliciter le serveur.
Pourrais-tu partager ton expérience, par un exemple d'application qui utiliserait Symfony et Réact?
Ce que j'entends par complexité front c'est un peu pour les mêmes raison qui font que l'on décide de passer par un fw côté php. Pourquoi vouloir utiliser Symfony (ou Laravel pour pas de jaloux ) alors que l'on pourrait tout faire en php pur ?
Dans le front c'est peux-être moins visible surtout quand on débute. Je vais prendre ici l'exemple de react ou vuejs car il permettent comme tu l'a mentionner de pouvoir créer des composants contrairement à Angular qui permet de faire plus que de simple composant et aussi car je ne connais pas assez Angular pour en parler.
Si j'ai un petit site assez simple, je pourrai commencer par du js classique pour les petites chose que j'ai besoin. Maintenant le site grossi et j'ai besoin d'un composant qui sera dans plusieurs page. Je peux le faire en JS mais cela reste assez complexe à faire malgré les WebComponents. Mais je peux partir sur react+react-dom ou sur vuejs qui peuvent très bien s'intégrer dans une page simple sans faire tout un système. On y mets le/les CDNs sur les pages qui auront besoin de composants + nos composants et ont aura quelque chose de réutilisable.
Sachant que côté back si on a besoin de récupérer des données Symfony/Laravel (le back) peut très bien soit transmettre dans la page des informations ou l'on peut les récupérer par des routes qui seront donc des API.
Maintenant on peut aussi avoir besoin d'un site complexe, par exemple on pourrait avoir le site visible par les visiteurs qui serait simple mais derrière avoir un admin panel ou même un panel pour les comptes des utilisateurs qui à besoin de plus de reactivité et la on pourrait partir sur quelque chose de plus gros avec un vrai projet react complet ou vuejs complet (routing, store etct) voir même passer par nextjs/nuxtjs.
Du coup le back ne serait plus que des API pour ces parties là (admin panel, user panel). Mais cela nous empêche pas de garder le back pour rendre des pages simples. Je sais d'expérience que dans nextjs tu peux avoir tes routes lié a des pages react mais dire que si la route n'existe pas tu demande à tester l'url sur un autre domain (donc la le back) et c'est le back qui va gérer le routing.
L'intérêt quand tu as des projets c'est que si tu as besoin de sortir ton user panel du site en application mobile et qu'il est décidé d'utilisé react-native ou nativescript alors c'est simple car certains code front pourront être réutilisé et surtout les api du back seront normalement déjà prêtes (si bien sur c'est bien fait )
Pour l'anecdote, avec un ami on avait fait une extension chrome assez complexe et on utilisait juste du js et on avait tellement de galère, quand on à changer pour mettre du vuejs ça nous a simplifier le code et la vie
La pour la suite je vais mettre des liens d'entreprise ou j'était / je suis car je sais comment c'est fait mais en aucun cas c'est de la pub. C'est juste pour appuyer mes propos.
Si on prends le site suivant : https://www.eurecab.com/ la page d'accueil est une page rendu par Laravel classiquement mais derrière je charge vuejs pour gérer le formulaire de recherche qui est un composant vuejs. A l'intérieur il y a même 1 composant vuejs pour la recherche autocomplete google qui en fait est un composant que j'ai créé et qui se trouve sur un repo git à pars du projet.
Si on fait une recherche basique "Orly" -> "Paris" et que l'on va sur la page suivant toute la partis filtre et résultat c'est du vuejs aussi. Et pourtant la page de base est généré par Laravel.
L'autre site : https://www.needhelp.com/ c'est du nextjs et si on prends la page d'accueil c'est même un CMS headless. Si on clique sur "Connexion" c'est du coup gérer par nextjs et non par Symfony. Mais par contre si on clique sur "Publiez une demande" alors on tombe sur une page legacy pour faire une demande (page qui est en cours de rénovation pour passer par next)
Personnellement j'aime bien le fait de créer pour des projets des SPA (Single Page App) car cela veut dire que le back ne se concentre plus que sur des endpoints simple et c'est le front qui gère le reste. Cela ne veut pas dire qu'il n'y a pas d'autre problèmes à gérer mais au moins on peut avoir le front et le back qui évolue un peu plus de leur côté, une fois les contrats d'API créé.
En résumé, c'est pour ça qu'il faut voir "la complexité" et comment le projet va être dans le futur. Si le site c'est juste un petit site vitrine, il n'y a peut-être pas besoin de tout ça. C'est pour ça que j'ai demandé à l'auteur de poser la question du "pourquoi c'est obligatoire ?" Qui a décidé de ça car si l'auteur débute ça pourrait faire l'effet inverse.
Voilà pour mon pavé S'il y a d'autre question je répondrais avec plaisir.
@@quenti77 Bonjour, un grand merci pour ce partage.
>> [...] Du coup le back ne serait plus que des API pour ces parties là (admin panel, user panel). [...]
Je n'avais pas cet angle de vue. J'associais, à tort, une vue automatiquement déterminée par le back ce qui créait dans mon esprit une incompréhension. En plus de m'améliorer d'un point de vue technique sur Symfony, je m’aperçois qu'il existe une multitude de combinaison possible entre le front et le back selon les projets.
Ton explication m'a éclairé. Merci
Interêt de React dans un projet Symfony ?
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
My website : Mon serveur discord, Se demerder tout seul, Faille XSS et SQL
My website : Mon serveur discord, Se demerder tout seul, Faille XSS et SQL