FrontEnd Routing

Configuration is the main thing. All frameworks have this one main configuration. The configuration maps the routes to components. The routes can have parameters. They are passed as parameters. The parameters can sometimes have couplings with router. But there must be some way to pass params as props without the componenent not being aware of the router. Then there is an outlet. That we put up top somewhere in the component hierarchy. That displays the correct component based on the url. We have special router related api that we use to change path. We can pass router link elements. We can call router changes from event handlers too. Changing routes change the URL. That is if we use history api of the browser. It changes the url and adds to history without refreshing the page. Next is the complicated part about nested routes. That turns out to be quite simple too. You have nexted configuration, as objects inside the objects. And the components having nested thing have another router outlet. So top level route has a component mapped to it and the nested config object also has components mapped to many sub routes. When routes change, elements are removed and new ones are put in. For those we can add transitions. History based this has an issue when requesting static stuff from server. The server has no files. Using hash urls instead of history api avoids this problem. But history API is good practice. So the server should return the default index file for all routes and since the browser has the exact url the required component will render