Если чисто по ошибке говорить, то SWITCH в данном случае является областью видимости и внутри него нельзя объявлять переменные с одинаковым именем.
Если хотите объявлять одни и те же переменные внутри CASE, то просто создайте еще один локальный Scope, добавив фигурные скобки.
Как-то так:
switch(characterChoose)
{
case 0: {
int PlayerDamage = 50;
int PlayerHealth = 150;
int PlayerResist = 25;
break;
}
}
А таски где прилетают? Вроде как во всех трекерах есть функция "Зависит от", где указывается другая задача, без которой ну никак эту не закрыть. А далее как воркфлоу настроен: иногда бывает так, что задача не переходит в выполнение, пока задача (от которой зависит таска) не перейдет в merged.
Само собой что деление на features принято для того, чтобы меньше кода между собой переплеталось, а то смысла вообще никакого...
"Умные мысли преследовали его, но он был быстрее..."
Без уточнения задачи это вообще не имеет никакого смысла.
Чем вас не устраивает обычный SELECT?
Где вам нужно пробежать по строкам? В функции/процедуре БД? В каком-то стороннем приложении?
OCCASS OCCASSOVICH, да. Иначе, зная эндпоинт, можно будет править любые посты, не являясь автором этого поста, просто отправляя POST-запросы на этот эндпоинт.
Обычно, если у вас есть разделение на клиент и АПИ, то с запросом посылают JWT-токен, в котором есть вся нужная информация. АПИ перед работой с БД, подтверждает валидность токена, парсит его и достает доступы, сравнивает их с каким-то эталоном и правит пост или же возвращает ответ "доступ запрещен".
И тут уже не важно, что на клиенте: пока не прикрепишь к своему запросу валидный токен - изменить пост не получится.
Александр, пускайте специально обученных людей со специально созданными правами доступа в специально созданную схему БД. Пусть работают через GUI клиенты...
Зависит от решаемых задач, конечно.
psiklop, все зависит от того как много операций производится с этими данными и где это чаще всего происходит. Исходя из этого уже можно думать как лучше поступить. Если у вас запись и изменение этого JSON происходит раз в день - то вообще никакой разницы как делать. Я вот вообще не могу представить почему порядок в JSON может быть важен: в UI компонентах нужно сортировать, а не БД и контроллеры мучить.
psiklop,
Вынося за скобки то, что JSON - это, грубо говоря, словарь ключ/значение, где порядок элементов не должен вообще ни на что влиять,
Правильнее будет делать сортировку в той же функции/процедуре, где вызывается JSON_REMOVE. Если не нравится - можно написать свою функцию, да, возможно она будет работать медленнее, но зато со своей логикой.
Еще можно написать триггер на таблицу BEFORE UPDATE на поле JSON и сортировать значение перед изменением там.
Ну или на клиенте изменить логику и перестать зависеть от сортировки в JSON (либо настроить сортировку там).
Ага, я тоже решил попробовать, но это реально воронка, где со сложностью проекта растет и количество фрейворков. За последние три недели, что я усиленно учу весь этот фронтенд, я познакомился и более/менее освоил:
1. Typescript - больше времени уходит на поиск названия нужного типа. Сам TS простой как две копейки;
2. React-dom - Тоже ничего сложного, за несколько часов учатся основы, потом идет оттачивание на примерах. Разве что с передачей состояний и хуками есть некоторые проблемы, но...
3. React-redux + RTK Query - решает вопрос хранения состояний для приложения. Едва ли не самая сложная часть лично для меня. Даже не в плане теории, тут все легко;
4. React-router - Красивый роутер для построения одностраничных приложений. Умеет многое как обычный браузер, но без лишних запросов к серверу;
5. Ant Design (antd) - Выбрал себе такой UI-фреймворк. Почему он? Да просто первое, что в гугле попалось, честно. Я так понимаю, что они все более-менее одинаковые.
6. faker.js - фреймворк для создания моков. Умеет даже в русский язык.
7. [в планах] json-server - чисто чтобы поднимать легкий api-сервер на том же клиенте.
Самый ад - это заставить все это гармонично взаимодействовать между собой. Опять же повторюсь, в теории ничего сложного нет, сложности начинаются в деталях реализации.
Не знаю, у меня Linux только по работе, поэтому только терминал, только хардкор. Когда увидел впервые UI (у Astra Linux) немного офигел как там все красиво... А потом открыл терминальное окно и продолжил работу. Но видел я там всякие установочники, подозреваю, что это что-то типа батников, "сахар" над баш-скриптом)
Вроде бы там и так по-умолчанию центрируется все в колонках. Может вы поверх чего переопределили?
Гляньте через консоль разработчика что там за классы есть на родительских элементах.
Bermut, к сожалению нет. Я его разворачивал уже настроенным из yaml (который мне предоставляли администраторы) и донастраивал интеграцию с AD по ldap. Примерно знаю что он умеет, но как его настраивать с нуля - увы.
Возможно я что-то и делаю не так, но я создал свой Input, затем HOC, который оборачивает этот Input и превращает его в InputWithSearch (добавляя компонент SearchArea). Смысл в том, что при клике на элемент внутри SearchArea должен перерисовываться и Input. Значения я храню в родителе, в котором отстраиваю InputSearchArea и обновлять его буду через props и, как я теперь понимаю, useEffect.