HashRouter vs BrowserRouter

112

Je suis nouveau dans la programmation, ce qui rend les choses légèrement difficiles à comprendre si je lis la documentation officielle.

Je lisais à propos de React Router 4 d'ici

Dans cet article, l'auteur parlait de <HashRouter>et<BrowserRouter>

C'est ce qu'il a mentionné

HashRouter utilise essentiellement le hachage dans l'URL pour rendre le composant. Depuis que je construisais un site Web statique d'une page, j'avais besoin de l'utiliser.

BrowserRouter , il utilise l'API d'historique HTML5 pour rendre le composant. L'historique peut être modifié via pushState et replaceState. Plus d'informations peuvent être trouvées ici

Maintenant, je ne comprends pas la signification et les cas d'utilisation des deux, comme ce qu'il veut dire quand il dit que l' histoire peut être modifiée via pushState et replaceState et qu'il utilise le hachage dans l'URL pour rendre le composant

Alors que la première explication de BrowserRouter est entièrement vague pour moi, la deuxième explication sur HashRouter n'a pas non plus de sens, par exemple pourquoi quelqu'un utiliserait Hash (#) dans l'URL pour rendre le composant?

iRohitBhatia
la source
Vous n'avez pas fourni de commentaires sur les réponses existantes. Puisqu'ils répondent déjà directement à la question, il serait utile de clarifier le type d'attention dont la question a besoin.
Estus Flask

Réponses:

126

BrowserRouter

Il utilise l'API historique , c'est-à-dire qu'il n'est pas disponible pour les anciens navigateurs (IE 9 et inférieurs et contemporains). L'application React côté client est capable de maintenir des routes propres comme example.com/react/route mais doit être soutenue par un serveur Web. Habituellement, cela signifie que le serveur Web doit être configuré pour une application d'une seule page, c'est-à-dire qu'il index.htmlest servi pour / react / route path ou toute autre route côté serveur. Côté client, il window.location.pathnameest analysé par le routeur React. Le routeur React restitue un composant pour lequel il a été configuré pour / react / route .

En outre, la configuration peut impliquer un rendu côté serveur, index.htmlpeut contenir des composants rendus ou des données spécifiques à l'itinéraire actuel.

HashRouter

Il utilise le hachage d'URL, il ne met aucune limitation sur les navigateurs ou le serveur Web pris en charge. Le routage côté serveur est indépendant du routage côté client.

Une application monopage rétrocompatible peut l'utiliser comme exemple.com/#/react/route . La configuration ne peut pas être sauvegardée par le rendu côté serveur car c'est / path qui est servi côté serveur, le hachage d'URL # / react / route ne peut pas être lu du côté serveur. Côté client, il window.location.hashest analysé par le routeur React. Le routeur React restitue un composant pour lequel il a été configuré pour rendre / react / route , de la même manière que BrowserRouter.

Plus important encore, HashRouterles cas d'utilisation ne sont pas limités à SPA. Un site Web peut avoir un routage côté serveur hérité ou convivial pour les moteurs de recherche, tandis que l'application React peut être un widget qui conserve son état dans une URL comme example.com/server/side/route#/react/route . Une page contenant l'application React est servie côté serveur pour / serveur / côté / route , puis côté client, le routeur React rend un composant pour lequel il a été configuré pour le rendu / react / route , comme dans le scénario précédent.

Fiole d'Estus
la source
2
Un autre point - si vous avez besoin de la navigation d'ancres sur la page (qui est location.hash a été généralement conçu et censé fonctionner hors de la boîte), c'est un peu plus difficile à implémenter.
WhiteKnight
1
@iRohitBhatia BrowserHistory vous permet également d'effectuer un rendu côté serveur car le serveur a accès à l'URL complète. Le serveur n'a pas accès au chemin derrière le #.
Sébastien Loix
28

SERVER SIDE: HashRouter utilise un symbole de hachage dans l'URL, ce qui a pour effet que tout le contenu du chemin d'URL suivant est ignoré dans la requête du serveur (c'est-à-dire que vous envoyez "www.mywebsite.com/#/person/john" le serveur obtient "www .mywebsite.com ". En conséquence, le serveur renverra la réponse pre # URL, puis le chemin post # sera géré par votre application de réaction côté client.

CÔTÉ CLIENT: BrowserRouter n'ajoutera pas le symbole # à votre URL, mais créera des problèmes lorsque vous essayez de créer un lien vers une page ou de recharger une page. Si la route explicite existe dans votre application de réaction client, mais pas sur votre serveur, le rechargement et la liaison (tout ce qui touche directement le serveur) renverra 404 erreurs non trouvées.

Sakhi Mansoor
la source
5

Les deux composants BrowserRouteret HashRouteront été introduits dans React Router ver.4 en tant que sous-classes de la Routerclasse. Simplement, BrowserRoutersynchronise l'interface utilisateur avec l'URL actuelle de votre navigateur, cela se fait au moyen de l'API d'histoire HTML-5. D'autre part, HashRouterutilise la partie Hash de votre URL pour la synchronisation.

Alex Trn
la source
5

"Cas d'utilisation"

HashRouter: Lorsque nous avons de petites applications côté client qui n'ont pas besoin de backend, nous pouvons les utiliser HashRoutercar lorsque nous utilisons des hachages dans le navigateur d'URL / barre d'emplacement, ne fait pas de demande de serveur.

BrowserRouter: lorsque nous avons de grandes applications prêtes pour la production qui servent le backend, il est recommandé d'utiliser <BrowserRouter>.

Référence par livre: Learning React: Functional Web Development with React et Redux Par Alex Banks, Eve Porcello

Abdul R.
la source
20
Imho "HashRouter" vs "BrowserRouter" n'a rien à voir avec les "petites" et les "grandes applications prêtes pour la production". Il n'y a ni limites ni problèmes de performances en utilisant HashRouter dans les grandes applications prêtes pour la production. Tout dépend du cas d'utilisation spécifique, des exigences et de l'architecture résultante. Les applications de production sans serveur sont une réalité.
Pawel Sas
4

L'actualisation de la page amène le navigateur à envoyer une requête GET au serveur en utilisant l'itinéraire actuel. Le # a été utilisé pour nous empêcher d'envoyer cette requête GET. Nous utilisons BrowserRouter parce que nous voulons que la requête GET soit envoyée au serveur. Afin de rendre le routeur sur le serveur, nous avons besoin d'un emplacement - nous avons besoin de l'itinéraire. Cette route sera utilisée sur le serveur pour indiquer au routeur ce qu'il doit rendre. Le BrowserRouter est utilisé lorsque vous souhaitez rendre les routes de manière isomorphe.

Kumar
la source
1

Un autre cas d'utilisation que je souhaite ajouter. Lorsque vous utilisez BrowserRouter ou Router, cela fonctionnera correctement sur notre serveur de nœuds. Parce qu'il comprend le routage client (préconfiguré).

Mais pendant que nous déployons notre application Build React sur le serveur Apache (disons simplement PHP, sur GoDaddy), le routage ne fonctionnera pas comme prévu. Il atterrira dans 404, pour cela nous devons configurer le fichier .htaccess . Après cela aussi pour moi chaque clic / url, sa demande d'envoi au serveur.

Dans ce cas, mieux nous utilisons le routage HASH (#). # nous l'utilisons sur notre page html, pour parcourir le contenu HTML et cela ne conduira pas à une requête du serveur.

Dans le scénario ci-dessus, nous pouvons utiliser HashRouting, c'est-à-dire toutes les URL présentes après #, nous pouvons faire fonctionner nos règles de routage en tant que SPA.

asishkhuntia
la source
0

Fondamentalement, si on utilise BrowserRouter, on peut utiliser une URL comme "soAndSoReactPage /: id"

par exemple:

with a Route <Route path="soAndSoReactPage/:id"><soAndSoReactComponent/></Route>

maintenant, dans le composant de réaction "soAndSoReactComponent", le "id" peut alors être extrait en utilisant useParams et ainsi vous pouvez afficher la page "soAndSoReactComponent" selon l'id

une telle chose ne peut pas être faite avec HashedRouter,

Raj Panchal
la source