You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
I spent a day or so yesterday trying to figure out what the best way to support the scenario where a user command-clicks a link, so it opens in a new tab from within an embedded app.
We were previously on v18.1.2 of this gem, and it seemed to be handled natively by the gem when the ShopifyApp::EnsureAuthenticatedLinks concern was included. Whilst in v21.8.0 of this gem, that concern adds support for deep links, it doesn't add support for opening pages in new tabs.
However, it does work if a shop and host param is present on the request URL. If I'm remembering correctly from yesterday, it looked like ShopifyAPI::Auth was responsible for part of this behaviour.
So my question is, is there a way native to this gem that allows us to support opening links in new tabs?
We're currently solving this by dynamically adding the params to <a>hrefs from stored .window attributes via JS. This seems a bit hacky, maybe there's some kind of header support that could do the same thing? or maybe there's just a setting somewhere I've overlooked.
Thanks for your help,
Oli
// Allows new tabs to work by adding a shop and host URL param. // i.e. the new page redirects to the shopify admin, then splash page, then the return_to location document.addEventListener('DOMContentLoaded',()=>{document.addEventListener('click',(event)=>{constelement=event.target.closest('a');if(!element)return;if(shouldInterceptLink(element)){constnewUrl=urlWithShopifyParams(element.getAttribute('href'));element.href=newUrl;}});});functionshouldInterceptLink(element){returnelement.href&&!element.href.startsWith('mailto:')&&isInternalLink(element);}functionurlWithShopifyParams(url){consturlObj=newURL(url,window.location.origin);if(window.shopOrigin&&!urlObj.searchParams.has('shop')){urlObj.searchParams.set('shop',window.shopOrigin);}if(window.shop_host&&!urlObj.searchParams.has('host')){urlObj.searchParams.set('host',window.shop_host);}returnurlObj.toString();}functionisInternalLink(element){consturl=newURL(element.href);returnurl.origin===window.location.origin;}
...bit of context
We're running a Rails 7.1 app with Turbo. Below are our controller setups.
What we ended up doing is creating a helper that wraps paths or URLs with the right attributes. Something like this:
<%= link_to 'Example', with_params_for_new_tab(example_path) %>. And we used only in select links that users might be more inclined to open in new tabs, like top navigation, etc.
Another more intrusive alternative that catches all links, is to override your path and URL helpers in your authenticated controllers, to include the params by default.
But yeah, it would be nice to have a default helper for this in the gem.
@flavio-b ok cool, so at least it's not just me missing something in the gem.
Mm, I think the link_to approach is less dirty for sure. We'll probably stick with the JS approach for now though.
The JS code above needed some tweaks for cases like anchor links and javascript:void.
Overview
I spent a day or so yesterday trying to figure out what the best way to support the scenario where a user command-clicks a link, so it opens in a new tab from within an embedded app.
We were previously on
v18.1.2
of this gem, and it seemed to be handled natively by the gem when theShopifyApp::EnsureAuthenticatedLinks
concern was included. Whilst inv21.8.0
of this gem, that concern adds support for deep links, it doesn't add support for opening pages in new tabs.However, it does work if a
shop
andhost
param is present on the request URL. If I'm remembering correctly from yesterday, it looked likeShopifyAPI::Auth
was responsible for part of this behaviour.So my question is, is there a way native to this gem that allows us to support opening links in new tabs?
We're currently solving this by dynamically adding the params to
<a>
href
s from stored.window
attributes via JS. This seems a bit hacky, maybe there's some kind of header support that could do the same thing? or maybe there's just a setting somewhere I've overlooked.Thanks for your help,
Oli
...bit of context
We're running a Rails 7.1 app with Turbo. Below are our controller setups.
The text was updated successfully, but these errors were encountered: