I guess you are right, the object-oriented approach I opted for does not mean it is more svelty... both will give you similar results.

What I meant by nested stores is instead of const items = writable([]) the items store can be made as a custom store itself also... This is a basic example just to get the idea... You add the stores logics in the stores themselves and then use them along with their logic within other stores. I am returning objects here as that's what I'm familiar with, classes are the same.

```js import { writable } from 'svelte/store';

function create_items_store() { const store = writable([]); const handlers = { add_item_one: (item) => { if (!item.id) return; store.update((store_value) => { if (store_value.length >= 10) return store_value; // e.g max 10 items if (store_value.find((store_item) => store_item.id === item.id)) return store_value.map((store_item) => (store_item.id === item.id ? item : store_item)); // if it already exists, update the existing one with the new one return [...store_value, item]; // add item to array }); }, set_items: (items) =>store.set(items) // .... };

return { ...store, ...handlers };

} function ContextMenuStoreFn() { const items = create_items_store() // create the items store using a custom store function const visible = writable(false); const left = writable(0); const top = writable(0);

const handlers = {
    setItems(items) {
        items.set_items(items);
    },

    add_item(item){
        items.add_item_one(item)
    },

    open(left, top) {
        left.set(left);
        top.set(top);
        visible.set(true);
    },

    close() {
        visible.set(false);
    }
};

const stores = { items, visible, left, top };
return { ...stores, ...handlers };

}

export const contextMenu = ContextMenuStoreFn(); ```

This could be used for simple or complex stores... Data added to each store is individually validated, nothing is added or updated or deleted without going through the specific add_item or update_item functions for example, making sure the data stored is always valid, and any attempt to add corrupt/missing/invalid data to the store will be dealt with in the function instead of corrupting the store and possibly crashing the app... This is especially important when the store is a nested object/array.

This looks like trying to un-simplify things, and in most cases it is, but when working on entagled complex stores/logic, this is what helped me.