Комментарии 5
Из того что вызывает вопросы - в интерфейсе (абстрактном классе) StorageInterface есть два комплекта методов, синхронные и асинхронные. Реализуется всегда только один из них. Подозреваю, что тут нарушение принципов L и I из SOLID
в интерфейсе (абстрактном классе) StorageInterface есть два комплекта методов, синхронные и асинхронные. Реализуется всегда только один из них.
Это не всегда так. Например MockInterface и MapInterface реализуют и те и другие. В любом случае, при попытке использования нереализованного метода будет выброшена ошибка.
Я правильно понимаю, что разработчик этой библиотеки - вы? Судя по репозиторию, это так, поэтому вопросы про интерфейс и реализацию буду задавать вам.
Самый главный вопрос: для чего такая абстракция? У localStorage и sessionStorage и так общий интерфейс. IndexedDB же обычно используется для других целей, чем Storage. Ограничения на значения и особенности их хранения у него, опять же, другие.
Мне кажется, можно было бы не изобретать свой интерфейс, а взять тот же самый Storage, и дописать для него нужные вам реализации (для Map, например).
Использование Proxy тоже выглядит не слишком оправданным. Например, из-за такого интерфейса, получается, в вашем хранилище нельзя сохнанить данные по ключу entries, раз он занят методом? Использование ключей, начинающихся с __ (вместо, например, приватных полей) тоже вызывает вопросы к тому, что возможны коллизии.
Плюс еще одна причина, почему мне не нравится такие интерфейсы - они ломают ожидания о производительности. Вряд ли многие программисты будут ожидать, что когда они будут просто читать поле объекта, это будет обращение к внешнему хранилищу.
Я правильно понимаю, что разработчик этой библиотеки - вы?
Так и есть.
Самый главный вопрос: для чего такая абстракция?
Добавляет удобство использования и чтения кода за счет того, что мы можем работать с хранилищем как если бы это был просто объект. Кроме того, можно включить кеширование для запросов, что приведёт к повышению производительности. При этом код остается простым.
получается, в вашем хранилище нельзя сохнанить данные по ключу
entries, раз он занят методом?
Да, так и есть, это описано в документации в разделе Limitations. К сожалению, с этим ничего не поделаешь.
Использование ключей, начинающихся с
__(вместо, например, приватных полей)
Насколько я понял, вы увидели __ на скриншоте. Это ключи в localStorage, а не в экземпляре. Если не включено кеширование, ключи вобще не хранятся в экземпляре, а сразу пишутся в localStorage, следовательно использование приватных полей невозможно. Если говорить про включенное кеширование, то кешированные ключи хранятся в Map (MDN). При попытке записи ключа, имя которого совпадает с именем ключа в котором хранится массив ключей для "виртуального" хранилища будет выброшена ошибка. Но это достаточно маловероятная ситуация, чтобы её получить надо написать что-то вроде storage[__storageTwo-keys-array] = .... В любом случае, такая проблема может возникнуть только в расширенной версии с "виртуальными" хранилищами, в SessionStorageThin ключей с __ в localStorage нет.
Плюс еще одна причина, почему мне не нравится такие интерфейсы - они ломают ожидания о производительности. Вряд ли многие программисты будут ожидать, что когда они будут просто читать поле объекта, это будет обращение к внешнему хранилищу.
Возможность работать с хранилищем как с простым объектом это и есть основная фишка этой библиотеки. Но да, вы правы, это может быть неожиданно.
Опечатка, вместо SessionStorageThin должно быть LocalStorageThin.
Обертка для indexedDB / localStorage /…