Per this React Router announcement, React Router and Reach Router are now the same project (more or less). The Reach Router docs says
Router manages the focus of your app on route transitions. There’s nothing you have to do about it, it just happens.
At present there's nothing in the React Router Web API docs about focus (I did a text search) and the roadmap has
Add focus management APIs
in the backlog.
Is this feature still coming or are we waiting for this React RFC or is it there and not documented? Asking because it's been a while since the announcement and it's understandable if there are documentation gaps. Want to make sure it's really not there before I keep rolling my own.
Related
Issue: appears to be that banno framework is "remembering" the urls. This is happening in a mobile browser when the user does not close the tab or browser. When the user opens the page, banno is remembering the url from last time and trying to load the same url.
What needs to happen is that banno needs to fully reload the page so that we can go retrieve a new url and log the user in again.
Could it be how they treat plugins when a browser is left open. A url that is loaded is not good forever.
Odds are good that the situation you're encountering is described in https://stackoverflow.com/a/71267143/6680761
Essential info from that link is:
Part of keeping state of the page is keeping authentication data. The OAuth flow used to initially authenticate the user is not intended to be used on every page refresh. It's expected that the embedded web application will keep its own authentication state. How this is done is usually very specific to the language and platform used for the embedded web application. However all strategies almost exclusively use a cookie which is destroyed when the application closes.
The Oauth callback URL with an authentication code should be redirected away from once the code is exchanged for an access token. From that point forward your app should be using its own authentication mechanism.
From my research, the browser gives us some features that the JavaScript engine itself doesn’t provide: a Web API. This includes the DOM API, setTimeout, HTTP requests, and so on.
So because browsers run functions that are not supported in the JavaScript engine, like setTimeout for example, is it correct to say that the browser's terminal is an interface to the web and Web API.
Does that make sense, is that a constructive way to think about it?
I think that the WebAPI and the Console are two separate Things that both plug into the js-engine of your browser. The Console is not able to directly access the DOM for example, it can only execute javascript lines, that access the DOM internal and return a specific result (again returned via javascript)
Are there any benefits or drawbacks if you serving light version of page optimized for SEO if bots crawls and if people come from web then react SPA which completely javascript application.
Basically question is, is there practice to actually serve like short HTML version which contains only SEO important things and rips off everything else for bots and full page for users.
Is there any use case or example that somebody have used this technique?
This would be seen as Cloaking by the crawlers and could get your site penalized in the search results. If you are serving a prerendered page, you will want to make sure it is the exact page that your users will see after the javascript has been executed in order to prevent any cloaking issues.
You'll could mount prerender:
The Prerender.io middleware that you install on your server will check each request to see if it's a request from a crawler. If it is a request from a crawler, the middleware will send a request to Prerender.io for the static HTML of that page. If not, the request will continue on to your normal server routes. The crawler never knows that you are using Prerender.io since the response always goes through your server.
The Prerender.io middleware that you install on your server will check each request to see if it's a request from a crawler. If it is a request from a crawler, the middleware will send a request to Prerender.io for the static HTML of that page. If not, the request will continue on to your normal server routes. The crawler never knows that you are using Prerender.io since the response always goes through your server.
Quora SEO post
taekwondomonfils.com SEO
while going through the history Api of html5, i got confused. What's the exact difference between router and history api. I mean if we consider the case of react-router, we can use history api also to change the url and load the content. Any help will be appreciated.
I am building a packaged chrome app (It is needed as I want to access chrome.socket). I have a website from which I would like to call my app (if installed or ask the user to install it) by clicking a link. Is this possible ? Not able to find any easy way for this workflow.
The url_handlers might be the best way to achieve this.
You can also use the externally_connectable manifest property to declare that your website can connect to your app, then call chrome.runtime.sendMessage or chrome.runtime.connect from your webpage and handle it in an chrome.runtime.onMessage handler in the app.
Which one is better suited depends on your needs. The url_handlers is an easier way, but it will permanently assign the URL on your link to your app, so you won't be able to use it for anything else if the app is installed. The externally_connectable is a harder way, but it enables a much more elaborate bidirectional communication between your website and the app.
You can even use a combination of the two approaches, if you need: launch the app using the url_handlers feature, then establish a communication channel back to the website once the app is up and running.
Apps can now (as of Chrome 31 I believe) register to handle urls by adding url_handlers in their manifest and detecting the url causing the app to launch in the chrome.app.runtime.onLaunched event. If the app doesn't launch, your hosted web site will be loaded an can present an inline installation with chrome.webstore.install.