да, можно, но если этого будет слишком много код превратится в кашу. Исключения нужны для критических мест приложения от которых зависит ее работа, их принято кидать из библиотек... короче из сервисного слоя. Повышает реюз кода.
ну как... вообще виртуальная машина js-а (во всяком случае v8) оптимизирует только локальный код. То есть если у вас идет доступ к глобальной переменной, никаких оптимизаций существенных (сокращающих время доступа к пропертям, элементам массива и т.д.) не будет.
Но опять же я вообще не вижу смысла в подобном функционале. Вы пытаетесь датабиндинг свой организовать? возьмите тогда на вооружение реализацию скоупов из Angular.js. Для других целей мне сложно придумать подобное поведение, проще организовать get/set метод (все же с localStorage можно работать через setItem/getItem, и как по мне это более рассово верное решение.
субботу вечер и я пьян, а чего хотите вы? Обзерверы решают проблему отслеживания изменений объекта. По добавлению проперти можно назначить геттер, геттер можно реализовать один для нескольких полей, по типу или как-то еще, собственно вот и все.
не знаю что вы там знаете не знаете но поясню свои "много букв".
Вы всегда знаете какие проперти у вас есть, вы можете это узнать в рантайме. Вы можете затрекать появление новых пропертей (Object.obsorver). Вы можете установить геттер/сеттер для этих новых пропертей. Вы можете написать прокси объект который будет это все делать. Писать несколько getName/setName ненужно, просто назначать один и тот же обработчик для геттеров и сеттеров (вы же писали что знакомы с возможностями js по добавлению геттеров и сеттеров)...
Другой вопрос что такая магия считается плохим тоном. Единственное применение этого дела - дата биндинг, но это можно сделать через object.obsorver.
мне кажется у вас ООП головного мозга. Вы кажется не понимаете принципов прототипного наследования.
По поводу localStorage - это просто hash-map, если вы напишите localStorage['test']['sub'] = 4; и проперти test в сторадже не будет у вас так же будет крэш. Никакой магии ненужно, если вам нужен доступ к одному уровню - никаких сеттеров и геттеров ненужно.
Если вам нужно содержать какую-то логику по выборкам данных - вы так или иначе должны знать какие проперти у вас есть, можете динамически добавить для вашего объекта геттеры/сеттеры и добавлять их или убирать если поля изменятся.
суть в том что вы должны кешировать только данные. При изменении данных можно сбрасывать (а лучше сразу перезаписывать) только те данные, которые изменились. Кеширование html или того что возвращает ваше приложение лучше переложить на более специфичные штуки аля varnish.
вот всегда было любопытно, чем руководствуются люди, которые на вопрос "посоветуйте инструмент" всегда рекомендуют свой гаечный ключ на 12, все зависимости от того, что им придется делать... ни аргументации, ни противопоказаний...
а что в этом сложного? Это же и есть вся суть monkey testing... вся соль в том что бы найти ошибки (404, 400, 500), которые могут быть вызваны пользователем. Речи о корректности работы логики не идет. Нужно просто пробежаться с главной в глубь сайта (скажем на 10-15 уровней), по заполнять формочки если есть, потыкать кнопки... Как бы да, возможно это просто никому не нужно... я сам впервые сталкиваюсь с необходимостью подобного, ибо тестировщика нету, смоук-тесты некому проводить...
