• Стоит ли автоматически оборачивать в try catch?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Если это объективно улучшит ваш код - то стоит. Если нет, то не стоит.
    Сам по себе такой прием ничего плохого не несет.
    Но если у вас это все в мидлварах, то проще написать один обработчик ошибок который будет ловить все исключения в мидлварах, добавить его в express аппу, и остальному коду разрешить бросать исключения.
    Ответ написан
    3 комментария
  • Подход "Сервис - Репозиторий" в express?

    @Nc_Soft
    Ваш Post.create({ title: body.title, ...}) итак кинет ексепшен (я так понимаю используется sequelize), проверка if(!result) мне кажется избыточной.
    Я тоже агрегирую статичные функции в класс, так не надо писать кучу module.exports
    Транзакции удобнее делать колбеком, так не надо писать rollback и коммит
    С учетом всего вышесказанного получается PostRepository не нужен, с этим справляется модель.
    Ответ написан
    1 комментарий
  • Mobile First в реакт, как организовать?

    Raxen
    @Raxen
    TechLead Frontend Developer, Beeline
    Вам пригодится react-responsive, пожалуйста.
    Ответ написан
    Комментировать
  • Пользовательские хуки или HOC, когда что использовать?

    @luzianin999
    Классовый компонент => HOC, функциональный => хук
    Ответ написан
    1 комментарий
  • Пользовательские хуки или HOC, когда что использовать?

    Robur
    @Robur
    Знаю больше чем это необходимо
    В каких случаях использовать HOC, а в каких пользовательские хуки?

    Если вы перешли на разработку с использованием хуков и хотите единообразия в коде - то всегда хуки. HOC не нужен вообще.

    Если вам нравится/хочется запилить HOC и некоторая каша в коде вас не смущает - делайте HOC.

    В плане функционала и возможностей они взаимозаменяемы.
    С точки зрения чистоты кода конечно при переходе на хуки от HOC надо отказаться - это просто лишний концепт в приложении.
    Ответ написан
    4 комментария
  • Как организовать компонент "Страница категории"?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Раз уж просили:
    1. Что значит "правильно"? нормальноу вас организовано
    2. называть что-то контейнером или нет - это ваше личное дело, в зависимости от того как вы для себя решите код организовать. каких-то требований и общепринятых стандартов которые нельзя нарушать по этому поводу нет.
    3. в общем случае - лучше загружать данные где-то в одном месте. Но бывают и исключения, дурно ли это у вас или нет здесь - я не знаю. Может так меньше запросов на сервер или лучше код, - тогда не дурно. Если вы просто не знали как код организовать и скопипастили загрузку в два места - то дурно.
    4. можно
    х. если нет нужды в редаксе, то да, он и не нужен. Если код начнет усложняться - какой-то стейт приложения потребуется.

    ПС. можете посмотреть на apollo-client, у него внутри редакс вроде. Но подобного плана библиотеки писать вам вряд ли придется.
    Ответ написан
    3 комментария
  • Как получать информацию страницы REST API?

    FinGanapre
    @FinGanapre
    В целом, в rest стараются делать такие ендпоинты, которые нужны приложению на клиентской стороне. Но, в данном случае я бы обратил внимание на то, что товаров в конкретной категории может быть очень много и вы будете делить их по 10 / 20 / 50 и т.д. При этом, информацию о самой категории логичнее получить один раз. Т. е., я бы поделил это на два запроса. И выглядеть это будет намного логичнее, когда вам где-то понадобиться получить только список товаров определённой категории.
    Ответ написан
    Комментировать
  • Когда SPA, а когда MPA?

    Sanes
    @Sanes
    От разработчиков зависит. Как посчитают нужным, так и сделают. Где-то компетенций не хватает, где-то необосновано дорого получается. А где-то дизайнер интерфейсов так решил.
    Это всегда компромисс.
    Ответ написан
    Комментировать
  • Когда SPA, а когда MPA?

    bootd
    @bootd
    Гугли и ты откроешь врата знаний!
    Гуглил, читал, почти в каждой статье все упирается в SEO.
    это вообще тут не причём, юзаем SSR и всё.

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

    Так же, выбором в сторону SPA может быть большое кол-во логики, которое вынесено на клиент или большое кол-во интерфейсов, которые связаны между собой. Или это сайт как яндекс музыка или вк, когда музыка играет, даже если вы переходите по страницам. Потому что страница не обновляется. А клиент получает лишь то, что ему действительно нужно, не обновляя страницу целиком. Это позволяет снизить нагрузку на сервер, но лишь, когда аудитория в много много человек.

    Выбором может быть просто любовь команды разрабов к тому или иному фреймворку/стеку. На мой взгляд, это тоже нормально. Пишут люди на React или бек на php yii2, с чего они должны взять и перейти на другой стек, когда пришёл новый заказ? Им удобно, им нравятся эти инструменты, процессы налажены, код стайл сформирован, готовые для их работы модули или сниппеты уже написаны, профит. Это единство кодовой базы, что позволит достаточно быстро перейти с одного проекта на другой, ведь везде будет одинаковый стек.

    Если это просто фриланс сайт на 1 раз, сверстал, натянул на вп(любую другую похожую CMS) и отдал(и т.п.), то тогда не нужны никакие SPA.
    А если у вас команда разработчиков, то на мой взгляд SPA подойдёт куда лучше.

    P.S. В нашей компании, мы 2.5 года назад полностью перешли на vue(nuxt.js) и не пожалели, выросло кпд и переход с одного проекта на другой стал гораздо проще. А старт новых проектов был отлажен, путём написания уже готовых модулей, которые были выделены в процессе написания прошлых проектов. Что позволило в конечном итоге снизить стоимость(пускай и не так много), но снизить время на написание одних и тех же модулей.
    Ответ написан
    Комментировать
  • Когда использовать Function Declaration, а когда Function Expression?

    Нет общих причин использовать тот или иной синтаксис для объявления функций.
    В Реакт стрелочные функции используются для того, чтобы в обработчике событий не потерять контекст и не использовать bind. Если к контексту внутри функции не обращаются или нет шанса его потерять - рекомендуется не использовать стрелочные функции.
    Это один из примеров, серебрянной пули нет, руководствуйтесь здравым смыслом и style guide конкретного фреймвока или конкретного проекта.
    Ответ написан
    3 комментария
  • В какую область ИТ можно перейти с опытом в классическом телекоме?

    approximate_solution
    @approximate_solution
    JS Developer. Angular\React\Vue\Ember
    облачные сервисы, ML, data analitics.

    Каким образом "тянуть провода" ростелеком как-то связуется с тем, что Вы описали выше?
    По факту - если у Вас есть желание прыгать в IT, не важно где вы работали до этого. Как правило смотрят не на прошлое место работы(если это конечно не Google, и не целевая специальность), а на знания, и практические навыки. Если Ваши знания это - обжать провода, и уметь конфигурировать свитч(работник средней руки телекома), это никаким образом не сыграет Вам на руку в data analitics.
    Вывод: изучите профессию, подтяните скилы, и вливайтесь в любую сферу которая Вам нравится.
    Ответ написан
    5 комментариев
  • Чем преобразовать текст в речь (бесплатные проекты, сервисы)?

    Как на счет SpeechSynthesisUtterance в JS ?

    let synth = window.speechSynthesis;
    
        document.onclick = function(){
          let speech = new SpeechSynthesisUtterance();
          speech.lang = 'ru-RU'; // язык
          speech.rate = 1.5; // скорость
          speech.text = 'Текст для озвучки';
          synth.speak(speech);
        }
    Ответ написан
    1 комментарий
  • Как устроена андроид разработка по аналогии с веб фронтенд разработкой?

    @AntonKrygin
    1. Нативная андроид разработка ведется в основном с использованием java(kotlin), иногда c++. Обычно интерфейс описывается в виде xml-файлов, которые отдаленно напоминают html, также есть возможность отдельно описывать стили/темы также в xml-файлах.
    2. Да. Логика - в java-классах, структура и стили - в xml-файлах.
    3. Как по мне, так общего у нативной андроид-разработки и веба очень мало.

    Дам совет, который вы не просили. Если вы хотите войти в мир мобильной разработки из веба как можно проще и быстрее, не выбирайте нативную разработку. Возьмите кроссплатформенный фреймворк типа Flutter или React Native - что вам ближе, вариантов сейчас много.
    Сам пересел на Flutter после нативной андроид разработки, впечатления можно описать фразой "а так можно было?". React Native и другие не пробовал.
    Главный плюс новых кроссплатформенных фреймворков - высокая абстракция от платформы. Для меня самая боль нативной разработки была в управлении жизненным циклом приложения. Во Flutter все намного проще. Если вам когда-нибудь перестанет хватать произодительности, всегда можно написать что-то на нативе и дергать из фреймворка типа Flutter.
    В общем, не ради холивара, не хотел никого оскорбить, просто совет.
    Ответ написан
    4 комментария
  • Стоит ли разделять 1 общий запрос на несколько маленьких?

    Stalker_RED
    @Stalker_RED
    Хочешь красивый-гибкий - дроби.
    Хочешь производительный-быстрый - не дроби.
    Ответ написан
    Комментировать
  • Стоит ли разделять 1 общий запрос на несколько маленьких?

    @AndryG
    А если добавить перечень частей, которые просят вернуть?
    дай мне:
    * автомобиль
    * запчасти
    * сервисные центры
    * утилизация
    * все отделы
    Юзер может выбрать, какие данные запросить в одном запросе: один, два или всё
    Ответ написан
    Комментировать
  • Стоит ли разделять 1 общий запрос на несколько маленьких?

    trapwalker
    @trapwalker
    Программист, энтузиаст
    Сделайте уровни абстракции, чтобы "копии" контроллеров были прозрачными и соответствовали принципу DRY. Тогда у вас и быстро всё будет и гибко. Будут и отдельные методы для получения запчастей и комбинированные для скорости.
    Однако помните, что преждевременная оптимизация - зло. Сделайте MVP и держите в голове, что, возможно, придётся вводить уровни абстракции и делать отдельные контроллеры для скорости. Не исключена вероятность, что скорости вам хватит и так, а оптимизация на ранних этапах отъест лишние деньги и время, которые можно было потратить на полезные фичи, чтобы соблазнить инвесторов.
    Ответ написан
    1 комментарий
  • Где загрузить начальные данные для состояния React + Redux?

    @iordania
    Вполне норм подход! Все запросы вы должны отпровлять в Action. Reducer же должен принимать тип экшона и пэйлоад который вы диспатчите в Action. Reducer должен быть чистой функцией
    Ответ написан
    1 комментарий
  • Где загрузить начальные данные для состояния React + Redux?

    profesor08
    @profesor08
    Можно сделать иначе, сначала получаешь данные, потом инициализируешь ими свое хранилище, потом инициализируешь реакт.
    Ответ написан
    3 комментария
  • Как вы разрабатываете свои приложения?

    trofProg
    @trofProg
    Fullstack developer (Typescript / Python)
    Очень небольшое количество людей может в одиночку делать продукт. У меня такая же проблема. Решение заключается в том, чтобы найти человека с кем бы можно было обсудить твои решения и получить подтверждение того, что все круто и можно реализовывать. Тебе не хватает одобрения от третьих лиц возможно
    Ответ написан
    4 комментария
  • Как использовать composer в модуле приложения, где уже есть composer?

    DevMan
    @DevMan
    это реализуется настолько, насколько хватит вашей извращённой фантазии.

    вы либо пользуетесь композером и всё лежит в его папке. либо ваш модуль (если он офигеть какой классный) имеет собственный vendor, либо вы конкретно костылите.
    Ответ написан
    6 комментариев