This post has been republished via RSS; it originally appeared at: Healthcare and Life Sciences Blog articles.
Many FHIR include complex nesting. For example the Item component of Questionnaire can either be a single item or an array of more items, which can themselves also be arrays of more items, with even more arrays below. Arrays all the way down! A previous post (FHIR + Blazor + Recursion = Rendering a Questionnaire ) showed a method to render objects with complex nesting: using Dynamic Fragments. This article shows an alternative method: using self-referential components.
Why use components?
Components will allow easier reuse than Dynamic Fragment rendered pages. Imagine a case where we want to both create new and allow updates of complex nested children. If we use components, we can easily adapt a component for both EDIT and CREATE. More reuse means less code!
How it’ll work
We’ll create a parent component. The parent component will render the child component.
AND HERE’s THE MAGIC:
The child component will render additional child components.
FHIR Specific Example
Check out the code below from (FHIRBlaze)
Parent Component (QuestionnaireComponent)
Note the ItemDisplay component.
Child Component ( ItemDisplay )
Line 58 is the key line. This component renders itself!
With this you should be able to quickly render nested Item after nested Item. But there are some caveats you should know.
#1: Memory Consumption
As you render each nesting- all those objects are loaded into memory. If a FHIR has an unknown number of children- each of which could have its own children, you could potentially consume large amounts of memory. This is a particular problem because you could be rendering on a phone.
Suggested Mitigation: Consider rendering to a max depth and a max number of children. Render “see more” type links to allow the user to see remaining children
#2: Display Clipping
The standard approach is to indent children. But if you have 5 levels of nesting and the app is rendered on mobile than your 5th level children may show up in a single character column. If you render 100 levels of nested children, your final level may not render at all.
Suggested Mitigation: Consider an alternative to displaying all children. For example- consider using collapsible sections to show children.
#3: Labeling Problems
If you’re allowing Edit of a component with complex nesting it may be difficult for a user to remember which level of children, they are in. For example, imagine the following are rendered as cards: Parent 1: Child 1: Child 2: Child 3: Child 4: Child 5.
Suggested Mitigation: Consider using borders and labeling to help users determine which child is currently selected