@ExtAnimal's approach to optionally use objects is charming, since we can enhance configurations via deep merges => only changing the parts we like to.
Current limitations: afterSetItems() will transform the object into the old array based structure right away.
- We can only statically enhance item objects.
- We are losing the original definition on instance level (well, we can still look at it inside the originalConfig / prototype)
- We can not use other
afterSet() hooks to further enhance / change object based item definitions
- It might not be clear for devs, that the hooks will already always get the items array
One strategy to keep the API consistent would be to use a new config like itemsObject. afterSetItemsObject() could do the transformation and store the result inside the real items config. This way, we could change the itemsObject at run-time. However, the transformation logic needs to be smart. Regenerating the array is not expensive, but re-creating existing item instances must not happen (this can become very expensive).
Thoughts?
@ExtAnimal's approach to optionally use objects is charming, since we can enhance configurations via deep merges => only changing the parts we like to.
Current limitations:
afterSetItems()will transform the object into the old array based structure right away.afterSet()hooks to further enhance / change object based item definitionsOne strategy to keep the API consistent would be to use a new config like
itemsObject.afterSetItemsObject()could do the transformation and store the result inside the realitemsconfig. This way, we could change theitemsObjectat run-time. However, the transformation logic needs to be smart. Regenerating the array is not expensive, but re-creating existing item instances must not happen (this can become very expensive).Thoughts?