тестовое задание
 

в общем имеются следующие условия:
http://jsbin.com/ladobefoji/edit?js,output

сделал вот так :
https://jsfiddle.net/t73w9obn/1/


по поводу сохранения данных на сервер не пойму что они от меня тут хотят...

DynkanMaclaud,
Uncaught TypeError: Cannot read property 'push' of undefined (index):138

В примере запись можно сохранять, изменять и удалять.

Возможно собирать введенный текст и сохранять в объекте.
Объект сериализовать и отдавать на сервер через протокол http, аяксом.

Rasy,
изменил ссылку на рабочий пример...

DynkanMaclaud,

у тебя класс Notes сочетает в себе и модель, и вьюху. По сути, наследуется от модели.

Возможно, правильнее было бы оставить модель отдельно, и, например, передавать её в конструктор вьюхи, или ещё как-то.

В самой модели предусмотреть асинхронный интерфейс (для взаимодействия с сервером). В идеале - модель должна быть EventEmitter, тогда вьюха просто сможет на неё подписываться и обновляться. При таком раскладе всякие прочие компоненты смогут тоже работать с моделью, а не с вьюхой.

В общем, как-то так.

Alexandroppolus,
т.е предлагаешь паттерн observeble (обозреватель) впилить ??

DynkanMaclaud,
ну это если совсем правильно делать :) повторюсь - это чтобы другие компоненты страницы могли с твоим компонентом работать, если вдруг такой кейс понадобится.

по рендеру - наверно, для обработки событий правильнее будет использовать делегирование, а конкретно вот такой подход: https://learn.javascript.ru/behavior - т.е. вешать один обработчик конкретного типа события на родительский элемент, смотреть target, ну и т.д. Чтобы при каждом обновлении обработчики не ставить на отдельные элементы.

DynkanMaclaud,
Работа с localStorage и JSON.parse без try...catch. Поправьте, пока никто не поранился.

Имхо, если предусмотрено общение с сервером, то локальное хранилище лишнее:)

destus,
можно пример того как вызов JSON.parse именно в этом коде, может выдать ошибку ... ? другими словами что пользователь может написать что код не отработает... ?)

Alexandroppolus,
запилил обозреватель...
https://jsfiddle.net/t73w9obn/2/

Он может банально через инструменты разработчика изменить сохраненный json и сделать его невалидным.

destus,
и многих вы рядовых пользователей знаете которые через инструменты разработчиков правят json ???)))))

destus,
ничего не имею против, хочется увидеть именно сногсбивающую аргументацию...)))

destus,
касательно архитектуры что скажите?? господа вам не кажется что когда в задании вас просят

Задача: отрефактировать код без использования сторонних библиотек.
Исправить баги, улучшить качество, maintainability, читабельность.
CSS писать не нужно.

Должен получится независимый компонент,
легко встраиваемый в любую вёрстку и не ломающий окружение.
Возможно в будущем захочется сохранять данные на сервер
и как-то ещё расширять возможности компонента.

и тут я юзаю паттерн, паттерн который например использовался на моей работе как взаимодействие компонентов... да это сейчас он маштабируем а когда 20 компонентов взаимодействует между собой, он не поддерживаем...

ну а кто мне минус кармы дал то отпишите аргументы...

Смысл в том, что нужно предусмотреть все возможные ситуации, и грамотно их обрабатывать. Это может быть json с нашего сервера, со стороннего апи. Не важно. Что более важно, так это написать гибкое приложение, которое будет обрабатывать по-возможности все возможные ошибки и грамотно на них реагировать. JSON.parse, как и обращение к localStorage всегда с try...catch.
Далее, у вас не получился компонент как таковой.
Во-первых, он наследуется от модели, что является очень плохим решением.
Во-вторых, компонент должен получать кусок состояния через биндинги сверху и отрисовывать UI. Это если мы говорим о stateless компонентах. Для statefull - источником данных могут быть сервисы. Под капотом взаимодействие с DOM событиями, но опять же, компонент сам не меняет состояние. Нужно либо генерировать событие и просить это сделать внешний код (EventEmitter), либо просить это сделать сервисы, складывая всю ответственность на них.
Ну и в-третьих, в коде есть баги. Если, например, открыть несколько записей для редактирования, и нажать Save / Remove по любой из них, то все открытые записи выйдут из режима редактирования.

Можете объяснить почему?
Если обернуть взаимодействие с localStorage в класс, который будет проверять доступно ли оно или нет и преобразовывать все данные в строку перед записью, то есть ли смысл оборачивать localStorage во wrapper'е в try catch?

Nexus,
https://developer.mozilla.org/en-US/...eb_Storage_API
пункт "Testing for availability".
скорее в функцию, которая проверяет доступность хранилища.

destus,
благодарю за информацию.
Можно, конечно, в коде постоянно проверять доступно ли хранилище, но, по-моему, удобнее реализовать класс.

Nexus,
Можете и через класс, но просто проверить доступно оно или нет, этого мало. Установка нового значения может упереться в отсутствие памяти и выбросом исключения QuotaExceededError https://www.w3.org/TR/webstorage/#storage

destus, я понял, что доступность хранилища не гарантирует корректного с ним взаимодействия.

Почему наследуется?, Notes не имеет методов Storage, в конструкторе Notes я создаю Storage (да правильнее было бы передавать его как аргумент), и прокидываю туда Notes, т.е модель при инициализации подписываает View на события, а view триггерит эти события, которые улавливает Storage...

destus,
не могли бы вы показать мне какой нибудь простой пример, именнно то как вы видите компонент

Rise,
как такой вариант ? https://jsfiddle.net/yaepa0u2/7/
что насчет делегирования скажите?? стоит ли делать? неудобно будет сохранять индекс элемента в атрибуте ... потом через e.target , получать а далее в storage.remove ... и т.п, в данном случае из замыкания достает...

Плохо
Разные стили function Storage, class Notes

this.data = load() ? load() : [];

зачем дважды выполнять load(), если он вернет результат

var storageEnable = (function () {
        var state = false;
        try {
            window.localStorage.setItem('test', 'a');
            state = window.localStorage.getItem('test') === 'a';
            window.localStorage.removeItem('test');
        } catch (err) {
            console.log('Local storage disable');
        }
        return state;
    }()); // утка если крякает

this.remove :stop:
splice
this.set очень интересно. здесь либо this возвращать, для использования в дальнейшем цепочки вызовов или присваиваемое значение для плюшек в синтаксисе
если несколько раз используете document.createElement
то можно для создания написать функцию

<script>
function buildElement(tagName, props) {
  var element = document.createElement(tagName);
  for (var propName in props) element[propName] = props[propName];
  return element;
}

document.addEventListener("DOMContentLoaded", function() {
  var btn = buildElement('input', {
    type: 'button',
    value: 'Delete',
    style: 'background-color: red'
  });
  document.body.appendChild(btn);
});
</script>

и наверное лучше было раз создать, а затем по необходимости клонировать эти элементы