Approach to dealing with nested smart/ dumb components

[NathanWalker]

From @goelinsights on April 23, 2018 19:53

Trying to figure out the pattern for injecting nested smart and dumb components. Is the solution to re-create them but extract the repeating function logic in the components into services?

Example (gallery with a list of photos. Smart/dumb component pattern for gallery but not for photo using material design): app-gallery-page.component.html

<div [data]="gallery$ | async">
  <app-gallery [data]="gallery">
   <mat-grid-list>
      <app-gallery-photo *ngFor="photo of gallery.photos">
        <mat-grid-tile> 
            ...
        </mat-grid-tile>
      </app-gallery-photo>
   </mat-grid-list>
  </app-gallery>
</div>

In the current angular smart/ dumb approach you use the html template for AppGalleryPage to drive the remainder of what's displayed downstream. Is there any way to reuse all of this (i.e., swapping out HTML templates using a conditional in templateUrl that would compile, etc, that would be smaller than stuffing all of the HTML for different versions with a flag?)

In this case, say material design only works in a SSR (web) and Admin (web) version of the app, but you'd want to reuse the logic in the smart component as a starting point for the AMP version but need a different HTML setup, is there a way to do this that would be better than shipping a bunch of conditional IF blocks, i.e.,?

app-gallery-page.component.html

<div [data]="gallery$ | async">
  <app-gallery [data]="gallery">
   <mat-grid-list *ngIf="!!web">
      <app-gallery-photo *ngFor="photo of gallery.photos" [admin]="adminStatus"[version]="web">
        <mat-grid-tile> 
            ...stuff
        </mat-grid-tile>
       <app-gallery-photo-admin *ngIf="!!adminStatus">
       <app-gallery-photo-admin
      </app-gallery-photo>
   </mat-grid-list>
    <amp-alternative-to-grid *ngIf="!web && !!amp">
        <app-gallery-photo *ngFor="photo of gallery.photos" [admin]="false" [version]="amp">
             ...stuff
        </app-gallery-photo>
    </amp-alternative-to-grid>

  </app-gallery>
</app-gallery-page>

Similar question on if that means that we'd need to ship all the code related to the Admin version so things don't break, despite creating a much lighter non-admin app if we can avoid loading that code.

Copied from original issue: nstudio/xplat-issues#3

[NathanWalker]

Precisely the reason for xplat/[platform] here. Once ssr support is available you would put your amp specific template handling in there.

• Drop all your shared component code down to libs/features/gallery/abstract/gallery.base-component.ts defined as export abstract class GalleryBaseComponent {...
• Have xplat/web/features/gallery/components/gallery.component.ts extend GalleryBaseComponent.
• Have xplat/ssr/features/gallery/components/gallery.component.ts extend GalleryBaseComponent which would contain the amp specific template handling.

GalleryBaseComponent would contain your binding references for gallery$, etc. Git rid of all the silly *ngIf stuff.

[NathanWalker]

From @goelinsights on April 23, 2018 23:20

@NathanWalker that sounds awesome! Can't wait.

Followup. I'll have two versions of SSR (AMP and normal web SSR'd for SEO purposes) + web for the admin version of the site.

Is the syntax adaptable to something like xplat/ssr-web & xplat/ssr-amp? Or could we create a xplat/amp that pulls from SSR default configs? Or would we do something like create the base generics in the SSR folder and then apply the specific html templates in the apps folder?

[NathanWalker]

As far as admin portion of your template code, there's a couple ways to handle that (outside of anything related to xplat really - just angular decisions primarily) you could build an AdminModule which gets loaded when an admin user is authenticated. It would itself come with app-gallery-photo-admin which is only activated and available when the AdminModule is loaded. Your standard SharedModule would use CUSTOM_ELEMENTS_SCHEMA as part of the schemas to potentially allow usage of unknown (and unactivated) app-gallery-photo-admin which would simply render nothing when no admin is present. However once the AdminModule was loaded could activate them. But there's other ways to go about it - really just however you and your team want to handle that.

[NathanWalker]

Oh nice really appreciate your feedback btw, yes we can definitely plan on supporting xplat/ssr-web + xplat/ssr-amp that's an interesting idea. I'll think through that a bit and whether that's really necessary before releasing the ssr support.