Не очень ясно, как вы собираетесь что-то защищать в коде, который выполняется клиентом.
Решение о том, отдать ли данные принимает сервер.
Просто не отдавайте их и сделайте так, чтобы без них защищенные роуты умели только редиректить на логин.
Если пользователь проголосовал, лучше сразу отправить. Кроме того, состояние рейтинга будет меняться и другими пользователями, и лучше доставить новое состояние побыстрее. Впрочем, не для каждого голосования это важно...
SherbakovFirst, тут пример
как можно сохранить реактивность между компонентами. Если усвоите, то станет понятно, что менеджер состояний необходим не так уж часто, как может показаться.
А почему руководители и исполнители в разных таблицах?
Те и другие люди. Или социальные лифты априори не предусмотрены?
При такой архитектуре ваша бд будет терять целостность данных при каждом событии в отделе кадров.
Alexander Ivanov, я опираюсь на то, что наблюдал эту ошибку всякий раз, когда в исходных таблицах было либо много данных, либо много логики. Либо, когда цепочка IMPORTRANGE проходит белее, чем через 1 таблицу.
При этом без всяких манипуляций через пару часов всё прекрасно работало.
Поэтому мне сложно сделать какой-то другой вывод.
Abykeev, самое сложное уже позади.:)
Далее у вас будет цикл, который выводит "календари".
На каждой итерации выполняете поиск по массиву (который вы создали в п.3), получаете массив с объектами, соответствующими дате. Запускаете еще один цикл (вложенный), который выводит эти объекты.
Фёдор, а вот насчет фреймворка вопрос спорный.
В определённых ситуациях фреймворк тоже может стать топором в каше.
Тут всё зависит от бизнес-логики, которую требуется реализовать и от выбранной архитектуры.
И нужно всё взвесить:
это монолит? - тогда однозначно фреймворк.
Но если у вас в перспективе маячит много разных клиент-сервисов, всё становится не таким уж однозначным.
puppup, response.ok это не ответ сервера. Это мнение скрипта о том, ответил ли сервер.
Сервер вероятней всего ответил текстом ошибки и отправил её с кодом 200, поэтому клиент думает, что response.ok.
Вам надо во вкладке Network посмотреть что именно ответил сервер.
SherbakovFirst, мы же в контексте vue3? Не vue2? Если да, то она сохранится.
Если вы измените TaskList в дочернем компоненте (удалите/добавите элемент), он удалится/добавится и в родительском.
Даже если вы сделаете v-for (Task in TaskList) :TaskItem ="Task" и измените какое-нибудь свойство TaskItem, это также изменится и в родительском TaskList.
Причем потомок не обязательно должен быть дочерним, он может быть и внуком и правнуком.
Главное, чтобы родительский объект был в ref().
Так же может стать неожиданным, что в теле скрипта обращаться к нему следует TaskList.value
Здесь нужно условное форматирование.
Вы сказали таблице, что хотите, чтобы E3 была синей. Это всё, что ей известно.
А ей нужно сказать: будь синей, если значение 2-й строки твоего столбца между значениями B и C твоей строки.
Ну исходя из того, как сформулирована задача, вам нужно
1. Создать новый массив.
2. Перебрать каждый из 3-х имеющихся, добавляя по пути в каждый объект свойство color и складывая в новый массив.
3. Отсортировать получившийся новый массив по полю start_date.
Дальнейшие действия зависят от понимания требуемого результата:
если есть завтрашний календарь, то есть и вчерашний, позавчерашний, послезавтрашний....
Или достаточно прошлого и будущего... Не ясно.
В таком случае Михаил Ливач говорит всё верно.
Тут похоже действительно нужно найти или создать способ измерить время функции.
Но мне непросто представить себе задачу, которая выполняется дольше, чем запрос.
Большинство вычислений я поручаю sql, поскольку это синтаксически проще.
Refguser, так и мой ответ не про, чтобы скрыть. Он про то, как получить данные.
ВП ожидает, что они будут в массиве $_POST. Их там нет, потому что они пришли в php://input
Решение о том, отдать ли данные принимает сервер.
Просто не отдавайте их и сделайте так, чтобы без них защищенные роуты умели только редиректить на логин.