Issues Including Sightly Components in Handlebars

[MRyno]

We are using AEM 6.2 and are having issues with the Social Communities components. I have overlaid the qnaforum.hbs and need to include some Sightly components. The official documentation (link) says the correct way to do this is:

{{include this.id path="title" resourceType="myproject/components/content/common/title"}}

When done this way there are three problems:

1. The component appears, but then disappears from the page.
2. I get the warning "Forcing resource type is not supported when sling including on the client side"
3. There is a failed(404) GET request to http://localhost:4502/content/myproject/qna-index-page/jcr:content/qna-parsys/qna/title.html in the browser console (like it's trying to find the renderer for the title resource at that path).

In the same qnaforum.hbs file, Adobe is using the same include for their subscriptions component and it seems to work fine.

{{include this.id path="subscriptions" resourceType="/libs/social/subscriptions/components/hbs/subscriptions"}}

Does this type of include only work for Social or Handlebars components? If so, how can I include a custom resource in the handlebars template?

[JK_Kendall]

Hi MRyno,

The following is true for any non-HBS component :

When the HBS template is rendered on the client side, the sightly component will no longer be loaded if

• it’s a “non existing” resource (NER)
• if a resource type is being forced on it

Non-HBS components that are NERs, or forced to a resource type different from their actual resource type, may be included only when doing server-side rendering.  Support for client-side rendering of this type of component was removed due to security concerns.                  

To allow client-side rendering, what should work is to actually create a “title” node (such as "subscriptions") with the needed resource type as a sightly component resource, and include that sightly component in the HBS template. 

Let us know if this addresses the issue for you.

-JK

[MRyno]

Here is an example of one of the components we have. We have a few different ones we are including, but this is the first one in our overlaid social component:

qna-index (jcr:primaryType = cq:Page)
    jcr:content (cq:template = /apps/foo/templates/qnaindex-template)
        global-header (our header)
        qna-parsys (parsys container for our custom overlaid qnaforum)
            qna (the custom overlaid social component based on qnaforum)
                qnaforum-top (this is included at the top of the overlaid qnaforum in the qnaforum.hbs that has been overlaid. This component is Sightly)
        global-footer (our footer)

So, the qnaforum-top has some things that are able to be changed in the authoring environment (such as title and a description) but also includes a filtering mechanism based on tags selected in the dialog (making it more complex to just convert to handlebars). Inside the qnaforum.hbs (the "qna" node in the above content structure) we have the following code at the very top:

{{include this.id path="qnaforum-top" resourceType="foo/components/modules/qnaforum-top"}}

Given this scenario, how would you include Sightly components in an overlaid handlebars social component like what we have above? It seems like the Sightly components are routeable and shouldn't be NER's. It looks like we are providing the resourceType which may violate the second condition. If we remove the resourceType from that include, it renders the "qnaforum-top" twice (so we see two titles, two descriptions and two of our tag-based filtering mechanisms). The qnaforum-top component acts like a wrapper (and has a corresponding bottom that I am leaving out of this example), so when it renders twice, it looks like you have the qnaforum and it's qnaforum-top inside an outer qnaforum-top. It is very strange. It seems like including the resourceType makes the overlaid qnaforum render for a half second and then disappear (giving the "Forcing resource type" error) and removing the resourceType causes it to render twice. Right now, the qnaforum-top node in the above structure was probably originally created because it was included with a resourceType in the qnaforum.hbs because we aren't sure how we can create that natively since it is inside a social component (how would that be created when an author creates a new qna-index page?). Hopefully this makes more sense even though it is super specific to our situation. I think ultimately we are hung up on how to include Sightly components inside overlaid social components like qnaforum.hbs or topic.hbs. One thing would be to rewrite those components in Handlebars, but that raises other questions like how to get access to the page properties and also makes us maintain Sightly and Handlebars versions of the same components. We're hoping there is another way outside of converting to Handlebars, but are open to exploring that. Thank you very much for any help or information you can offer. If there are any examples of similar (simpler) things, feel free to point me in that direction. Thanks again!

Ryan

[aponnusa]

Hi Ryan,

Does qnaforum-top use any data from the QnA components ? if not, why can it not be included above the QnA Component under qna-parsys

 qna-parsys (parsys container for our custom overlaid qnaforum)

            qnaforum-top (this is included at the top of the overlaid qnaforum in the qnaforum.hbs that has been overlaid. This component is Sightly)
            qna (the custom overlaid social component based on qnaforum)

Also if the resource exists, you can just do - {{include this.id path="qnaforum-top"}}

Let us know if these help.

[MRyno]

So, qnaforum-top doesn't use anything from the QnA components. The reason we included it the way we did is we wanted the contents of qnaforum-top to not be included when a topic was being displayed. Anything in the QnA is replaced by the Topic contents if you click on a topic from the list. We could show/hide that with JavaScript, but this is really only one example of something that we have occurring a few times within QnA.

To the other point of using {{include this.id path="qnaforum-top"}}, we actually did try that syntax but when we do, qnaforum-top is actually rendered twice when going to the qna forum index page. We cannot see any reason why that would happen.

If we needed to include something on a topic, how would content exist for a newly created topic (since it is UGC that is created on the fly)?

Ultimately we have a library of Sightly components that we maintain and would like to use inside some of the social components (like title, hero images, social share tray, etc) but we are hitting a brick wall when we try to include those things in any of the handlebars stuff. It is looking more and more like we need to copy all of those components into handlebars so that we can use them in the social components, but that would be a huge pain, so we are trying to avoid that if we can.

[aponnusa]

The issue is strange, and we have included sightly components inside of Handlebars in the past. We have had customers who were doing something like what you did. Also looks like you already tried all permutations of the include helper. So can you send your component as a zip, and I can try to see whats happening.

It will be of great help if you can package us the page, the clientlibs used the by the page, and all the components in the page.

Thanks

[MRyno]

Sent you a PM. Thank you for checking that out for us!

[aponnusa · Accepted solution]

Hi, I sent a code suggestion in PM/email to overcome the dissappearing QnA issue.

For the benefit of others who might hit the same issue again - The overlaid QnAForum component looked like this

{{include this.id path="qnaforum-top" resourceType="custom/components/modules/qnaforum-top"}} {{#if-wcm-mode mode="EDIT" }} <div class="scf-includeClientLib">{{includeClientLib js="cq.social.commons.widgets, cq.social.toggle"}}</div> {{/if-wcm-mode}} <div data-module="qna-index" class="scf scf-forum scf-qna " data-component-id="{{id}}" data-scf-component="social/qna/components/hbs/qnaforum"> {{!-- Other QnA code --}} </div>

But code should be like this

{{#if-wcm-mode mode="EDIT" }} <div class="scf-includeClientLib">{{includeClientLib js="cq.social.commons.widgets, cq.social.toggle"}}</div> {{/if-wcm-mode}} <div data-module="qna-index" class="scf scf-forum scf-qna " data-component-id="{{id}}" data-scf-component="social/qna/components/hbs/qnaforum"> {{!-- moving line1 from previous code snippet inside this parent div}} {{include this.id path="qnaforum-top" resourceType="custom/components/modules/qnaforum-top"}} {{!-- rest of QnA Code }} </div>

[JK_Kendall]

In other words, the include of the HTL component should appear within the div tag with the data-scf-component attribute instead of before it.

- JK

[MRyno]

So, something like that could work for us. However, what happens is that the qnaforum-top will render inside the scf component. As an example, our qnaforum-top contains a column with filters that will change what is displayed in the qnaforum social component. If we were to move the qnaforum-top inside of the social component, it would end up being rendered on the topic pages as well. If we did move qnaforum-top to be within the qna scf component, we would need a way to hide things within the qna scf component based on the context (e.g. currently viewing a topic, so don't show the filters). It seems there are two potential ways to accomplish what we want to do. Option 1 is what we have been trying by wrapping the scf component with qnaforum-top (which contains our filters), which isn't working. Option 2 is to integrate qnaforum-top into the qna scf component, but come up with a way to hide components within the qna scf component based on the context of what is currently visible to the user (e.g. viewing a topic, so hide the filter list). Either would work for us, but Option 2 presents some additional challenges that are hard to address because the qna scf component works via ajax to replace the contents (as opposed to changing URLs), so we don't have an obvious way of getting context. We could run some JS to do some show/hide manipulation, but then we have the filter list loading and disappearing (on a topic page) or popping up out of nowhere after the page load (on the index list page).