Статья, как и любой творческий продукт, который вы выпускаете в мир, должна быть ААА уровня. Что такое ААА? В переводе на русский 5++. Мы же играем в игры и смотрим фильмы. И точно знаем, какой продукт высокого уровня, о котором можно сказать: не пожалели времени и денег, приятно смотреть играть и наслаждаться качеством.
Исходя из этого понимания можно выработать критерии, которым должна соответствовать статья ААА-класса. Самое важное, что в ее написание вложены достаточно серьёзные усилия. Будет эта статья революцией в мире IT, или новым описанием существующих знаний — она обязана быть в красивой обёртке.
Здесь немаловажны писательские и издательские (назову их так) приёмы: орфография, оформление, стиль. Проработка этих вопросов поднимет уровень статьи. Далее содержание. Раскрыта ли тема и проработан материал? Не дублирует ли он источники, или, если дублирует, то хотя бы делает это по-новому и лучше?
Хабр - это библиотека знаний, где читатели складывают на полочку важные для себя статьи. И возвращаются к ним не один раз. Пишите вашу статью так, чтобы она, как компьютерная игра или фильм, могла бы стать любимой.
Спасибо, автор, за то, что осветил не такую уж и очевидную утечку производительности компонентов. Весь реакт основан на оптимизации перерендера, поэтому стоит учитывать материал статьи в проектированию кода реакт-компонентов.
Сам я исповедую идею "каждому используемому значению стора свой селектор". Для примера из статьи это выглядит так
Мне не очень нравится идея вставлять везде shallowEqual. По крайней мере не стоит делать это бездумно.
Так же отмечу, что не всегда деструктуризация с useSelector'ом — зло. Очень часто ветки стора проектируются так, чтобы полностью использоваться в компонентах контейнера.
Например, так: // компонент деструктурирует все значения объекта const { isLoading, error, data } = useSelector(someDataSelector);
Здесь обновление компонента не будет лишним, так как используются все данные объекта. Соответственно не нужно создавать для каждого значения отдельный селектор.
Написание кода дешевле его отладки и поддержания. Поэтому документирование легко встраивается в процесс разработки. Проблема остаëтся в том, что сам факт документирования не удешевляет поддержание кода. Точно так же как и написание кода искусство документирования должно развиваться и ему нужно учиться.
Соглашусь, что в разработке этому уделяют малую часть усилий. Получается геометрическая прогрессия проблем: бизнес не умеет объяснить потребность, аналитик пишет неоднозначную документацию и тз, qa и программист интерпретируют эти задания по-разному, тест-кейсы не совпадают с кодом. В последствии вопросы поднимаются до уровня бизнеса и не решаются, пока всё не пройдут к общему знаменателю. Получается документирование даст эффект для отладки только если оно будет единым для всех уровней.
Для поддержания кода достаточно документирования на уровне разработчика. Тогда это должно происходить после готовности кода (отлажено, протестировано, принято). Документировать после каждой строчки кода - эта бездумное удорожание разработки (хотя и небольшое).
Резюмируя рассуждения, скажу, что описанное в статье документирование должно быть отдельной задачей в процессе разработки, что-то вроде тех долга. Опять же, что и насколько подробно документировать, - это бест практис, которые нужно развивать, а не внедрять ради моды.
Спасибо за замечание! Это плохой пример и моя ошибка. В действительности langs определён анализатором как более точный тип, поэтому TypeScript подсвечивает, что string не подходит.
Спасибо, ваше решение значительно лучше выглядит. Мой код навеян реальным кейсом, когда функция находится в составе коллекции мутаторов и её неудобно типизировать всю (иначе понадобилось писать тип всему mutators). Кроме того хотелось бы рассмотреть более редкий случай типизации аргументов.
Спасибо. Ваш посыл следует отнести в коллекцию неприятий TypeScript'а разработчиками.
Если вы не встречаете вложенность функций, то вы пишете очень маленькие приложения, потому что вложенность функций не только НЕ плохая практика, но она используется в реализации различных паттернов проектирования (фасад, стратегия, композиция и скорее всего другие тоже).
Сожалею, что был недостаточно убедителен для вас, призывая использовать TypeScript в крупных приложениях.
В планируемом цикле статей, я буду опираться на особенности типизации React-приложений. В текущей статье рассматриваются общие сведения и нет акцента на конкретной библиотеке.
Дельное замечание. Спасибо! В придумывании примеров преследую мысль, что он должен быть компактным и передавать идею посыла в тексте. Сам понимаю, что иногда это далеко от того, что мы встречаем на практике.
Статья, как и любой творческий продукт, который вы выпускаете в мир, должна быть ААА уровня. Что такое ААА? В переводе на русский 5++. Мы же играем в игры и смотрим фильмы. И точно знаем, какой продукт высокого уровня, о котором можно сказать: не пожалели времени и денег, приятно смотреть играть и наслаждаться качеством.
Исходя из этого понимания можно выработать критерии, которым должна соответствовать статья ААА-класса. Самое важное, что в ее написание вложены достаточно серьёзные усилия. Будет эта статья революцией в мире IT, или новым описанием существующих знаний — она обязана быть в красивой обёртке.
Здесь немаловажны писательские и издательские (назову их так) приёмы: орфография, оформление, стиль. Проработка этих вопросов поднимет уровень статьи. Далее содержание. Раскрыта ли тема и проработан материал? Не дублирует ли он источники, или, если дублирует, то хотя бы делает это по-новому и лучше?
Хабр - это библиотека знаний, где читатели складывают на полочку важные для себя статьи. И возвращаются к ним не один раз. Пишите вашу статью так, чтобы она, как компьютерная игра или фильм, могла бы стать любимой.
Спасибо, автор, за то, что осветил не такую уж и очевидную утечку производительности компонентов. Весь реакт основан на оптимизации перерендера, поэтому стоит учитывать материал статьи в проектированию кода реакт-компонентов.
Сам я исповедую идею "каждому используемому значению стора свой селектор". Для примера из статьи это выглядит так
// файл селекторов
export const counterSelector = (state) => state.counters;
export const firstCounterSelector = (state) => counterSelector(state).firstCounter;
// файл компонента
const firstCounter = useSelector(firstCounterSelector);
Мне не очень нравится идея вставлять везде shallowEqual. По крайней мере не стоит делать это бездумно.
Так же отмечу, что не всегда деструктуризация с useSelector'ом — зло. Очень часто ветки стора проектируются так, чтобы полностью использоваться в компонентах контейнера.
Например, так:
// компонент деструктурирует все значения объектаconst { isLoading, error, data } = useSelector(someDataSelector);
Здесь обновление компонента не будет лишним, так как используются все данные объекта. Соответственно не нужно создавать для каждого значения отдельный селектор.
Написание кода дешевле его отладки и поддержания. Поэтому документирование легко встраивается в процесс разработки. Проблема остаëтся в том, что сам факт документирования не удешевляет поддержание кода. Точно так же как и написание кода искусство документирования должно развиваться и ему нужно учиться.
Соглашусь, что в разработке этому уделяют малую часть усилий. Получается геометрическая прогрессия проблем: бизнес не умеет объяснить потребность, аналитик пишет неоднозначную документацию и тз, qa и программист интерпретируют эти задания по-разному, тест-кейсы не совпадают с кодом. В последствии вопросы поднимаются до уровня бизнеса и не решаются, пока всё не пройдут к общему знаменателю. Получается документирование даст эффект для отладки только если оно будет единым для всех уровней.
Для поддержания кода достаточно документирования на уровне разработчика. Тогда это должно происходить после готовности кода (отлажено, протестировано, принято). Документировать после каждой строчки кода - эта бездумное удорожание разработки (хотя и небольшое).
Резюмируя рассуждения, скажу, что описанное в статье документирование должно быть отдельной задачей в процессе разработки, что-то вроде тех долга. Опять же, что и насколько подробно документировать, - это бест практис, которые нужно развивать, а не внедрять ради моды.
Спасибо за замечание! Это плохой пример и моя ошибка. В действительности langs определён анализатором как более точный тип, поэтому TypeScript подсвечивает, что string не подходит.
Исправил на более практичный пример.
Приятно узнавать, что люди прорабатывают код примеров. В вашем я решил уменьшить размер дженерика
<K extends keyof ConfigType>(param: K, value: ConfigType[K]) => { ... }Спасибо, ваше решение значительно лучше выглядит. Мой код навеян реальным кейсом, когда функция находится в составе коллекции мутаторов и её неудобно типизировать всю (иначе понадобилось писать тип всему mutators). Кроме того хотелось бы рассмотреть более редкий случай типизации аргументов.
Спасибо. Ваш посыл следует отнести в коллекцию неприятий TypeScript'а разработчиками.
Если вы не встречаете вложенность функций, то вы пишете очень маленькие приложения, потому что вложенность функций не только НЕ плохая практика, но она используется в реализации различных паттернов проектирования (фасад, стратегия, композиция и скорее всего другие тоже).
Сожалею, что был недостаточно убедителен для вас, призывая использовать TypeScript в крупных приложениях.
В планируемом цикле статей, я буду опираться на особенности типизации React-приложений. В текущей статье рассматриваются общие сведения и нет акцента на конкретной библиотеке.
Спасибо! Уже приступил.
Надеюсь, даже техническую литературу удастся сделать захватывающей.
Дельное замечание. Спасибо!
В придумывании примеров преследую мысль, что он должен быть компактным и передавать идею посыла в тексте. Сам понимаю, что иногда это далеко от того, что мы встречаем на практике.