Смысл изменения стейта снаружи, в том, что я могу по нему выводить какие-то общие данные, по жэтому не могу его менять в каждом Item отдельно. Получается никого решения не существует, и это нормально поведение?
P.S. И как быть, если массив состоит из пары сотни item, это же их каждый раз все перерисовывать придется в цикле.
Да, действительно мне приходится также учитывать время, я опустил эту информацию в вопросе т.к. с этим проблем нету. Выше уже предлагали использовать транзакции, и у меня возникает вопрос, разве это не испортит логику хранения данных, мы получается выносим условие хранения данных в запрос, и в случаи утери этого запроса бд не будет знать как хранить правильно данные. Разве это хорошее решение? Просто это похоже на ситуацию, как если бы мы убрали у какого нибудь поля уникальность, и добавили для контроля транзакции, это получится потенциально проблемное место.
DevMan, запросы это же просто способ изменения или получения данных из бд. Для хранения отношения между собой данных мы используем ключи, внешние, уникальные и т.д. чтобы бд самостоятельно контролировала правильность хранения данных. Если я вынесу это ограничение на кол-во брони в зарос, получается бд не будет контролировать правильность данных и может быть ситуация когда кто-то, поддерживая например этот проект, не учтет это и мы получим мусор в бд. Разве использование транзакций таким образом не портит логику проекта?
Я читал про них, они позволяют выполнить несколько запросов как одно целое. Но разве это правильный подход? Получается логика хранения данных находится в запросе, которые может быть изменен или утерян. Мы же создаем ключи специально чтобы бд сама поддерживала данные в нужном нам виде, разве не так?
Дмитрий Шицков, по тому что я не знаю как их вынести, в этом и суть вопроса, как правильно хранить подобные данные, когда в зависимости от роли, меняется достаточно большое кол-во столбцов. Выносить это в абсолютно независимые таблицы не получится из-за авторизации и общих полей типа email
Евгений Ромашкан, уже думал, получается что у меня не получится стоить выборку с сортировкой пользователей по имени например т.к. эти данные будут лежать в json
BoShurik, общие поля, только email, password и role. Остальное у каждого пользователя свое, и при такой структуре возникают проблемы с добавлением новых ролей, и удалением старых.
Антон Р., даже если я вынесу роль в отдельную таблицу, проблема с кучей столбцов остается, если мне нужно будет удалить роль, то мне придется выискивать все столбцы что использовались для конкретной роли
Зачем сразу другого? coffeescript отличный пример того что я ищу, но для python, там просто другой синтаксис который конвертируется в чистый js, что-то вроде синтаксического сахара, только составляющего 90% кода. Неужели нету подобных проектов? ( у меня не получилось найти )
Алексей Уколов, проблема в том, что из-за того что setData запускать нельзя, приходится создавать mock, а при создании в mock объекте заглушки данные теряются и я не могу для них вызвать assertEquals, чтобы узнать результат работы doSomething
