Thanks for creating the issue and your feedback. I am in the process of revising the technical implementation of the acktive state and the recognition of field arrays. I am aware of the problem through several issues and technically it can all be solved. However, I am currently writing my bachelor thesis and cannot say with certainty when I will get to the implementation.

However, I have already fixed some of the problems. Please test the whole thing once in the latest version. The length should work according to my tests.

Thank you, I will give the newest version a try :)

Yes, the newest version fixes that issue!

One question though: When I remove an item from an array via remove the array is not returned when calling getValues(form, { shouldDirty: true }). Is there even such a thing as a dirty state on an ArrayField?
Or is that something that is supposed to be implemented in userland?

Yes, field arrays also have their own dirty state. However, this is probably not yet fully implemented for the shouldDirty option. The dirty state changes whenever the items of a field array are changed by remove, insert and so on. Would the expected behavior on your part be that only then the array is returned or also when a field in the array is dirty?

Would the expected behavior on your part be that only then the array is returned or also when a field in the array is dirty?

Well, I don't know; it seems very case specific. I'll try to explain my usecase:

I have a gallery FieldArray, each item having "file" and "caption" fields. The API requires me to send the whole gallery array whenever there is a change inside (either fields values or added/removed enrties)
But when there is no change, I do not want to send the gallery array at all (null).

Currently I use <Form shouldDirty ... /> and in the onSubmit handler I check if gallery is defined. If it is defined, I use getValues(form, "gallery") to fetch all fields inside. This approach however does not work when removing items from the array, since gallery will be undefined (= no changes).

I was thinking of using a custom diff function. I could remove shouldDirty from <Form>, receiving all in the function argument and compare values with the initial values, as deeply as I need to. Basically writing my own "isDirty" check.
But for that I need a way to access the initial values from the form. Can I just use form.internal…?

Or do you have any other ideas how to solve the problem?

Yes, you can use form.internal. I don't recommend it for most users, but if you know what you're doing, it's fine. I think that in the long run, I may be able to solve this problem. Basically, the library needs to check if a field array is dirty or at least one contained field and if so, return the field array. However, since I am currently writing my bachelor thesis, I cannot give a timeframe for when I will get to the technical implementation.

It seems the issue happens because setValues sets arrays as both fields and fieldArrays. remove affects the fieldArray but getValues then retrieves the field version instead of the fieldArray version.

I've reproduced the issue in both solid and preact but the same line exists in all packages (solid, qwik, react, preact).

To reproduce the issue in the linked stackblitz:

First, click one of the "Remove item" buttons to interact with the form's initialValues then click submit. Everything works as expected and the onSubmit handler logs only 1 list field. You'll also notice that the console shows fieldArrayNames: ['list'], fieldNames: ['list.0.name', 'list.1.name'].

Now click "Set values" and again remove one of the items in the list. Now click submit and you'll see 2 list items instead of one. In fact, even if you change the value of the remaining input field and submit again, you'll see the value logged is not correct. Also, you'll notice that the console shows fieldArrayNames: ['list'], fieldNames: ['list.0.name', 'list.1.name', 'list'], fieldNames should not include list.

I've submitted #274 which seems to fix the issue based on local testing. This might also be related to #85.

Sorry for the late reply. I'll try to look at it next week, but I can't guarantee it with so many other things going on at the moment. 😐