Ion-item inside an ion-item?

I have a bunch of custom-render doodad components in my app. Like, “here’s how you render a community preview - member count, name, and so on”, so I can do <community-preview [community]="item"> or what have you.

The problem is that the preview uses an ion-item element for layout - makes it easy to have icons, text, and everything else render nicely, and I don’t have to deal with my own parallel flexbox stuff. Except sometimes community-preview is rendered itself inside an ion-item. I haven’t had any rendering problems to date, except now that I’m trying to fiddle with reorderable lists.

In particular, if I have that rough structure- an ion-list where each direct ion-item child has somewhere in its child hierarchy an ion-item, setting reorderable on the list ends up putting two grab handles on each item - one on the outside item, and one on the nested item. Worse: the nested handle doesn’t actually work (getReorderNode doesn’t look far enough up the dom tree to find its reordering parent node).

So, a two-phase question: one, is it possible to set an attribute on an ion-item to override the containing list’s claim of reorderability? and two, are there likely other issues associated with nesting ion-items inside each other for layout purposes, and if so: what’s the general strategy? I’ll note that I landed on ion-item mainly because there doesn’t seem to be a basic ion-panel that attaches default text / icon / flexbox styling the way items do, so I sometimes end up using ion-item outside of its intended semantic meaning.

for the time being, I can do a really, really hacky workaround here -

import { Directive, ViewContainerRef } from '@angular/core';

@Directive({
  selector: '[noreorder]',
})
export class NoReorder {
  constructor(vc: ViewContainerRef) {
    try {
      vc['_data'].componentView.component._hasReorder = false;
    } catch (e) {
      console.log(e);
    }
  }
}

then I can do <ion-item noreorder> elsewhere, and it’ll do just that - pretend the item isn’t reorderable. considering that i’m relying on the unpublished internals of not one, but two different libraries (getting the component from angular and setting an interior flag on the item), this isn’t really a great solution.

Throwing an @Input into the item to allow overriding reorderability would be pretty rad, though.