Looks good! I do wonder if we should open the block previews in a new tab/window instead of in the modal? Looks like css isn't applied in the modal?

Thank you for the review!

I originally had them opening in a new tab using anchor links, but @auniverseaway mentioned a using full screen modal. I think it makes sense as it keeps the user in the da editor.

The blocks being pulled don't seem to have any css with them, and they look that way in a new window as well. If you try one of the templates, which point to bacom templates and they appear to load with css as expected.

The blocks being pulled don't seem to have any css with them, and they look that way in a new window as well. If you try one of the templates, which point to bacom templates and they appear to load with css as expected.

This is what I was getting at with my other comment. You have three formats of how people will enter their lists of blocks...

1. Most common - https://content.da.live/...
2. 2nd most common - https://main--{NAME_OF_SITE}...
3. Least common, but possible: https://admin.da.live/source/.../page.html (note the .html addition)

For 1 & 2, you will need to detect and convert to the 2nd so you get a proper rendering of the page. Something like...

if (url.origin.includes('--') return url.href;
if (url.origin.includes('content.da.live') {
  const [, org, site, ...split] = url.pathname.split('/');
  return `https://main--${site}--${org}.aem.page/${split.join('/')}`;
}
if (url.origin.includes('admin.da.live') {
  return `Similar thing to content, but different`;
}

The blocks being pulled don't seem to have any css with them, and they look that way in a new window as well. If you try one of the templates, which point to bacom templates and they appear to load with css as expected.

This is what I was getting at with my other comment. You have three formats of how people will enter their lists of blocks...

1. Most common - https://content.da.live/...
2. 2nd most common - https://main--{NAME_OF_SITE}...
3. Least common, but possible: https://admin.da.live/source/.../page.html (note the .html addition)

For 1 & 2, you will need to detect and convert to the 2nd so you get a proper rendering of the page. Something like...

if (url.origin.includes('--') return url.href;
if (url.origin.includes('content.da.live') {
  const [, org, site, ...split] = url.pathname.split('/');
  return `https://main--${site}--${org}.aem.page/${split.join('/')}`;
}
if (url.origin.includes('admin.da.live') {
  return `Similar thing to content, but different`;
}

Aah. thank you, that clarifies it a lot. Thank you both. I will get those changes made and push them up. Appreciate the review.

Hello @chrischrischris and @auniverseaway,

I was enacting the changes to modify the preview url to one that will load the user's repository code for a better preview when I realized there may be a permissions issue that crops up if we normalize the url to use aem.page:

This is what occurs for da-bacom when the url used is aem.page vs. aem.live in the config. Before I go down the path a little more, I wanted to get your advice: Do we check for a valid response from aem.page first before using it, or should we rely on users to know to use non-restricted paths?

We could easily fetch the HEAD to see if a Type Error is thrown, and then try using aem.live and if that fails, have a fallback message appear in the preview or even fall back to the content.da.live page. What do you think?

Thank you,
Jason

@JasonHowellSlavin I think we respect what people put in. If someone puts in aem.page, we use it (even if it 401s). If they put in aem.live, we use it. If someone puts in *.da.live we use aem.live.

Also: I have Github notifications turned off, so I didn't see this. Feel free to Slack me if you don't hear from us in a day or two.

Thank you Chris for the feedback. I made the changes you suggested. I did have one question regarding the last bullet:

• There should be support for Esc key closing of preview

It appears that the library modal code closes on esc, but it uses the same functionality that I avoided with the preview initially. That is, it removes the entire modal, library included. See the attached video where I use the button to close out of the preview vs using escape.

Let me know what you think, and thank you again.

Re Closing with Esc, I personally rather have the key do something vs requiring a mouse.... but I'll defer to @auniverseaway