[Feature]: fChildren directive to constrain children to designated area

[chladog]

Describe the Feature

Great project so far!
I would like to propose a new directive named fChildren which can be set to any Node's or Group's descenant block element.
Currently the only offset possible is the includePadding directive, which is fine if you need simple title in the corner, but if you need to add some (interactive) content that needs to be visible, inputs, outputs etc. that is not enough:

With this feature you would be able to achive something like this - notice that the title is inside the Node but outside of the area containing children

The "Drag to group" title always visible, but basically the content could be placed anywhere

Sample of fChildren usage:

<div fNode fDragHandle [fNodeId]="node.id" [fNodeParentId]="node.parentId" [fIncludePadding]="includePaddings()"  [fAutoSizeToFitChildren]="autoSizeToFitChildren()" fAutoExpandOnChildHit]="autoExpandOnChildHit()"
      [fNodePosition]="node.position" [ngClass]="getNodeClasses(node)">

      <h4>Title that needs to be visible</h4>

      <div class="content-area" style="display: flex;">
        <div fChildren class="children-area">
          <!-- This is the designated children area -->
        </div>
        <ul>
          <!-- Outputs on the side -->
          <li>Output 1</li>
          <li>Output 2</li>
          <li>Output 3</li>
        </ul>
      </div>
      <small>
        Node footer that needs to be visible and maybe some outputs
      </small>
    </div>

Since there is flat structure in f-flow, the calculation would be a difference between parent's node outer sides and fChildren element sides coordinates. As there could be layout shift inside the parent node as it changes size, the offset and fChildren size would need to be recalculated in every loop.

The behavior of fChildren could be affected by the same directives fAutoSizeToFitChildren and fAutoExpandOnChildHit (pushing a node on the side of fChildren would expand parent and consequently fChildren in that direction) directives on the parent. If this is implemented fIncludePadding might be obsolete for the use-case with fChildren as it would be part of the offset between the boxes calculated already.

What problem does it solve?

Parent groups and nodes are not strictly just containers. They can practically be both - a Node with all the Node functionality and controls combined with being a container at the same time.

Have you considered any alternatives?

Alternatively the fChildren could also be placed outside the fNode body itself if needed and paired by parentId - in case you would need a detached designated area, but functionality still connected to a Node for example.

[siarheihuzarevich]

Thanks for the suggestion! Yes, this kind of fChildren functionality is something we are considering, but it won’t appear soon. Still, we appreciate the idea — it helps us shape the long-term direction of the library.