Ну this.setState в любом случае перерисовку вызовет. Но в целом да, имеется ввиду вызов setState в самом методе, а не в коллбеке. В исходной статье есть такой же комментарий.
Официальная рекомендация из доков по реакту это избегать сайд-эффектов в конструкторе. reactjs.org/docs/react-component.html#constructor
Ну и комментарий Дэна Абрамова на эту тему. Вообще довольно туманное объяснение.
(https://github.com/reactjs/reactjs.org/issues/302)
If it's an async request, it won't be fulfilled by the time the component mounts anyway, regardless of where you fire it. This is because JS is single threaded, and the network request can't «come back» and be handled while we are still rendering. So the difference between firing it earlier and later is often negligible.
You're right that it matters in some rare cases though and for those cases it might make sense to break the recommendation. But you should be extra cautious as state can update before mounting, and if your data depends on state, you might have to refetch in that case. In other words: when in doubt, do it in componentDidMount.
The specific recommendation to avoid side effects in the constructor and Will* lifecycles is related to the changes we are making to allow rendering to be asynchronous and interruptible (in part to support use cases like this better). We are still figuring out the exact semantics of how it should work, so at the moment our recommendations are more conservative. As we use async rendering more in production we will provide a more specific guidance as to where to fire the requests without sacrificing either efficiency or correctness. But for now providing a clear migration path to async rendering (and thus being more conservative in our recommendations) is more important.
К сожалению, эпам практикует политику набрать как можно больше студентов, дотянуть их до джуниоров за 30тр и пытаться запихать их во все проекты. У сотрудников с опытом, на нормальные з/п, промоушен идет с большим скрипом.
Реальный пример — разработчика, который проработал почти 10 лет в компании, 5 из них на позиции d3, был тех. лидом на русскоязычном проекте, заворачивали несколько раз на промоушене (даже без попыток пойти на комитет) потому что, как сказали выше, у него были недостаточные активити и разговорный инглиш.
Да, спасибо, имел ввиду конечно именно 2-й вариант. Т.к. в данном случае получается и вы тратите/планируете свое время и клиент, и резолвить такие ситуации мне кажется не очень приятно.
А были ли неудачные консультации, когда не удавалось решить проблему, либо когда клиент не был доволен консультацией? И если были, то как разруливали такие ситуации?
А почему декларативность вызывает улыбку? Как мне показалось основной фишкой саг является именно попытка перевести разработку на декларативные рельсы с помощью эффектов-объектов (call, put & etc). А yield это всего лишь инструмент для этого.
Не совсем понял, что добавилось за неделю после публикации?
Да, чтобы UseWebpackDevMiddleware заработал из SpaServices, нужно поставить пакет aspnet-webpack и прописать publicPath в конфиге, можно и без path.resolve, все пути зарезолвятся. Но вроде это было в статье.
А почему натуральный логарифм (lnN)? Я так понимаю, что пытались донести мысль, что поиск простым перебором иногда быстрее, чем построение balanced tree и поиск по нему? А на каком участке logN > N?
В первом случае (Any) мы перебираем список, до первого совпадения (ну или вообще наличия элемента в списке), во втором случае (Count) мы полностью перебираем список чтобы посчитать количество.
Нет, в принципе понятен вопрос. Я об этом писал в статье — с добавлением слоя репозиториев у нас появляется возможность отгородиться от ef контекста, и в дальнейшем мы можем подменить реализацию репозитория, например на mock для юнит тестов.
Мне кажется здесь вы немного переусложняете и сваливаете все в одну кучу и обработку pipeline реквеста и асинки. Ничего сверх сложного в асинках нет, с точки зрения их использования, и есть вполне определенный набор кейсов когда их стоит применять, и не совсем понятно как это связано с пайпами.
Ну в данном случае мы ходим в базу за данными и при использовании асинка поток не будет ждать ответа от базы, а вернётся в пул, где сможет заняться чем нибудь полезным, например обработать ещё один реквест.
Промахнулся ответом
Ну this.setState в любом случае перерисовку вызовет. Но в целом да, имеется ввиду вызов setState в самом методе, а не в коллбеке. В исходной статье есть такой же комментарий.
Ну и комментарий Дэна Абрамова на эту тему. Вообще довольно туманное объяснение.
(https://github.com/reactjs/reactjs.org/issues/302)
If it's an async request, it won't be fulfilled by the time the component mounts anyway, regardless of where you fire it. This is because JS is single threaded, and the network request can't «come back» and be handled while we are still rendering. So the difference between firing it earlier and later is often negligible.
You're right that it matters in some rare cases though and for those cases it might make sense to break the recommendation. But you should be extra cautious as state can update before mounting, and if your data depends on state, you might have to refetch in that case. In other words: when in doubt, do it in componentDidMount.
The specific recommendation to avoid side effects in the constructor and Will* lifecycles is related to the changes we are making to allow rendering to be asynchronous and interruptible (in part to support use cases like this better). We are still figuring out the exact semantics of how it should work, so at the moment our recommendations are more conservative. As we use async rendering more in production we will provide a more specific guidance as to where to fire the requests without sacrificing either efficiency or correctness. But for now providing a clear migration path to async rendering (and thus being more conservative in our recommendations) is more important.
Реальный пример — разработчика, который проработал почти 10 лет в компании, 5 из них на позиции d3, был тех. лидом на русскоязычном проекте, заворачивали несколько раз на промоушене (даже без попыток пойти на комитет) потому что, как сказали выше, у него были недостаточные активити и разговорный инглиш.
Да, чтобы UseWebpackDevMiddleware заработал из SpaServices, нужно поставить пакет aspnet-webpack и прописать publicPath в конфиге, можно и без path.resolve, все пути зарезолвятся. Но вроде это было в статье.
Нет, в принципе понятен вопрос. Я об этом писал в статье — с добавлением слоя репозиториев у нас появляется возможность отгородиться от ef контекста, и в дальнейшем мы можем подменить реализацию репозитория, например на mock для юнит тестов.
Мне кажется здесь вы немного переусложняете и сваливаете все в одну кучу и обработку pipeline реквеста и асинки. Ничего сверх сложного в асинках нет, с точки зрения их использования, и есть вполне определенный набор кейсов когда их стоит применять, и не совсем понятно как это связано с пайпами.
Он есть, просто по законам жанра мы его только в части 2. Фронтенд подключаем.