Using ParSys vs Layout Container Responsive Grid as resourceType

[webdev91]

Hello Everyone,

We have a simple 3-Columns Grid component where we are using "wcm/foundation/components/parsys", directly inside those columns for adding whatever component. Our concern is that, is it safe to use "parsys" as resourceType directly or should we use "wcm/foundation/components/responsivegrid" as resourceType always?

What are the disadvantage or what's going to impact in the future if using parsys directly here?

Note: We are using parsys directly here because, the component itself is creating the layout and if we use responsiveGrid as resourceType then it adds it's own wrapper div and set of CSS classes which is not needed in this case.

<div class="container">
    <div class="row" id="${properties.id}">
        <div class="col-xs-12 col-md-4">
            <sly data-sly-resource="${'path1' @ resourceType='wcm/foundation/components/parsys'}"/>
        </div>
        <div class="col-xs-12 col-md-4">
            <sly data-sly-resource="${'path2' @ resourceType='wcm/foundation/components/parsys'}"/>
        </div>
        <div class="col-xs-12 col-md-4">
            <sly data-sly-resource="${'path3' @ resourceType='wcm/foundation/components/parsys'}"/>
        </div>
    </div>
</div>

[Anish-Sinha]

Hi @webdev91 ,
Definitely you can use the parsys and your own component to define the layout as shown in the code instead of using the layout container which is "wcm/foundation/components/responsivegrid". It is not a mandate to use Layout container,  however, it provides a flexibility to authors to define the layout they want based on different breakpoints. It's up to you to use it or not.

responsive grid provides more flexibility and provides more capabilities to authors to manage the layout and using parsys you are restricting the styles in the custom code which is not in control of authors. This is the only disadvantage.

[webdev91]

Hi @Anish-Sinha 

Yes, I agree that a Layout Container definitely provides more features to the author in managing the layout, adding policies, etc. But here, we define the layout and manage it through the code. The sole purpose of ParSys here is to allow the author to add the component, so thought no need to use the Layout Container. Additionally, Layout Container comes with extra wrapper div with aem-grid CSS classes, which are not needed here.

With Layout Container:

<div class="col-md-4">
    <div class="aem-Grid aem-Grid--12 aem-Grid--default--12">
        <div class="teaser aem-GridColumn aem-GridColumn--default--12">
            <!-- Component code -->
        </div>
    </div>
</div>

With ParSys:

<div class="col-md-4">
    <div class="teaser">
        <!-- Component code -->
    </div>
</div>

This was the concern, and that's why we have used ParSys directly. But we wanted to make sure that we are not doing anything crazy here that may break something in the future. 

Thanks for the response. I would love to hear if you or someone else have other approach after reading this.

[Anish-Sinha]

I don’t think parsys is going to get added to deprecated component list neither the functionality. So I suppose if this fulfills your requirement, you can proceed with this implementation.