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