Если класс, то почему в виде функции, сейчас 2023 год.
Если функциональный компонент - то весь его стейт должен хранится в хуках. Если нужно автоматическое обновление (реактивность), то в useState/useReducer. Если обновление вручную - то можно использовать "сырой" useRef. Есть же руководство Roles of hooks.
А вообще, использовать useContext в качестве глобального стора для большого приложения - это дикие проблемы с производительностью (постоянный ререндер на каждый чих).
Лучше использовать локальные сторы, везде, где это возможно. Можно попробовать MobX, если не хватает ванильных способов.
Если нужен реально глобальный (обычно не нужен) стор, то redux toolkit + reselect (для кеширования, чтобы не ререндерить).
В любом случае нужно глубже погрузиться в механизмы работы реакта. Вывести в нескольких местах console.log и увидеть, где происходят лишние ререндеры.
Насчет Java – это такая же модная технология в контексте времени её появления. Sun также пиарила её, как современные компании пиарят свои языки/фреймворки.
Нет в неё ничего особо фундаментально отличного от современных вариантов. Разница лишь в том, что Java выжил. Маркетологи победили. Платформа выстрелила и стала достаточно популярной, чтобы закрепиться на рынке, не смотря на свои минусы.
Сейчас называть её "основополагающей технологией" конечно можно. Но это постзнание. В 90-е это был лишь один из возможных вариантов.
---
jQuery - не просто "модный фреймворк". В свое время он решал вполне конкретные задачи - кроссбраузерное управление DOM-ом. Некоторые из его фишек вошли в стандарт языка. Он оказал большое влияние на сферу веб-разработки.
Со временем он был вытеснен библиотеками и фреймворками более высокого уровня, который инкапсулируют работу с DOM, и обеспечивающие реактивность (KnockoutJS, AngularJS)
CoffeeScript - поделие бекендеров-рубистов, как и SASS, Jade (Pug)/Haml. Кто хотел писать фронты с привычным синтаксисом.
TS почти с рождения позиционировался как надстройка над JS, обеспечивающая типизацию, не меняя сам язык. (Самые чужеродные сейчас его места: namespaces, enums - были еще до этого). Сейчас его синтаксические фишки также просачиваются в стандарт, что не может не радовать.
Это я к чему... Каждая из технологий/платформ решает какую-то боль, занимает свободную нишу. Такой плюрализм - благо, есть что выбрать, есть конкуренция между идеями/подходами, выживет сильнейший.
Боюсь писать статьи на Хабр. Что-то интересное мне, после освоения кажется таким простым и очевидным, что странно об этом писать. А если то, что интересно - то обычно это то, что сейчас изучаю, но кому интересны мысли недоучки, тут же профи разномастные.
А потом читаешь вот такие капитанские статьи и удивляешься. Чего боялся, пипл хавает?
Ожидал чего-то интересного, глубокого. А тут введение в БД на уровне технарского урока...
В статье он и используется. testing-library - это не тестраннер, а просто библиотечка для фейкового рендера и взаимодействия с отрендоренным компонентом. Тесты запускает jest, который поставляется из коробки с CRA (yarn create react-app - это и есть create-react-app)
Я скорее имел в виду, что на го писать в таком стиле не особо принято. Это язык прикладного применения, его прелесть в простоте. Для решения подобных низкоуровневых задач с кучей ручных оптимизаций обычно используют си или плюсы.
Поэтому да, на любом языке это будет выглядеть сложно. Применять именно го для этого странно.
Без живых примеров статья неполная:
https://google-research.github.io/seanet/brain2music/
В правильно организованном скроллинге память подчищается, элементы сверху удаляются
UseCreateAppContext- ну не пишут так, что это?Если класс, то почему в виде функции, сейчас 2023 год.
Если функциональный компонент - то весь его стейт должен хранится в хуках. Если нужно автоматическое обновление (реактивность), то в useState/useReducer. Если обновление вручную - то можно использовать "сырой" useRef. Есть же руководство Roles of hooks.
А вообще, использовать
useContextв качестве глобального стора для большого приложения - это дикие проблемы с производительностью (постоянный ререндер на каждый чих).Лучше использовать локальные сторы, везде, где это возможно. Можно попробовать MobX, если не хватает ванильных способов.
Если нужен реально глобальный (обычно не нужен) стор, то redux toolkit + reselect (для кеширования, чтобы не ререндерить).
В любом случае нужно глубже погрузиться в механизмы работы реакта. Вывести в нескольких местах
console.logи увидеть, где происходят лишние ререндеры.this внутри функционального компонента, это уже за гранью добра и зла.
Чем useRef не угодил?
Так а что за плагин/мод для Minecraft? В ваниле такого нет
Насчет
Java– это такая же модная технология в контексте времени её появления. Sun также пиарила её, как современные компании пиарят свои языки/фреймворки.Нет в неё ничего особо фундаментально отличного от современных вариантов. Разница лишь в том, что
Javaвыжил. Маркетологи победили. Платформа выстрелила и стала достаточно популярной, чтобы закрепиться на рынке, не смотря на свои минусы.Сейчас называть её "основополагающей технологией" конечно можно. Но это постзнание. В 90-е это был лишь один из возможных вариантов.
---
jQuery - не просто "модный фреймворк". В свое время он решал вполне конкретные задачи - кроссбраузерное управление DOM-ом. Некоторые из его фишек вошли в стандарт языка. Он оказал большое влияние на сферу веб-разработки.
Со временем он был вытеснен библиотеками и фреймворками более высокого уровня, который инкапсулируют работу с DOM, и обеспечивающие реактивность (KnockoutJS, AngularJS)
CoffeeScript - поделие бекендеров-рубистов, как и SASS, Jade (Pug)/Haml. Кто хотел писать фронты с привычным синтаксисом.
TS почти с рождения позиционировался как надстройка над JS, обеспечивающая типизацию, не меняя сам язык. (Самые чужеродные сейчас его места: namespaces, enums - были еще до этого). Сейчас его синтаксические фишки также просачиваются в стандарт, что не может не радовать.
Это я к чему... Каждая из технологий/платформ решает какую-то боль, занимает свободную нишу. Такой плюрализм - благо, есть что выбрать, есть конкуренция между идеями/подходами, выживет сильнейший.
Если она отдает страницу с кодом 404, то это ужасный костыль.
Нужен редирект.
Что-то типа https://github.com/rafgraph/spa-github-pages/blob/gh-pages/404.html
Боюсь писать статьи на Хабр. Что-то интересное мне, после освоения кажется таким простым и очевидным, что странно об этом писать. А если то, что интересно - то обычно это то, что сейчас изучаю, но кому интересны мысли недоучки, тут же профи разномастные.
А потом читаешь вот такие капитанские статьи и удивляешься. Чего боялся, пипл хавает?
Ожидал чего-то интересного, глубокого. А тут введение в БД на уровне технарского урока...
Это не звучит, как нерешаемая задача. Просто чуть позже.
Массовость ушла. Сейчас заработать руками сильно сложнее. Ты должен чем-то сильно выделится, чтобы смочь конкурировать с конвейером.
Спасибо большое, не слышал раньше про подобное. Очень поможет в работе.
pictесть в brew:В статье он и используется. testing-library - это не тестраннер, а просто библиотечка для фейкового рендера и взаимодействия с отрендоренным компонентом. Тесты запускает jest, который поставляется из коробки с CRA (yarn create react-app - это и есть create-react-app)
Это пока не релизнулось
А подскажите, плиз, как не сломать типы у метода/функции при использовании декоратора? Допустим, декоратор не меняет сигнатуру.
Я скорее имел в виду, что на го писать в таком стиле не особо принято. Это язык прикладного применения, его прелесть в простоте. Для решения подобных низкоуровневых задач с кучей ручных оптимизаций обычно используют си или плюсы.
Поэтому да, на любом языке это будет выглядеть сложно. Применять именно го для этого странно.
Вот эту портянку на "go" тоже поддерживать сложно.
Если для вас сложно написать `main(iterations, axiom, rules, angle)`, то тут автор уже бессилен
У Jest все очень плохо с поддержкой ESM. Лучше взять vitest, там такой проблемы нет, при этом он максимально похож на jest.
Тоже смутило. Вроде бы все и правильно, несмотря на экспрессию. Но взять и запихнуть картинку в фон... подрывает доверие к остальному.
Потому что у него есть "внутренний дизайнер" )