I couldn't understand the theoretical part of choosing routes. There are many examples out there which implements routes like /authentication /user:id but how can we decide which routes we need in our application. I am not able to distinguish do I have to use route for something or not.
"how can we decide which routes we need in our application"
Routes are entry points into your application. Anything the user types in manually in the address bar, copy-pastes from somewhere, clicks on a link in an email, etc. can be an entry point.
So whenever you have an entry point (page loading for the first time) that is NOT simply the default route or default page loading behavior, you need a new route.
For single page apps, this usually boils down to looking at the URL with JS code at runtime and deciding which view/component to render. Most projects rely on libraries like react-router to formalize and automate this functionality.
Related
Asking this here because of an issue that was closed because the maintainer believes this is already a supported use-case of react-router.
My app has four sections that can be switched between by using a sidebar on the left. All sections are rendered at all times, and only one is displayed at a time using a custom screen switcher component. This is also so that state is not lost for sections you have visited.
However, I'm having issues using a singular router for this. When I switch to a different section, the one I was just at loses all its state because it sees I'm at a completely different URL now, so it forgets all the data it's loaded and has to re-load the next time I visit it. (I'm not using a Switch for rendering the sections, since that unmounts them if the route doesn't match. The Switches inside the section do de-activate, though.)
Ideally, when I switch away from a section, that section should remember its path and I just activate another section's router. When switching back, I can re-activate the router and the full path appears in the browser address bar, just as the user left it.
There's a high probability that this use case is not supported by react-router. But in case there is, how would I go about it? Do I really need multiple routers or is there something else I can use?
The maintainer got back to me and clarified that this is definitely already possible. I would use a plain <Router> component and pass a custom history that would only update/listen to browser history changes conditionally.
Edit: I've since successfully implemented this, and it works really well. I can't share any code unfortunately.
I am new to react and I haven't cleared all things in my mind yet.
I am currently working on a project where I need to build a react app with a landing page, a sign up/in page, an ask-a-question page and a answer-question page. Something like a stack overflow clone.
To my knowledge so far I get that I have two choices. 1) use react-router and have a function rendering what I want for each page or 2) have a state like showPage and with some if/else if render the page I want.
What is the correct way to do what I want? And in general when should I use react-router and when just state.
Thanks in advance
You'll always use routing if you have multiple pages to render. As you said you have 3 pages currently you'll need to work on.
Landing page
Sing in/ register
FAQ
What you'll want to do is wrap everything inside your app.js in Router and have say a pages folder that'll have all the pages you want to render.
In React, routers help create and navigate between the different URLs
that make up your web application. They allow your user to move
between the components of your app while preserving user state, and
can provide unique URLs for these components to make them more
shareable. With routers, you can improve your app’s user experience by
simplifying site navigation.
Read more here
You need to separate all this because when your project grows you'll thank yourself for creating specific file for specific workload. It'll be easier to manage. And when you're working on large scale projects you'd want to create layouts and have even bigger distributions.
layouts
|__admin_layout.js
|__user_layout.js
here admin layout will handle all routes specific to admin and user layout will handle all routes specific to users.
Routing helps you manage your pages much better
I'm new to React.
In React, we use navigation with a library like... 'react-router-dom' to navigate to pages. My question is most of the time, I can show and hide the entire Component based on the item selected in a navigation bar. I can store a value in the state and if the selection changes, I can show another component. Then why should we use a navigation library to navigate around?
I can not find any clear information about this online. Please help.
I was writing in this answer about having a more organized code (easier to maintenance) and a better folder structure, but you could easily have it working without a navigation library.
Probably the main point to use a navigation library is, as said in React Router page, whether you want to have bookmarkable URLs for your web app or a composable way to navigate in React Native.
Web
The library will help you work with the URL, receive parameters, navigate between pages.
Mobile
You can make use of deep linking, receive parameters, navigate between screens, animations, components ready for Stack navigation, Drawer navigation, Bottom Tab navigation...
You can do anything I mentioned above by yourself, but libraries exist because other people had a need and you decide to use it if you have the same need and think it's worth it.
Why should we use a navigation library to navigate around?
In short, because they are widely used, well-tested libraries, with a performance that you may not be able to achieve easily if you want to have many different functionalities like those libraries have. And they will certainly save you a lot of time in case you need to create a way to navigate and work with things related to navigation (like those mentioned about Web and Mobile).
If your project is simple, there is no need to use a navigation library. To have a more practical experience, you can even try to do your project without using such a library, and when you are having difficulties, try replacing your logic with some library and analyze if it was worth it.
I was building a dashboard view in my react-admin app, using a custom route and a List. (I found the necessary doc in the Custom App doc)
But ra's List component is bound to current route, location etc.
As I will show multiple lists I guess I may use ListController instead, with a custom view.
This approach lead me to an idea... Why not use react-admin to build both my app's admin and front-end ? I would be able to use the same dataProvider, authProvider, custom actions etc.
Do you, react-admin lovers, think it'd be good idea to try using ra components (List, Edit, ListController...) and leverage the power of ra to build a fully ui-customized production app ?
Is there a proof-of-concept out there ?
I wonder if I should give this a try (I really wan't to) and I'd love it if I could get feedback from developers who endeavored to do just that already.
I think it's a good idea, and it should be relatively straightforward. React-admin controllers (ListController, EditController, CreateController) don't depend on the route explicitely. It's only because they are used as children of Route props that they receive route parameters (rescource, id) in their props. ListController and CreateController do need a location prop to work, because that's where part of their state comes from (the filters in the list, the default values in the create form). But if you pass your own location, it may work.
We could imagine refactoring these controllers to be completely route (and location) independent, but I'm afraid of the added complexity for handling filters in the URL.
I understood that routing libraries for SPAs like https://github.com/ReactTraining/react-router help to parse the URL and put the app into a corresponding state of a state machine.
Is there more to routing than this?
Why is routing needed in the first place?
Why are URLs important? For example in a desktop app there are no URLs, so what's the big deal about them in a web app?
I also have this problem: "Why do we need routing?". You can write apps without routing at all. The code can get messy but still, it is not impossible.
My biggest reason for having routing is because if the user hits the Back button of the browser (Forward button as well, for that matter), he will not be navigating within the app. The user might expect to navigate within the app using the history of the different "pages" he loaded previously. Instead, he will be thrown out of the web app. Hitting the Refresh button would also throw him to the root of the app.
From the user's point of view, it is a regular web app (he doesn't need to know how it is designed: SPA or otherwise) and it should work as any web app/website should work. Routing ensures this, doesn't it?
This is a very good question, and one that I don't see discussed as often as I think it should be. The short answer is that often, in a Single Page Web Application, you don't need routing. If you are building an application which doesn't require its pages to be indexed by Google, and you either don't care, or don't want the user to be able to Bookmark pages, then there is no reason to implement routing.
In an SPA, routing adds additional complexity and effort, so if you can avoid doing it, you should. Of course, modern frameworks such as Angular and React provide facilities for making routing much easier, but even then some things can be hard to do with routing, for example animating between pages.
A good example of a web application where routing would be redundant would be a multi-page form which you want to control the user's passage through and possibly prevent them from returning to pages which have became inapplicable.
Implementing such a form with routes would be a nightmare as you would have to prevent the user from visiting certain pages in their history.
It's useful to ask yourself what a route actually is in a SPA. It's easy to think of it as just a 'web-page', but what it really is is a state, and when you navigate between routes what you are really doing is navigating between different states of the app. The fact that the appearance of the app may change between states is incidental to what is really going on. So what a route does is give the user a means of returning to particular states of the app.
You should only implement a route in an SPA when there is a state of the app which you want the user to be able to return to.
An alternative, and perhaps more useful way of doing this, would be to implement Undo and Redo mechanisms.
Of course, even when you don't have routes you still have to care about what happens when the user clicks the History Back button, but then you simply have a modal alert which warns them that they are about to leave the app should they proceed with the navigation.
In desktop applications you have buttons and other controls to get what you want. So routing in UI apps would be the set of all UI controls.
In web apps on the other hand, all functionality is accessed via some text which is the links and the parameters.
A URL is the path to access a functionality. Routing is like the mechanism to decide which functionality to call based on the provided URL and params.
So basically routing is a mapping between an URL and the functionality of a web server.
Routing in SPAs is used to load certain parts of the web app e.g. yourappurl.com/profile/userid/ will load the profile part of an SPA with the right user profile corresponding to the userid. This can be seen in the GitHub example you provided:
<Router history={browserHistory}>
<Route path="/" component={App}>
<Route path="about" component={About}/>
<Route path="users" component={Users}>
<Route path="/user/:userId" component={User}/>
</Route>
<Route path="*" component={NoMatch}/>
</Route>
SPA refers to the fact that in general you have an index.html as your "main view" and then depending on the routing you add/remove certain parts from the index.html with frameworks like React or AngularJS etc.
I have the same question from time to time.
I would like to say router in SPA is a component hierarchy helper.
As #tech4242 pointed out, we don't have an something like segue in iOS. So what should we use to help users navigate if we don't use router? We are talking about SPA here. So we can manage this in store or state. Yes, that's feasible but not preferable.
Try to think this from the perspective of using a component-oriented library (either React or Vue). Using router help us use a certain component for a specific route. When users move back and forth between different route, we are relying on the route to tell what component to display. We simply couple a component with a specific route, which makes our root component (normally called App) clear, maintainable and readable. Without router, either the root component or state would be messy and hard to maintain.