Про множество стейтов, мол нужно делать универсальный - это справедливо только для неуправляемых компонентов т.к, в противном случае, на любое изменение в любом из полей будут ререндериться все поля, которые управляются этим стейтом. Это очень важное уточнение
А какая разница, если стейт родительский, следовательно ререндирится родитель и все его дети (поля). Если не берем в расчет мемоизацию инпутов и оборачивание обработчика в usecallback
@Сергей-у3к8й Инженерные задачи, которые решает TypeScript: 1. Снижение количества ошибок на этапе разработки благодаря статической типизации 2. Улучшение читаемости и сопровождения кода благодаря самодокоментирующим типам 3. Более легкая в реализации модульная архитектура благодаря наличию явных интерфейсов 4. Улучшение автодополнения, рефакторинга и других аспектов разработки благодаря LSP интеграции 5. Явный контроль за изменениями в коде благодаря явному указанию типов 6. Способствование написанию мономорфного кода благодаря строгому соблюдению типов Очевидно многие из перечисленных плюсов могут быть перекрыты отрицательным IQ разработчика, но при правильном использовании - писать код намного приятнее и удобнее, особенно в команде. Довод в сторону валидаторов вообще не понятен. Валидаторы стали популярны как раз во время TypeScript, т.к. помогают в случаях, где JavaScript по своей сути не может вычислить тип данных (ответ с API или ввод пользователя как самый распространенный пример).
@Сергей-у3к8й Инженерные задачи, которые решает TypeScript: 1. Снижение количества ошибок на этапе разработки благодаря статической типизации 2. Улучшение читаемости и сопровождения кода благодаря самодокоментирующим типам 3. Более легкая в реализации модульная архитектура благодаря наличию явных интерфейсов 4. Улучшение автодополнения, рефакторинга и других аспектов разработки благодаря LSP интеграции 5. Явный контроль за изменениями в коде благодаря явному указанию типов 6. Способствование написанию мономорфного кода благодаря строгому соблюдению типов Очевидно многие из перечисленных плюсов могут быть перекрыты отрицательным IQ разработчика, но при правильном использовании - писать код намного приятнее и удобнее. Довод в сторону валидаторов вообще мне не понятен. Валидаторы стали популярны как раз во время TypeScript, т.к. помогают в случаях, где JavaScript по своей сути не может вычислить тип данных (ответ с API или ввод пользователя как самый распространенный пример).
@Сергей-у3к8й после таких слов валидаторы для строгих языков программирования сделали долгую затяжку. Задача валидаторов, внезапно, валидировать, а тса - типизировать. Каким образом ты в типах укажешь, что значение должно быть в ренже от 0 до 100, к примеру? Что строка с эмайлом должна быть валидной? И т.д. > какие инженерные задачи решает ts? Упрощает поддержку приложения. Указывает на ряд ошибок ещё на этапе написания кода, а не в рантайме. Ускоряет внедрение новых разработчиков в проект (особенно джунов/мидлов). Добавляет новые фичи до того, как они появляются в ванильном жс.
@Сергей-у3к8й так ютуб постоянно рандомно комменты удаляет. :/ 1. Абсолютно верный тезис, который никак не противоречит моим словам.) 2. Всё так, только отлов будет именно в рантайме и только когда приложение дойдёт до этой части кода. 3. И это, опять же, не противоречит моим словам.) 4. В своё время опшинал чейнинг и декораторы, к примеру, в тс появились задолго до самого жса. Какими полифилами это можно решить? В целом, ты всё верно пишешь, но ты почему-то считаешь, что упрощение той же поддержки выбирается по принципу Math.max, а не через сложение пользы от подходов/инструментов, улучшающих поддерживаемость. В таком случае и юнит тесты ненужны, они ведь тоже помогают поддерживать приложение. Собственно, типизация и есть своего рода юнит тестирование.
блин, приятель, расскажи про Backend на JS. Будет неплохо просто увидеть то, как это делают другие. Я сейчас учу именно backend (понадобилось для проекта небольшого), поэтому был бы рад увидеть что-то такое
1:00 Не вводите людей в заблуждение, никакого отношения к React и "асинхронному" setState это поведение не имеет. Так работает JavaScript и все другие ЯП с не-ссылочным типом переменных.
Перед тем как сказать это в видео, я специально загуглил, является ли правдой то, что я скажу. Как оказалось -- да. stackoverflow.com/questions/36085726/why-is-setstate-in-reactjs-async-instead-of-sync Вот подтверждение моих слов.
@@gorbatkoff_dev когда функция вызывается у нее в замыкании перменная counter с одним значением, поэтому при вызове setState 3 раза подряд, в переменной counter будет одно и то же значение, которое поменяется только при перерендере компонента, когда функция useState будет вызвана снова и проиниализирует переменную counter с новым значением поэтому и правда, никакого отношения к асинхронности это не имеет, просто внутри этой функции в переменной counter есть значение и мы напрямую его никак не меняем
@gorbatkoff_dev setState безусловно асинхронных (по технологии батчинга). Только какое это имеет отношение к захваченному в замыкании значению не-ссылочной переменной? Точно также это будет работать и с синхронным кодом, и вне React: значение переменной никак не обновиться, без явного присваивания, а в данном случае и присваивание невозможно, потому что переменная объявлена через const.
@@ProJavaScript Вы правы, что асинхронность setState сама по себе не влияет на поведение замыкания и значение переменной, захваченной в нём. Однако я упомянул об асинхронности setState в контексте, чтобы подчеркнуть потенциальные ошибки, которые могут возникнуть, когда программист рассчитывает на немедленное обновление состояния. 👌
Репозиторий с кодом: github.com/gorbatkoff/react_mistakes
Для новичков ролик реально годный
от только вчера практиковался в реакт и не понимал почему по два массива мне прилетает вместо одного. спасибо за контент.
Это было круто!!! Спасибо!
Ты молодец!Очень приятно разговариваешь и хорошо обьясняешь!Продолжай в том же духе
Привет!
Спасибо большое! Приятно слышать)
Про множество стейтов, мол нужно делать универсальный - это справедливо только для неуправляемых компонентов т.к, в противном случае, на любое изменение в любом из полей будут ререндериться все поля, которые управляются этим стейтом. Это очень важное уточнение
А какая разница, если стейт родительский, следовательно ререндирится родитель и все его дети (поля). Если не берем в расчет мемоизацию инпутов и оборачивание обработчика в usecallback
@artmich8132 Мы не можем не брать в расчет мемоизацию если хотим получить нормальный перформанс формы
"Удачи! Только не сдавайся. Хорошо получается."
Классный ролик, спасибо за полезную информацию! 😊
Хорошее изложение материала, продолжай в том же духе!
Юзайте typescript и не будет таких ошибок с формой
@Сергей-у3к8й чувак, ты явно не в себе. если ты пытаешься привести статистику NPM как аргумент, то у TypeScript рост ещё сильнее, к твоему сведению
@Сергей-у3к8й Инженерные задачи, которые решает TypeScript:
1. Снижение количества ошибок на этапе разработки благодаря статической типизации
2. Улучшение читаемости и сопровождения кода благодаря самодокоментирующим типам
3. Более легкая в реализации модульная архитектура благодаря наличию явных интерфейсов
4. Улучшение автодополнения, рефакторинга и других аспектов разработки благодаря LSP интеграции
5. Явный контроль за изменениями в коде благодаря явному указанию типов
6. Способствование написанию мономорфного кода благодаря строгому соблюдению типов
Очевидно многие из перечисленных плюсов могут быть перекрыты отрицательным IQ разработчика, но при правильном использовании - писать код намного приятнее и удобнее, особенно в команде.
Довод в сторону валидаторов вообще не понятен. Валидаторы стали популярны как раз во время TypeScript, т.к. помогают в случаях, где JavaScript по своей сути не может вычислить тип данных (ответ с API или ввод пользователя как самый распространенный пример).
@Сергей-у3к8й Инженерные задачи, которые решает TypeScript:
1. Снижение количества ошибок на этапе разработки благодаря статической типизации
2. Улучшение читаемости и сопровождения кода благодаря самодокоментирующим типам
3. Более легкая в реализации модульная архитектура благодаря наличию явных интерфейсов
4. Улучшение автодополнения, рефакторинга и других аспектов разработки благодаря LSP интеграции
5. Явный контроль за изменениями в коде благодаря явному указанию типов
6. Способствование написанию мономорфного кода благодаря строгому соблюдению типов
Очевидно многие из перечисленных плюсов могут быть перекрыты отрицательным IQ разработчика, но при правильном использовании - писать код намного приятнее и удобнее.
Довод в сторону валидаторов вообще мне не понятен. Валидаторы стали популярны как раз во время TypeScript, т.к. помогают в случаях, где JavaScript по своей сути не может вычислить тип данных (ответ с API или ввод пользователя как самый распространенный пример).
@Сергей-у3к8й после таких слов валидаторы для строгих языков программирования сделали долгую затяжку. Задача валидаторов, внезапно, валидировать, а тса - типизировать. Каким образом ты в типах укажешь, что значение должно быть в ренже от 0 до 100, к примеру? Что строка с эмайлом должна быть валидной? И т.д.
> какие инженерные задачи решает ts?
Упрощает поддержку приложения. Указывает на ряд ошибок ещё на этапе написания кода, а не в рантайме. Ускоряет внедрение новых разработчиков в проект (особенно джунов/мидлов). Добавляет новые фичи до того, как они появляются в ванильном жс.
@Сергей-у3к8й так ютуб постоянно рандомно комменты удаляет. :/
1. Абсолютно верный тезис, который никак не противоречит моим словам.)
2. Всё так, только отлов будет именно в рантайме и только когда приложение дойдёт до этой части кода.
3. И это, опять же, не противоречит моим словам.)
4. В своё время опшинал чейнинг и декораторы, к примеру, в тс появились задолго до самого жса. Какими полифилами это можно решить?
В целом, ты всё верно пишешь, но ты почему-то считаешь, что упрощение той же поддержки выбирается по принципу Math.max, а не через сложение пользы от подходов/инструментов, улучшающих поддерживаемость. В таком случае и юнит тесты ненужны, они ведь тоже помогают поддерживать приложение. Собственно, типизация и есть своего рода юнит тестирование.
блин, приятель, расскажи про Backend на JS. Будет неплохо просто увидеть то, как это делают другие. Я сейчас учу именно backend (понадобилось для проекта небольшого), поэтому был бы рад увидеть что-то такое
кейс на обложке интереснее всех изложенных)
Видимо, просто спер у другого блогера
Спасибо большое!
прием-прием, автор живой? когда некст видео?
А в реакте что-ли нет форм по типу ангуляровских?
1:00 Не вводите людей в заблуждение, никакого отношения к React и "асинхронному" setState это поведение не имеет.
Так работает JavaScript и все другие ЯП с не-ссылочным типом переменных.
Перед тем как сказать это в видео, я специально загуглил, является ли правдой то, что я скажу.
Как оказалось -- да.
stackoverflow.com/questions/36085726/why-is-setstate-in-reactjs-async-instead-of-sync
Вот подтверждение моих слов.
@@gorbatkoff_dev когда функция вызывается у нее в замыкании перменная counter с одним значением, поэтому при вызове setState 3 раза подряд, в переменной counter будет одно и то же значение, которое поменяется только при перерендере компонента, когда функция useState будет вызвана снова и проиниализирует переменную counter с новым значением
поэтому и правда, никакого отношения к асинхронности это не имеет, просто внутри этой функции в переменной counter есть значение и мы напрямую его никак не меняем
@gorbatkoff_dev setState безусловно асинхронных (по технологии батчинга). Только какое это имеет отношение к захваченному в замыкании значению не-ссылочной переменной?
Точно также это будет работать и с синхронным кодом, и вне React: значение переменной никак не обновиться, без явного присваивания, а в данном случае и присваивание невозможно, потому что переменная объявлена через const.
@@ProJavaScript Вы правы, что асинхронность setState сама по себе не влияет на поведение замыкания и значение переменной, захваченной в нём.
Однако я упомянул об асинхронности setState в контексте, чтобы подчеркнуть потенциальные ошибки, которые могут возникнуть, когда программист рассчитывает на немедленное обновление состояния. 👌
А где пример из превью видео?
Привет!)
Превью сделано для привлечения внимания к теме, а в видео я объясняю похожие случаи и ошибки. Надеюсь, содержание было полезным)
Крутой ролик
крутое видео! Вижу, что ты тоже реактер. Может вместе будем сайт писать? мне просто помощник нужен, а то я не очень опытный, да и времени нет
Не понял, а какой видос нужно посмотреть, чтобы понять почему там логи 2 раза вызываются ?)
Привет!
Держи ссылку на видос) 🙏
th-cam.com/video/BI5ovonBHJ0/w-d-xo.html
Какого хрена на обложке ты пишешь не делай так? Делал и буду делать