Buggy deletion of objects in arrays

[Vettl5]

I don't know, if this is a bug or a feature, but I noticed something strange while implementing your Guifier in a work project. The use case is, you have an array with at least 3 objects in it (because that is the minimum amount of objects, where all characteristics of the bug are visible). My problem was, I needed the current data in the guifier immediately after an element (regardless of object, array or primitive type) gets deleted from it. But it appeared to have weird behavior after deleting an object from an array, as followed:

We assume, that the array holds the following data: [ i=0: {name: "Max", age: 7 }, i=1: {name: "Susi", age: 9 }, i=2: {name: "Colin", age: 10} ]

• case 1: you delete the first object in the tree order of the array.

After doing so, the array should look like this: [ // here was the deleted object i=0: {name: "Susi", age: 9 }, i=1: {name: "Colin", age: 10}, ] but instead, Guifier gives back an array, that looks something like this: [ i=0: {name: {_fieldtype: "text", _key:"name", _value:"Susi"}, age: {_fieldtype: "number", _key:"age", _value:9}}, i=1: {name: {_fieldtype: "text", _key:"name", _value:"Colin"}, age: {_fieldtype: "number", _key:"age", _value:10}, i=2: {name: "Colin", age: 10} ] So it seems like, Guifier deletes the object that is supposed to be deleted and directly after that, it creates a new one in the same place, uses the same properties in it, but for the values of the properties it creates another object with the attributes of the neighbour object (index i+1) (BUT it ONLY adds a new object in place, if it finds an object for i+1). And appearently, it does this for every object in the array, that comes after the object selected for deletion in tree order as well, until it finds no i+1 neighbour anymore. That is why, for the last object in the array, it does nothing. If there were 5 objects in the array and you deleted the first one, it would have done this 4 times and so on.

• case 2: you delete the penultimate object (one before the last) in the tree order of the array:

After doing so, the array should look like this: [ i=0: {name: "Max", age: 7 }, // here was the deleted object i=1: {name: "Colin", age: 10}, ] but instead, Guifier gives back an array, that looks something like this: [ i=0: {name: "Max", age: 7 }, i=1: {name: {_fieldtype: "text", _key:"name", _value:"Colin"}, age: {_fieldtype: "number", _key:"age", _value:10}, i=2: {name: "Colin", age: 10} ] As I mentioned in case 1, it acts the same behavior, but cannot find a neighbour for i=2 (Colin) and stops there.

• case 3: you delete the last object in the tree order of the array:

After doing so, the array should look like this: [ i=0: {name: "Max", age: 7 }, i=1: {name: "Susi", age: 9}, // here was the deleted object ] and it actually does look like that. Because again, if it cannot find a next object for the current index i+1, it does NOT create a new object in the same place as it would in case 1 or 2. Colin got deleted, and after Colin, there was no other kid/object to be found.

Nobody would notice this visually, because in the Guifier UI, the deleted object disappears. But I implemented an event delegation in my code, which gets called every time, a button in the Guifier with with the textContent "delete" gets clicked. It then calls the function guifier.getData(), to save the current data in a variable or localStorage after the user deleted something. And if you look into that saved data by echoing it in the console, you see what I saw. The dataset is not clean. And because of that, if you try to ADD an object in a different array after you just deleted one or more in the first array, those newly created objects in the first array with properties that hold again properties magically appear again in the first array but with corrupted data and null types (its of course not reliably readable, if the values of the properties in the array are stored in objects)

Because there are some other missing features (e.g. working with yaml schemas to validate the structure and content of the guifier data, adapting the possibly addable objects/arrays/primitive types from the schema into the overlay menu instead of giving just the option to generally add those somewhere, removing delete buttons for required fields based on the validation schema etc.), I am constantly finding workarounds with DOM manipulations and I don't want to find another one for this. Could you please have a look into this? Tell me, if I am missing something. Thanks in advance!

[maliknajjar]

Hi @Vettl5, thanks for using Guifier!

You're absolutely right — this is definitely a bug. You shouldn't be seeing an object like {name: {_fieldtype: "text", _key: "name", _value: "Colin"}}; that's an internal representation and should be hidden from the UI.

I’ve come across this issue before. It typically happens when the root of your JSON is an array instead of an object, like this:

[
  { "name": "Max", "age": 7 },
  { "name": "Susi", "age": 9 },
  { "name": "Colin", "age": 10 }
]

If you wrap it in an object, like this:

{
  "array": [
    { "name": "Max", "age": 7 },
    { "name": "Susi", "age": 9 },
    { "name": "Colin", "age": 10 }
  ]
}

…the issue should disappear.

Of course, we need to fix this properly on our end. But in the meantime, can you confirm if switching to a root-level object resolves the issue for you?

[Vettl5]

Interesting, but not a suitable solution for my case. I cannot change anything in the structure schema of the file. I found a solution by myself by comparing the exported data from guifier to the original previous data (saved in a variable and in localStorage) and find the first object, that differs to the original data. Then I delete this object in the original data and give the whole stringified object back to guifier, to clean up the messed up data. I can remove this function as soon as you fixed the problem. Looking forward to it!

[maliknajjar]

it will be hopefully fixed in version 2 of Guifier im just a bit busy with work. if anyone wants to create a PR that will be very helpfull

[maliknajjar]

Hi @Vettl5. how are you? GuifierV2 is now used in the guifier.com and this issue is totally fixed

[Vettl5]

Great to hear! Thanks for the effort, very much appreciated! I will have a look as soon as I am working again on the project and hopefully will give feedback. Thanks again 👍