Calcite Flow without removing panels from the DOM

[nel11211]

Description

It seems that the calcite-flow component removes each panel from the DOM on a back() call. This poses an issue for ArcGIS Charts implementation. One of the panels we add to our calcite-flow harbors underlying logic for the chart config modifications. Ideally this would stay active throughout the usage of the UI. But since it seems that calcite-flow actually removes each panel on a back() call, we end up losing that operation logic until the user navigates forward to that panel again.

We are considering temporarily removing use of calcite-flow and instead hide/show each panel as the user navigates. This seems to be working in tests, but is obviously not preferable. We'd much rather be in sync with calcite-flow changes, and not have to maintain our implementation separately.

We discussed the alternative of trying to save the needed panel state as a whole. The issue there is simply the sheer volume of logic integrated into our chart component would make for a major overhaul of the codebase to decouple it from the Stencil component lifecycle. It would be far more convenient in our case if we could retain the presence of the existing panel component throughout usage.

Would it be feasible to add some flexibility to the calcite-flow so that we don't need to remove the panels from the DOM as the user navigates?

Which Component

calcite-flow

Example Use Case

ArcGIS Charts current usage: https://devtopia.esri.com/WebGIS/arcgis-charts/blob/43eefcf66c1ec067c7d53df69960b2465a2c0503/packages/arcgis-charts-config-components/src/components/arcgis-charts-config-create-flow/arcgis-charts-config-create-flow.tsx#L320

CC: @jcfranco

[driskull]

@nel11211, we do have a property on the flow called beforeBack, which can be used to store the panel if necessary.

https://github.com/Esri/calcite-components/blob/master/src/components/calcite-flow/calcite-flow.tsx#L34-L42

Otherwise, we can look into doing something different. It might not be ideal to keep the panel in DOM when not in use though but maybe we could just hide it instead.

[nel11211]

@nel11211, we do have a property on the flow called beforeBack, which can be used to store the panel if necessary.

https://github.com/Esri/calcite-components/blob/master/src/components/calcite-flow/calcite-flow.tsx#L34-L42

Otherwise, we can look into doing something different. It might not be ideal to keep the panel in DOM when not in use though but maybe we could just hide it instead.

Thanks @driskull,
The problem isn't so much that we lose access to the object reference, it's the fact that the panel is removed from the DOM automatically by calcite-flow. That in turn initiates the Stencil destructor routine for the chart configuration panel. When that happens we lose active watchers, lifecycle positions, prop/value states, etc. associated with that config panel and all its children.

Some capability (even just a non-default option on calcite-flow) to not remove() the panel when navigating would allow us to fix this setup on our side without having to remove usage of calcite-flow.

[driskull]

@nel11211 I think you should be able to use the beforeBack property to specify a function to move the panel's content before the panel is removed.

[nel11211]

@nel11211 I think you should be able to use the beforeBack property to specify a function to move the panel's content before the panel is removed.

Hmm, so you mean something like:

• Grab the panel using beforeBack.
• Move it outside the calcite-flow (say as a sibling).
• Hide that panel.

Then on forward navigation:

• Move the panel back into the calcite-flow.
• Unhide that panel.

Ya that sounds plausible, I'll try it out and see how it goes. Thanks

[nel11211]

@nel11211 I think you should be able to use the beforeBack property to specify a function to move the panel's content before the panel is removed.

Hmm, so you mean something like:

• Grab the panel using beforeBack.
• Move it outside the calcite-flow (say as a sibling).
• Hide that panel.

Then on forward navigation:

• Move the panel back into the calcite-flow.
• Unhide that panel.

Ya that sounds plausible, I'll try it out and see how it goes. Thanks

@driskull
This doesn't seem to work. Because calcite-flow back method always calls lastItem.remove() after beforeBack finishes, it doesn't matter if I move the element to a new place in the DOM, it still gets removed by calcite-flow.

[driskull]

@nel11211 can you remove the content from the panel that you need to keep? The panel will get removed but you can save anything you need from it.

[nel11211]

@nel11211 can you remove the content from the panel that you need to keep? The panel will get removed but you can save anything you need from it.

Do you mean append child elements back and forth between the flow panels and the dummy locations? It sounds a bit hacky, dynamic element restructuring done after the render seems to go against the purpose to using Stencil components.

If that will actually work and there's no other way to deal with the calcite-fab calling .remove() I can try to write something to that effect. But I'm apprehensive about that sort of dynamic element manipulation.

[geospatialem]

Not currently a pattern Calcite is seeking to follow and would require a breaking change. Reallocated to the Freezer for now.

[jcfranco]

Closing in favor of #5072.