Вот у меня есть вопрос. Сможет ли typescript защитить от неконсистентных данных пришедших с сервера? Можно хоть до посинения типизировать свой код, но однажды с бэка прийдёт строка вместо массива и весь "строготипизированный код" рассыпется как карточный домик. Так и какой тогда смысл от этого полурешения?
Eslint, типы Typescript, Prettier, настройка husky, Storybook и регрессионное тестирование.
Как это говно никуда не денется? Его станет меньше. Куда меньше. Чем больше таких рамок, тем лучше бизнесу. Быстрее фичи, меньше тех. долга, меньше рефакторинга.
Ни один из этих инструментов может не спасти от говнокода от слова совсем. Говонокод — это не «забыл поставить точку с запятой», а сложный, не поддающийся никакому рефакторингу запутанный монолит. И он может проходить все тесты. И es-lint ругаться не будет. И вообще всё будет отлично ровно до того момента, как там надо поправить баг или расширить функционал.
Если вы фигачите загрузку данных и прочий бизнес в компонентах, то ваш код очень сильно пахнет, не зависимо от реакта. И callback-hell был еще задолго до того, как ФП стало набирать популярность: в nodejs, например.
Если этот бизнес будет относиться только к этому конкретному компоненту, зачем его выносить куда-то?
Ах да, и модалки которые в редаксе делаются императивно dispatch(showModal(modalName)) было очень больно делать декларативно. Есть вроде чистый компонент таблицы какой-нибудь и давай его пачкать стейтом isVisible итд.
Пока какой-то крупный проект не изъявит желание перейти на svetle и его опыт не окажется положительным, надежды на svetle как на конкурента тройки крайне малы, ИМХО.
Не переживай. По факту, за день ты сделал довольно большой кусок функционала и писать вещи в стиле «В общем, в React не получилось :(» в таких случаях позволяют себе только ЧСВ-шники 81 лвл-а (которых в front-end каждый второй). Вопрос, надо ли тебе работать в такой команде? Твой затраченный день стоит, как минимум, вежливости со стороны этих js гуру.
Накидал 2 простых примера, которые показыват на практике кейс, который я описал:
1. С редаксом, при клике вызывается экшен и страница перерендеривается, хотя на ней нечему обновляться: codesandbox.io/s/reactredux-70hm1
2. С мобиксом, при клике компонент не перерендеривается, потому что на странице нечему меняться: codesandbox.io/s/mobxreact-s7db5
В идеале конечно такого не должно происходить, я должен был убрать это свойство из mapStateToProps, но в данном случае MobX мне простит ошибку, а Redux — нет.
Если вы ещё раз внимательно почитаете, то увидите, что это не мои домыслы, а краткий перевод статьи с английского. С некоторыми моментами из этого источника я абсолютно согласен. Если вам нравится setState, используйте его на здоровье.
Во-первых, при наличии таких операций как 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!
Как мне кажется, минус в виде замедления скорости разработки, весьма существенный, с точки зрения бизнеса.
Вот у меня есть вопрос. Сможет ли typescript защитить от неконсистентных данных пришедших с сервера? Можно хоть до посинения типизировать свой код, но однажды с бэка прийдёт строка вместо массива и весь "строготипизированный код" рассыпется как карточный домик. Так и какой тогда смысл от этого полурешения?
Ни один из этих инструментов может не спасти от говнокода от слова совсем. Говонокод — это не «забыл поставить точку с запятой», а сложный, не поддающийся никакому рефакторингу запутанный монолит. И он может проходить все тесты. И es-lint ругаться не будет. И вообще всё будет отлично ровно до того момента, как там надо поправить баг или расширить функционал.
Redux-saga-reselect, максимально переиспользуемые компоненты, бесконечные контейнеры-обертки, короче ясно-понятно путешественник из 2016))
Если этот бизнес будет относиться только к этому конкретному компоненту, зачем его выносить куда-то?
И потом в коде можно будет вызывать как
Можно тезисно про mobx, чем не устроил и если если переезжать, то на что?
Звучит как страшный сон)
окей, гугл
Пока какой-то крупный проект не изъявит желание перейти на svetle и его опыт не окажется положительным, надежды на svetle как на конкурента тройки крайне малы, ИМХО.
Можно выводы, стоит ли игра свеч? Насколько быстрее стало рендериться приложение?
1. С редаксом, при клике вызывается экшен и страница перерендеривается, хотя на ней нечему обновляться: codesandbox.io/s/reactredux-70hm1
2. С мобиксом, при клике компонент не перерендеривается, потому что на странице нечему меняться: codesandbox.io/s/mobxreact-s7db5
В идеале конечно такого не должно происходить, я должен был убрать это свойство из mapStateToProps, но в данном случае MobX мне простит ошибку, а Redux — нет.
Только если эти библиотеки написаны для Редакс
Можете подсказать зачем это надо?
Тогда проще писать на ванили.
Не монимаю, почему в данном примере надо использовать map. Я этот массив не собираюсь никак менять.
С этим согласен
Конкретно в данном случае это не нужно, писал в спешке. Такую конструкцию Promise в Promise, я обычно использую когда неизвестно, какой статус от сервера может придти. Это может быть 200 или 400. И то и то нормально. Но если я потом буду ждать ответ в async он упадет, а в случае с двумя промисами у меня есть возможность прописать resolve даже если промис вернется не со статусом ОК.
Оф документация:
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!
Много подобного функционала пришлось сделать?
Даже комментировать не буду
Почему нет? Это вообще мало относится к стейту на фронтенде.