• Хороша ли практика мутирования input элемента в React без useState?

    @nokkc
    Получение элементов из DOM через querySelector или getElementBy считается плохой практикой и более идиоматичный для React-а способ - использовать useRef для функциональных / createRef для классовых компонентов.

    А сам подход без использования useState называется uncontrolled components и он достаточно часто используется, основное отличие в данном случае будет в том, что изменение значения в инпуте таким образом не вызывает нового рендера и если от этого значения зависят другие компоненты/эффекты, то и они обновляться/вызываться тоже не будут.
    Ответ написан
    1 комментарий
  • Как перенести информацию с формы на форму в рамках ООП C#?

    Vindicar
    @Vindicar
    RTFM!
    Я не гарантирую, что мой совет будет толковым, но... имхо, требование о приватности полей следует применять умеренно - в первую очередь в классах с нетривиальными методами. Там это позволяет избежать внезапного изменения поля, когда логика работы методов этого не ожидает. В этом случае сеттер свойства может проверить, разрешено ли изменять поле в настоящий момент, и действовать соответственно.

    Разумеется, свойства необходимы, если мы планируем использовать паттерн Наблюдатель(Observer), который в C# реализуется через интерфейсы INotifyPropertyChanged и INotifyPropertyChanging. Если вкратце - если мы хотим, чтобы другие объекты могли подписаться на наш объект, и получать уведомления об изменении его состояния. Тут всё понятно - сеттер свойства будет эти уведомления рассылать.

    Также свойства могут выручить, если мы потом захотим изменить способ хранения данных, но не захотим изменять "внешний вид" (интерфейс) объекта. Тогда в геттер свойства можно будет поместить код, который пересчитает "внутреннее" представление свойства во "внешнее".

    В случае примитивных data transfer objects, как User в твоём примере, я не вижу особенного смысла в использовании свойств ради свойств. Я бы даже сделал его struct, а не class, но это уже пусть спецы по C# меня поправят.

    Вообще, любую рекомендацию по проектированию нужно рассматривать не как заповедь, а как некий размен (trade-off): мы выигрываем в X, но проигрываем в Y (зачастую Y = сложность кода). И, соответственно, смотреть, что для тебя важнее.
    Ответ написан
    Комментировать
  • Как правильно деплоить проект?

    Maksclub
    @Maksclub
    maksfedorov.ru
    по п.1 — делается черех веб-хук GIT
    по п.2 — миграции также как и любые др файлы проекта передаются через GIT на продакшн-сервер
    а вот чтобы их применить — нужно на продакшене их накатить
    по. п3 — пароли индивидуально на сервере задаются, их нельзя пихать в GIT


    Чтобы все автоматизировать по цепочке:
    pushвеб-хукpull+migrate+composer update+npm install

    Можно использовать полноценные инструменты для деплоя:
    Deployer
    Capistrano
    Ответ написан
    Комментировать
  • Где найти живое сообщество программистов (создание cms)?

    riky
    @riky
    Laravel
    сначала прочтите мой ответ отсюда Что почитать об архитектуре CMS?

    то что вы описываете это вписывается в просто "небольшой проект на фреймворке/голом пхп". хотя и называете вы это цмс, у многих создается ощущение что это новый вордпресс, но если посомтреть глубже то любой кто пилит проекты на фреймворках по сути так же делают свою мини цмс как и у вас (конечно не всегда, но если есть панель менеджера/админка то по сути это уже цмс).

    если бы вы писали коробочную цмс, с поддержкой плагинов, тогда вам бы пригодились специфичные знания.
    если вы пишете цмс для себя, своих проектов, вряд ли вы там реализуете систему хуков - то это самый пресамый "обычный проект не пхп", ищите сообщества на фреймворке который используете. предполагаю что еще не используете, поэтому ищите сообщество где люди пишут на голом пхп, если честно мне кажется такие люди живут в своих замкнутых мирках, и особо не коннектятся с внешним миром, иначе бы использовали фреймворки и жили в больших сообществах где вопрос коммюнити был бы сам по себе закрыт, куча документации, бест практикс, готовых модулей и куча других плюшек, при этом их рамки (фреймворки) не так уж и сильно их ограничивают, единственный минус их тоже надо изучать, но зато потом все идет как по маслу.

    из русских создателей коробочных цмс знаю https://phpixie.com/ можете попробовать с его создателем сконнектится, но в коробочных цмс потребности немного другого порядка.

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

    если что - спрашивайте, и конечно же удачи!
    Ответ написан
    9 комментариев
  • Зачем нужны таск менеджеры GULP и GRUNT?

    Tash1moto
    @Tash1moto
    Примерно лет 10 назад, помню было .html .css .js

    Сейчас же, весь этот "девелоперский" антураж в виде фреймворков для фреймворков для запуска фреймворков с кучей json конфигов, с пафосным названием и флэт логотипом : )
    Ответ написан
    1 комментарий