Dynamically loading a list entries based on a form condition

[jamesmacwhite]

Question

Is there any possible way with the current functionality/extendability with Formie to dynamically load a list of entries from a data source and replace this on existing select field?

I'd imagine I could implement something custom myself with JavaScript events, but obviously looking at using the Formie JS/events first.

The use case I have is based on the selection of another field I want the list of options in a select field to be dynamically loaded and modified, given the value selected on the first field influences the values returned on the other.

Rather than use dropdowns, I was thinking using entries fields so I have more control over the data criteria part given they are not fixed and also if we remove options I don't want this to affect submissions, with entries these can be disabled to prevent them being visible but still be in the data for this part.

The main area is the dynamic loading of options on the select field. I could implement a controller/Element API endpoint to return the data needed to be replaced, but just in case I'm over complicating it.

Additional context

No response

[engram-design]

Nothing native to Formie on this, sorry. You couldn't use the value or another field as the source for a query to create dynamic options. It's something we maybe might look at for element fields, but you'd be the first person to ask about it.

Absolutely possible with some custom fields, or even just custom JS and a template/module controller that returns JSON data for the dropdown items - as you mention. I think that's a solid plan, and not overcomplicated at all.

[jamesmacwhite]

@engram-design Thanks! No worries. I thought so.

I've been able to partially use existing Formie JS events as the field being targeted for dynamic values is within a repeater, so using: https://verbb.io/craft-plugins/formie/docs/developers/javascript-api#the-initRow-event

I can then do a fetch to the JSON endpoint and return the values to replace.

The element query event would normally be fine, but it would only work for on render/load and given this is based on another field value after rendering, it can't be used. A JS version of modifyElementFieldQuery would potentially make this easier, but probably a bit of a unique use case.

I've used conditions to hide the repeater until the field related has a value that's not empty.

[jamesmacwhite]

A follow up question! I have an additional use case where if the value of another field changes, I want to remove all instances of any Formie repeater rows, given they might not be valid for the new selection anymore.

How can I use repeater.js to correct destroy the row instances, so any new instances created after this will be correct and start at the array index of 0 and not continue from the previous? Removing the DOM elements wouldn't be enough as it looks like from the data attributes from the original instances are still being stored and incrementing the index count.

[jamesmacwhite]

Maybe something like this?

let selectField = document.querySelector('[data-field-handle="selectField"] select');
let $fields = document.querySelectorAll('[data-field-type="repeater"]');

selectField.addEventListener('change', function(event) {
    $fields.forEach($field => {
        const repeater = $field.repeater;
        const rows = repeater.getRows();

        rows.forEach(($row) => {
            $row.parentNode.removeChild($row);
        });

        repeater.updateButton();
    });
});

[engram-design]

Looks right to me!

[jamesmacwhite]

Great! The only thing I noticed, was data-repeater-row index still seems to "remember" the removed rows and kept counting up as if the original deleted row was present, but when submitting this appeared to be OK, I assume on the server side there is possibly some logic that's removing empty arrays potentially?

[engram-design]

Oh, I might suggest using repeater.removeRow($row) to replace repeater.updateButton() (see reference).

[jamesmacwhite]

Thanks for the tip! The index still seems to keep incrementing. Although testing the normal remove button seems to behave the same, so I guess that's normal?