• Mr. Stylin
    0

    По поводу мобилок хороший аргумент, по поводу кита не совсем согласен. На проекте может быть штук 7 разных шрифтов, это значит неизбежно появление small, superSmall, extraSmall и тд.

  • Mr. Stylin
    +2

    Всё пытаюсь понять чем же запись p fontSize=15 более ужасна и менее понятна, чем Title size="small"

  • Вопросы для собеседования по хукам React
    +4
    Что увидел? Всё правильно написал сначала, надо делать clearInterval, ни в классовом компоненте ни в функциональном этого нет.
  • Использование Effector в стеке React + TypeScript
    +9
    Сложилось впечатление, что девиз эффектора «Я могу делать то же самое, только сложнее». Видно я не модный и не молодёжный :)
  • REACT + JEST = TDD ❤️
    0

    Как мне кажется, минус в виде замедления скорости разработки, весьма существенный, с точки зрения бизнеса.

  • React — Используйте стандартные пропсы для потока данных
    0

    Вот у меня есть вопрос. Сможет ли typescript защитить от неконсистентных данных пришедших с сервера? Можно хоть до посинения типизировать свой код, но однажды с бэка прийдёт строка вместо массива и весь "строготипизированный код" рассыпется как карточный домик. Так и какой тогда смысл от этого полурешения?

  • 6 рекомендаций по разработке масштабируемых React-проектов
    0
    Eslint, типы Typescript, Prettier, настройка husky, Storybook и регрессионное тестирование.

    Как это говно никуда не денется? Его станет меньше. Куда меньше. Чем больше таких рамок, тем лучше бизнесу. Быстрее фичи, меньше тех. долга, меньше рефакторинга.

    Ни один из этих инструментов может не спасти от говнокода от слова совсем. Говонокод — это не «забыл поставить точку с запятой», а сложный, не поддающийся никакому рефакторингу запутанный монолит. И он может проходить все тесты. И es-lint ругаться не будет. И вообще всё будет отлично ровно до того момента, как там надо поправить баг или расширить функционал.
  • Архитектура приложения React Redux
    +1

    Redux-saga-reselect, максимально переиспользуемые компоненты, бесконечные контейнеры-обертки, короче ясно-понятно путешественник из 2016))

  • 5 типичных ошибок при создании React компонентов (с хуками) в 2020 году
    0
    Если вы фигачите загрузку данных и прочий бизнес в компонентах, то ваш код очень сильно пахнет, не зависимо от реакта. И callback-hell был еще задолго до того, как ФП стало набирать популярность: в nodejs, например.

    Если этот бизнес будет относиться только к этому конкретному компоненту, зачем его выносить куда-то?
  • Как управлять состоянием React приложения без сторонних библиотек
    +1
    Ах да, и модалки которые в редаксе делаются императивно dispatch(showModal(modalName)) было очень больно делать декларативно. Есть вроде чистый компонент таблицы какой-нибудь и давай его пачкать стейтом isVisible итд.


    import React from 'react';
    import ReactDOM from 'react-dom';
    
    const confirmRoot = document.createElement('div');
    const body = document.querySelector('body');
    body.appendChild(confirmRoot);
    
    const customConfirm = DialogContent =>
      new Promise(res => {
        const giveAnswer = answer => {
          ReactDOM.unmountComponentAtNode(confirmRoot);
          res(answer);
        };
        ReactDOM.render(<DialogContent giveAnswer={giveAnswer} />, confirmRoot);
      });
    
    export default customConfirm;


    И потом в коде можно будет вызывать как

    customConfirm(Component)/await customConfirm(Component)


  • Как мы разрабатывали поле ввода новых сообщений в нашем мессенджере (Gem4me)
    +1

    Можно тезисно про mobx, чем не устроил и если если переезжать, то на что?

  • Cypress + Storybook. Хранение тестового сценария, данных и рендеринг компонента в одном месте
    0
    1000 переиспользуемых компонентов

    Звучит как страшный сон)
  • Redux против MobX без путаницы
    +1
    В то время как в Redux у вас есть установленная церемония настройки вещей, MobX менее самоуверен.

    окей, гугл
  • Пришло ли время забыть о React и перейти на Svelte?
    –3

    Пока какой-то крупный проект не изъявит желание перейти на svetle и его опыт не окажется положительным, надежды на svetle как на конкурента тройки крайне малы, ИМХО.

  • Server Side Rendering для React App на Express.js
    0

    Можно выводы, стоит ли игра свеч? Насколько быстрее стало рендериться приложение?

  • Опыт разработки тестового задания на React для Aviasales
    0
    Не переживай. По факту, за день ты сделал довольно большой кусок функционала и писать вещи в стиле «В общем, в React не получилось :(» в таких случаях позволяют себе только ЧСВ-шники 81 лвл-а (которых в front-end каждый второй). Вопрос, надо ли тебе работать в такой команде? Твой затраченный день стоит, как минимум, вежливости со стороны этих js гуру.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Накидал 2 простых примера, которые показыват на практике кейс, который я описал:
    1. С редаксом, при клике вызывается экшен и страница перерендеривается, хотя на ней нечему обновляться: codesandbox.io/s/reactredux-70hm1
    2. С мобиксом, при клике компонент не перерендеривается, потому что на странице нечему меняться: codesandbox.io/s/mobxreact-s7db5

    В идеале конечно такого не должно происходить, я должен был убрать это свойство из mapStateToProps, но в данном случае MobX мне простит ошибку, а Redux — нет.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Если вы ещё раз внимательно почитаете, то увидите, что это не мои домыслы, а краткий перевод статьи с английского. С некоторыми моментами из этого источника я абсолютно согласен. Если вам нравится setState, используйте его на здоровье.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Большинство проектов и библиотек работают с Redux — проще интергрироваться при необходимости.

    Только если эти библиотеки написаны для Редакс
    Redux создает каждый раз новый экземпляр stor'a — поэтому можно отследить в reduxDevTools историю изменений stor'а.

    Можете подсказать зачем это надо?
    Redux — функциональщина которая понятно как работает, mobx — какая то магия.

    Тогда проще писать на ванили.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    –3
    Во-первых, при наличии таких операций как getUser, элементы хранить надо в Map, а не в массиве.

    Не монимаю, почему в данном примере надо использовать map. Я этот массив не собираюсь никак менять.

    Во-вторых, если fetchList — единственная мутирующая операция, то имеет смысл использовать observable.ref вместо observable.

    С этим согласен

    В-третьих, откуда вы взяли этот паттерн с оборачиванием Promise в другой Promise?! Зачем вообще внешний Promise нужен?


    Конкретно в данном случае это не нужно, писал в спешке. Такую конструкцию Promise в Promise, я обычно использую когда неизвестно, какой статус от сервера может придти. Это может быть 200 или 400. И то и то нормально. Но если я потом буду ждать ответ в async он упадет, а в случае с двумя промисами у меня есть возможность прописать resolve даже если промис вернется не со статусом ОК.

    В-четвертых, action не действует на асинхронные продолжения. Конкретно в приведенном вами коде декоратор action бессмысленный.


    Оф документация:

    The action wrapper / decorator only affects the currently running function, not functions that are scheduled (but not invoked) by the current function! This means that if you have a setTimeout, promise.then or async construction, and in that callback some more state is changed, those callbacks should be wrapped in action as well!

  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Это всё зависит от задачи. В моём последнем проекте я организовал стор на MobX так: ссылка на коммент
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Анду/реду;

    Много подобного функционала пришлось сделать?
    Оффлайн мод; Лоадинг стейты; Централизованная обработка ошибок;

    Даже комментировать не буду
    Канкарент модификации состояний (реализация полноценной асинхронной работы с приложением с участием нескольких пользователей);

    Почему нет? Это вообще мало относится к стейту на фронтенде.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Я не пытаюсь вам что-либо навязать, как по мне, хоть на jquery всё пишите, главное, чтобы мы ни в каком проекте не пересеклись
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Почему — я выше подробно расписал. Голый MobX вы можете сравнить, скажем, с голым Svelte, с react hooks, с knockout и пр.

    Я сравниваю преимущества MobX по сравнению с flux — архитектурой (на примере Redux) в приложениях на React. Оба они по сути конкуренты — и то и другое представляется как возможность организовать хранение данных на фронте. Статья так и называется — почему вы должны использовать MobX вместо Redux. Почему я должен сравнивать MobX с Svetle, Knockout и react hooks я, честно говоря не очень понимаю.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    А текущая статья это как 99% статей про Svelte где вам показывают 2+2 и спрашивают, а чего это вы все ещё не пишете на Svelte? :)

    Вы предлагаете мне сделать аналог фейсбука, чтобы вы смогли оценить преимущества MobX?
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    +3
    Если реакт использовать для чисто серверного рендеринга где все страницы рендерится на сервере

    Тогда и реакт не нужен
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    0
    Согласен, такой подход позволяет убрать всю бизнес логику из компонентов, оставить в них только логику отображения. Тут тоже несколько плюсов:
    1. Компоненты становятся меньше и соответственно более понятно, что в них происходит
    2. Если в компонентах фигачить бизнес-логику, она будет пересчитываться каждый раз, когда этот компонент будет перерендериваться, а это минус к производительности
    3. Компоненты становятся менее зависимыми от данных == больше шанс их переиспользовать.
  • 5 причин, почему вы должны забыть о Redux в приложениях на React
    –2
    Можно создать отдельный класс в котором будут данные и отдельный класс в котором будут методы. Лично я предпочитаю хранить и данные и методы для этих данных в одном классе:
    class Users {
       @observable list = [];
       @action getUser = (id) =>{
           return this.usersList.filter(user => return {user.id == id})
       }
       @action fetchList = () => {
           return new Promise((resolve, reject) => 
                    api.get('someUrl')
                        .then(res=> {
                              this.list = res.data;
                              resolve()
                         })
                       .catch(e => reject(e))
           )
       }
    }
    

    Такой подход позволяет не просто хранить данные, а создавать сущности и потом в компоненте сразу понятно, что происходит:
    try {
        await Users.fetchList();
        Users.getUser(id);
    } catch(e){
        console.log(e)
    }