Since the _blank
opens a new tab so it is another instance of your app even the app is the same app the internals are different. But you can use something like localStorage
.
Since they will be persisted and will be shared for same origin you will have access to it in the new or any tab or window of your application. You need to query it in the component mount or after first render with and useEffect
hook with a second parameter being probably empty array, []
. For hooks checkout React docs if you use them.
Another way is to use the querystring
. You can receive the query string from your opened comopenent instance.
I am sure you can use any other persistense mechanism, like Indexed DB, Cookies, etc.
There are a few other ways coming into my mind under the umbrella web messaging; Broadcast Channel API, Window.postMessage, and Channel Messaging API that you may make use of.
If you state is relatively small it mifght be good to use querystring, or localStorage is the easiest way to go. If your data way more bigger you can use Indexed DB. It is async. Only be careful when it completes write, then you get it in your new window, tab.
In persistence usage cases, write to persistence before you navigate, just wait the write process if it is async before you navigate (by opening new tab/window in your specific use case).
One might navigate to a new tab maybe by right clicking and selecting from the context menu. ın that case Page Visibility API can be used on the right clicked page in a React effect (attaching its effects in an React effect with an empty second argument to React effect) and the data can be written again to a persistence mechanism, one of above mentioned ones, and the rest I mean the operations in the opening tab will be the same.
Since the writing mechanism can be late and even it is a sync one opening of a new tab if it is not programmatical might happen before the writing is done. In that case the opening tab's React effect to read the data written might be early to read. To circumvent these workarounds like waiting via a setTimeout
to read can be used simply, however, a programmatically correct and a guaranteedly timed way would be using one of the appropriate web messaging apis I have mentioned above like Broadcast Channel, postMessage, and Channel Messaging API.