В других языках тоже самое. Если Вы поюзаете int32, то в других языках получите ещё больший бред.
Ну ок, Вы скажите, что можно поюзать не int32, а int64. Но и в JS тоже можно поюзать BigInt. Конечно, он работает медленнее (хотя теоретически движок вполне может пооптимайзить до int64), но диапазон от int55 до int64 нужен крайне редко в реальном коде.
ЧЯДНТ? dotnetfiddle.net/gi2MBL — вполне адекватный результат показывает. Из-за того, что каст работает неожиданным образом, каст нужно делать явно.
Формулировки про диапазон от int55 до int64 не очень понятны.
В большинстве языков при переполнении просто в минус уходит число (циклично), а не происходит падение. Но в целом, возможно, да, адекватнее было бы падать. Можно занести в недостатки JS, согласен.
Это не так. Да, переполнение зачастую работает именно таким образом. Но переполнение случается при манипулировании числами (сложение, вычитание, умножение). Мы же говорим о случае «число просто ввели» и «число пытаются распарсить из строки». Переполнение тут совершеннно не применимо.
parseInt парсит int, но отдаёт в стандартных числах, у которых может быть ограничено точность. Но я Вас удивлю: во всех языках ограничена точность у int.
С другой стороны, снова соглашусь, что в таких случаях, наверное, логичнее было бы падать, а не округлять.
dotnetfiddle.net/PIrWZK — и вуаля, опять здоровое поведение. Хотя вы уже согласились, это было ни к чему
Я не указывал те недостатки, которые уже исправили. Безусловно, раньше в JS было намного больше недостатков.
С наличием недостатка согласились и проехали. Но исходное утверждение у вас было в том, что стандартная библиотека js достаточно мощная. Претензия про то, что добрую половину lodash нужно было бы впихнуть в стандартную библиотеку — она сохраняется. Это ни в коей мере не похоже на богатую стандартную библиотеку.
Среди скриптовых языков, вероятно, это самый быстрый и с самым низким потреблением памяти язык.
Ну если сравнивать со скриптовиками и при учете слова «вероятно», то вероятно вы правы. Хотя обычно делают бенчмарки на реалистичных случаях.
Можно сравнить с PHP — PHP, вроде, где-то в 10–20 раз медленнее без учёта отсутствия асинхронности. С учётом отсутствия асинхронности PHP может быть до 1000 раз медленнее (из-за плохой архитектуры), особенно при обработке запросов пользователя с сервера.
PHP вообще удобный язык для сравнения. Можно вообще половину языков оправдать существованием PHP, особенно его старых версий.
Вы превосходно сформулировали суть проблемы. Потому что не очень прикольно превращать js в нормальный язык, js сохраняет странное поведение и его по-прежнему не любят.
Не могли бы вы развернуть вашу мысль? А то я что-то не могу понять о чём вы спрашиваете.
Представьте, что у вас есть функция copyFile принимающая только два параметра: путь ко входному файлу и путь к выходному файлу. И представьте, что эта функция изредка удаляет входной файл. В документации об этом упомянуто. С моей точки зрения — это явный косяк того, кто написал эту функцию; а мне как конечному пользователю — лучше использовать какую-то другую функцию. А с вашей точки зрения?
Если вы считаете такое поведение copyFile неадекватным, то в чем кардинальная разница этого случая и поведения var?
На сколько я понимаю, контринтуитивными вы считаете моменты в которых вы ожидали одно поведение, а получили другое. Видимо я в таких ситуациях реагирую не «что за дурацкое поведение!», а «почему так? А! Вон оно что!» и поэтому не чувствую никакой контринтуитивности.
Нет, контринтуитивность — это не просто расхождение актуального с ожидаемым. Контринтуитивность — это когда после того как вы узнали правильный ответ вы восклицаете «чезанах? как это может быть правдой?»; это когда приходится прилагать осознанные усилия, чтобы помнить о таком поведении. Например, парадокс Монти-Холла принадлежит к такому классу вещей.
Ну так не используйте var в TS, и дело с концом! Серьёзно, если вам не понятно как оно работает и нет желания разбираться, просто не используйте. Можете только let использовать, поскольку, подозреваю, const для вас будет работать контринтуитивно. Правда тогда вам нужно понять, что такое «блочная область видимости»… Честно говоря не знаю, как оно в C#. Наверное тоже контринтуитивно может оказаться…
Снобизм не идет к лицу.
А C# не позволяет в ноги стрелять? В самом деле?
C# спроектирован не на отъебись, и позволяет стрелять в ноги только в unsafe. В остальном в C# сложность использования связана со сложностью задачи. В основном. Моменты есть, но их куда меньше, чем у js.
А почему нет? Серьёзно спрашиваю. Ведь удобно же.
Удобно — это когда не приходится использовать сторонние инструменты, чтобы избежать проблем. При прочих равных остается только линтер.
Почему хотелось бы избежать — потому что каждое линт-правило вносит дополнительную задержку во время компиляции. А дурацкого поведения много. В итоге получается, что задержка существенная.
Во первых в использовании stack overflow ничего позорного нет — ни кто не знает абсолютно всё, а во вторых, если не для падения с ошибкой в случае использования устаревшего кода, то зачем ещё вам «langVersion:es7» нужен?
Ну очень плохо, что вы предполагаете только такой сценарий. Сценарий таков: у меня два основных языка — TypeScript и C#. При переключении между ними я иногда использую var внутри TS по-привычке.
Код со strict-режимом вполне нормально сосуществует с кодом без strict-режима. Так отчего же для директивы «langVersion:es7» нельзя добиться такого же поведения?
С чего бы? Потому, что вам не нравится? Вы на каком языке пишете? Что-то я пропустил, похоже, язык, на котором любой человек может сесть и без изучения основ начать програмировать.
Позвольте спросить, а ваша аргументация может оправдать самодетонацию компьютера при запуске js-кода? Если не может, то поделитесь, в чем разница. Вы понимаете разницу между «этому нужно обучаться» и «это контринтуитивное поведение»?
Какие люди? Кто-то всё ещё предпочитает. Помнится, какое-то время назад в циклах var показывам лучшую скорость, сейчас не знаю, возможно уже нет.
Разные люди, которые используют язык. Осведомленное большинство.
А чем его наличие вам мешает, если вы его не используете? Вам чисто для того, что-бы скопированное со stack overflow с ошибкой падало? Может позже, если будет массовый запрос, что-то подобное введут. Пока можно линтер настроить, если прям совсем невмоготу.
Меня например сейчас это волнует только в контексте необходимости переключаться между C# и TS, у которых var имеет совершенно различное поведение. Но концептуально меня волнует то, что managed язык предоставляет чудесное средство выстрелить в ногу. Линтер — это замечательный костыль, но хотелось как-бы без костылей.
А еще можно настроить линтер, чтобы не вызывать sort() и кучу еще дебильных моментов, которые не должны быть проблемой по дефолту.
Вам чисто для того, что-бы скопированное со stack overflow с ошибкой падало?
RTFM-синдром преобразовывается в мой-оппонент-копипастер-синдром.
В приведенном коде действительно всё правильно и понятно для тех, кто знает как оно работает. Но поскольку понятно, не всегда значит удобно, да и тех, кто не знает, как оно работает очень много
Как я и говорил, стокгольмский синдром вкупе с RTFM.
«Правильно и понятно для тех, кто знает как оно работает» — это вообще не критерий, достойный упоминания. И уж тем более его нельзя использовать в языковом сраче. Правильный критерий «при прочих равных я хотел бы, чтобы язык программирования работал так, а не иначе». Если люди не предпочитают добровольно использовать var (вкупе с осознанием его реального поведения) чаще чем let/const, то это значит, что var — ошибка. Косякам всегда можно найти объяснение, но это все равно останется косяком.
И нет, обратная совместимость — не аргумент. В конечном счете, «use strict» же ломал существующее поведение, не ломая его. Что мешало сделать нормальную директиву «langVersion:es7», которая отрубает var и прочий мусор?
Нууу… кое что у нас есть. Только не смейтесь, плз.
Это очень хорошо, что такие вещи появляются. Но caniuse говорит, что bigint доступен для аудитории в 71%, тогда как даже WeakMap доступен для 94%. Буду рад использовать эту вещь позже, но не сейчас.
Всё же, мне кажется, что споры о default comparator в одной из JS функций явно не стоят этого срача
Если кто-то считает, что неожиданное поведение хоть в какой-то мере адекватно; то это явно стоит срача.
Взять тот же PHP, там половина стандартной библиотеки вызывает острую степень недоумения. Почему не устраивают вселенских срачей про каждую из них
А криминал например в isNaN, про который мало кто вспоминает
Может быть дело в том, что sort нужен многим, а isNaN только некоторым? Да, у JS очень много дебильного поведения, но иллюстрировать эту позицию нужно теми примерами, которые чаще всего встречаются.
Отсутствие целочисленного типа. В реальности внутри движка для подходящих чисел используется целочисленный SMI, сейчас это int31. Для программиста тоже есть, т. к. можно целочисленно сохранить числа до 2 ^ 53 по модулю, т. к. это является подмножеством double.
Какая разница, как оно внутри движка устроено? Меня волнует, что у меня нет возможности закодировать просто целочисленное число, которое не превратится в тыкву.
Вводим в консоли хрома:
> 10995116277761111111
Получаем:
10995116277761112000
Круто, чо. Это нормально для float/double, ожидаемое поведение. Но абсолютно неадекватно для целочисленных. (Адекватно было бы падать).
В чем проблема? Ну например, parseInt('10995116277761111111', 10) отрабатывает так же само. parseInt парсит float, Карл! А что делает parseFloat? Тоже парсит float.
Неверная сортировка по умолчанию. Это смотря с какой стороны посмотреть. Вы не задали компоратор, соответственно, движок не может знать, как Вы хотели посортировать. Хотя я бы для удобства (и скорости) добавил бы метод sortNumbers({order: 'ask|desk'}) либо расширил обычный sort до sort(cmp), где cmp — либо функция, либо строка strings_ask | strings_desk | numbers_ask | numbers_desk.
Если движок не может знать, то движок должен требовать компаратор; а не рофлить.
«Полное отсутствие в JavaScript стандартной библиотеки» — встроенное API у JS мощное. А в node.js из коробки идут API, в которых есть вообще всё, что может понадобиться (например, низкоуровневые функции работы с файлами или сетью). Также можно установить или подключить библиотеки (модули) от сторонних разработчиков.
Конечно, ведь lodash (или его аналог) нужен только маргиналам. Map/Set/WeakMap/WeakSet недавно добавили тоже для маргиналов. WeakRef вообще только полным ублюдкам нужен.
Код:
for (var i = 1; i <= 2; ++i) {
setTimeout(function(){
console.log(i); //3
}, 0);
}
Здесь всё максимально правильно, если Вы не понимаете принцип работы, значит Вы не вообще изучили язык.
Вот удивительно как фанаты JS могут оправдать что угодно простым заклинанием «RTFM». Когда-то в C# было такое же дурацкое поведение. Ребята обнаружили, подумали, исправили спеку, выпустили новую версию языка с адекватным ожидаемым поведением. Но JS не для слабаков, да?
«выглядит громоздко» — на самом деле многопоточный код в JS намного проще, чем в других языках
Вы вообще другие языки видели? Они же предлагают кучу решений под разные сценарии. Вы уверены, что то, что предлагает JS вообще можно использовать там, где можно было бы работать с нормальной многопоточностью?
При этом JS быстр и ест очень мало памяти (на браузер не смотрите, там причина высокого потребления памяти совсем в другом).
Это правило не так-то хорошо работает, когда на одном конце провода незакомплексованный человек, а на другом конце провода — человек, который находится в состоянии стресса (или просто не имел конструктивного опыта взаимодействия с критикой).
Много проблем происходит из-за того, что люди разные и не понимают, что их поведение вызывает негативные ощущения у других.
И когда вы стейт менеджмент будете делать не на lifecycle-методах, а сторонними средствами
Вот тут проблема есть в этом рассуждение.
Да, некоторые люди используют реактовский state (без state management).
Да, статья написана с примерами кода без state management.
Но это не значит, что хуки не решают каких-то проблем.
Реакт занимается всем view, а не только рендерингом. Сложную view-логику вы не сможете переложить на state management, потому что там ей не месте.
Не говоря уже о том, что react hooks упрощают использование connect, contexts и прочих штук.
Я обожаю ситуацию, когда не понимаешь: твой собеседник тролль или вы просто друг друга не поняли?
Краткая интерпретация событий
Статья: Хуки позволяют переиспользовать код.
1-е сообщение (вы): «Я конечно понимаю, что в это может быть сложно поверить, но — если вы из класса вытащите всю отчуждаемую логику, то вы точно так же будете и с классами переиспользовать код.»
Ну вот вроде бы я должен был понять это сообщение как «реюз можно и на ООП строить, хуки не нужны».
2-е сообщение (я): «В typescript например, все не так радужно с ООП. Реюз возможен через HoC, а он порождает огромные проблемы с типизацией. Реюз возможен через миксины, но миксины заставляют дублировать интерфейс.»
Ну вот вроде бы вы должны были понять это сообщение как «в typescript реюз нельзя на ООП строить».
3-е сообщение (вы): «Да ну здрасьте. Что вам мешает наследовать классы в TS и делать всё без HOC? Там очень обычный ООП.»
Ну вот вроде я должен был понять это сообщение как «да ну шо вы говорите, в typescript на ООП отлично делает реюз»
4-е сообщения (я): «Например, то, что в TS нет поддержки мульти-наследования. Не считая миксинов, но см. выше»
Ну вот вроде бы вы должны были понять, что «я крайне несогласен с тем, что TS можно делать реюз на ООП, потому что отсутствует мульти-наследование»
5-е сообщение (вы): «Угу, а концептуально мульти-наследование — штука очень интересная и способная породить бесконечно количество граблей для последующего наступания.»
Я вот должен это как понять? Что если мульти-наследование — штука плохая, то это значит, что в typescript круто делается реюз через ООП?
Дополнительная интерпретация
Тут допустима еще одна интерпретация вашего текста. Как я понимаю, вы могли иметь в виду, что из компонента A можно вытащить какую-то общую логику вовне через функцию sharedFn. И использовать потом эту функцию sharedFn в другом компоненте B.
Такой вариант мне просто даже в голову не приходил до тех пор, пока я не начал прочесывать сообщения.
Если вы имели в виду именно это, то имхо, 1) удельный КПД этого действия слишком мал, чтобы его всерьез рассматривать; 2) подобный реюз не «атомарен» и не прячет деталей «абстракции».
Например, если реюзаемая логика sharedLogic требует участия в lifecycle методе componentDidMount и componentDidUnmount, то в компоненте A нужно будет вызвать componentDidMount и componentDidUnmount руками. Потом, если в будущем sharedLogic захочет участия в componentDidUpdate, то его нужно будет добавить во все компоненты, которые используют sharedLogic. Без наследования это бессмысленно.
Также подобный подход не обеспечит нормальной типизации для state, если вам нужно реюзать логику состояния компонента.
Как ни крути, все равно бред получается пока что.
Выводы
Хуки — это хорошо для реюза.
В typescript для реюза:
hooks лучше HoC (потому что типы не расходятся и их не нужно дублировать)
HoC лучше mixin (потому что не нужно делать заглушки для кастомных-методов из миксина)
mixin куда лучше наследования (потому что нет мульти-наследования).
В javascript для реюза:
hooks чуть лучше HoC (потому что не вводит новых мусорных компонентов, видных в React Developer Tools)
HoC чуть лучше или равноценен mixin (потому что меньше риск получить конфликт на двойном реюзе одинаковой логики; но в теории это можно доработать)
mixin куда лучше наследования (потому что нет мульти-наследования)
Наследование — это пример идеи хорошей в теории, но почему-то на практике редко используемой. Как вы думаете, почему? Потому что джаваскриптеры не умеют в ООП. Потому что наследование на практике не работает.
Что вам мешает наследовать классы в TS и делать всё без HOC
Например, то, что в TS нет поддержки мульти-наследования. Не считая миксинов, но см. выше.
Мне однако безынтересно обсуждать код без кода. Если вы верите в наследование, то попрошу вас предоставить сэмпл «реюзабельного кода» на наследовании. Так, чтобы его аналогом был компонент с четырьма хукам (hooks) или четырьма хоками (HoC). Например: connect, использование двух контекстов и мемоизация коллбека.
ЧЯДНТ? dotnetfiddle.net/gi2MBL — вполне адекватный результат показывает. Из-за того, что каст работает неожиданным образом, каст нужно делать явно.
Формулировки про диапазон от int55 до int64 не очень понятны.
Это не так. Да, переполнение зачастую работает именно таким образом. Но переполнение случается при манипулировании числами (сложение, вычитание, умножение). Мы же говорим о случае «число просто ввели» и «число пытаются распарсить из строки». Переполнение тут совершеннно не применимо.
dotnetfiddle.net/PIrWZK — и вуаля, опять здоровое поведение. Хотя вы уже согласились, это было ни к чему
С наличием недостатка согласились и проехали. Но исходное утверждение у вас было в том, что стандартная библиотека js достаточно мощная. Претензия про то, что добрую половину lodash нужно было бы впихнуть в стандартную библиотеку — она сохраняется. Это ни в коей мере не похоже на богатую стандартную библиотеку.
Ну если сравнивать со скриптовиками и при учете слова «вероятно», то вероятно вы правы. Хотя обычно делают бенчмарки на реалистичных случаях.
PHP вообще удобный язык для сравнения. Можно вообще половину языков оправдать существованием PHP, особенно его старых версий.
Если вы считаете такое поведение copyFile неадекватным, то в чем кардинальная разница этого случая и поведения var?
Нет, контринтуитивность — это не просто расхождение актуального с ожидаемым. Контринтуитивность — это когда после того как вы узнали правильный ответ вы восклицаете «чезанах? как это может быть правдой?»; это когда приходится прилагать осознанные усилия, чтобы помнить о таком поведении. Например, парадокс Монти-Холла принадлежит к такому классу вещей.
Снобизм не идет к лицу.
C# спроектирован не на отъебись, и позволяет стрелять в ноги только в unsafe. В остальном в C# сложность использования связана со сложностью задачи. В основном. Моменты есть, но их куда меньше, чем у js.
Удобно — это когда не приходится использовать сторонние инструменты, чтобы избежать проблем. При прочих равных остается только линтер.
Почему хотелось бы избежать — потому что каждое линт-правило вносит дополнительную задержку во время компиляции. А дурацкого поведения много. В итоге получается, что задержка существенная.
Ну очень плохо, что вы предполагаете только такой сценарий. Сценарий таков: у меня два основных языка — TypeScript и C#. При переключении между ними я иногда использую var внутри TS по-привычке.
Разные люди, которые используют язык. Осведомленное большинство.
Меня например сейчас это волнует только в контексте необходимости переключаться между C# и TS, у которых var имеет совершенно различное поведение. Но концептуально меня волнует то, что managed язык предоставляет чудесное средство выстрелить в ногу. Линтер — это замечательный костыль, но хотелось как-бы без костылей.
А еще можно настроить линтер, чтобы не вызывать sort() и кучу еще дебильных моментов, которые не должны быть проблемой по дефолту.
RTFM-синдром преобразовывается в мой-оппонент-копипастер-синдром.
«Правильно и понятно для тех, кто знает как оно работает» — это вообще не критерий, достойный упоминания. И уж тем более его нельзя использовать в языковом сраче. Правильный критерий «при прочих равных я хотел бы, чтобы язык программирования работал так, а не иначе». Если люди не предпочитают добровольно использовать var (вкупе с осознанием его реального поведения) чаще чем let/const, то это значит, что var — ошибка. Косякам всегда можно найти объяснение, но это все равно останется косяком.
И нет, обратная совместимость — не аргумент. В конечном счете, «use strict» же ломал существующее поведение, не ломая его. Что мешало сделать нормальную директиву «langVersion:es7», которая отрубает var и прочий мусор?
Если кто-то считает, что неожиданное поведение хоть в какой-то мере адекватно; то это явно стоит срача.
Почему это не устраивают? habr.com/ru/post/142140
Может быть дело в том, что sort нужен многим, а isNaN только некоторым? Да, у JS очень много дебильного поведения, но иллюстрировать эту позицию нужно теми примерами, которые чаще всего встречаются.
Какая разница, как оно внутри движка устроено? Меня волнует, что у меня нет возможности закодировать просто целочисленное число, которое не превратится в тыкву.
Вводим в консоли хрома:
> 10995116277761111111
Получаем:
10995116277761112000
Круто, чо. Это нормально для float/double, ожидаемое поведение. Но абсолютно неадекватно для целочисленных. (Адекватно было бы падать).
В чем проблема? Ну например, parseInt('10995116277761111111', 10) отрабатывает так же само. parseInt парсит float, Карл! А что делает parseFloat? Тоже парсит float.
Если движок не может знать, то движок должен требовать компаратор; а не рофлить.
Конечно, ведь lodash (или его аналог) нужен только маргиналам. Map/Set/WeakMap/WeakSet недавно добавили тоже для маргиналов. WeakRef вообще только полным ублюдкам нужен.
Вот удивительно как фанаты JS могут оправдать что угодно простым заклинанием «RTFM». Когда-то в C# было такое же дурацкое поведение. Ребята обнаружили, подумали, исправили спеку, выпустили новую версию языка с адекватным ожидаемым поведением. Но JS не для слабаков, да?
Вы вообще другие языки видели? Они же предлагают кучу решений под разные сценарии. Вы уверены, что то, что предлагает JS вообще можно использовать там, где можно было бы работать с нормальной многопоточностью?
По сравнению с кем?
У тайпскрипта в корне лежат те же проблемы, что и у джаваскрипта, потому что он старается быть максимально "джаваскриптом с типамии".
Я пользуюсь. Потому что раньше пользовался оперой
Много проблем происходит из-за того, что люди разные и не понимают, что их поведение вызывает негативные ощущения у других.
Я правильно понимаю, что они обнаружили, что у замкнутой системы есть только ограниченное количество состояний?
/сарказм, чисто в противовес.
А что, у вас в практике был пример подобной жести?
Да, некоторые люди используют реактовский state (без state management).
Да, статья написана с примерами кода без state management.
Но это не значит, что хуки не решают каких-то проблем.
Реакт занимается всем view, а не только рендерингом. Сложную view-логику вы не сможете переложить на state management, потому что там ей не месте.
Не говоря уже о том, что react hooks упрощают использование connect, contexts и прочих штук.
1-е сообщение (вы): «Я конечно понимаю, что в это может быть сложно поверить, но — если вы из класса вытащите всю отчуждаемую логику, то вы точно так же будете и с классами переиспользовать код.»
Ну вот вроде бы я должен был понять это сообщение как «реюз можно и на ООП строить, хуки не нужны».
2-е сообщение (я): «В typescript например, все не так радужно с ООП. Реюз возможен через HoC, а он порождает огромные проблемы с типизацией. Реюз возможен через миксины, но миксины заставляют дублировать интерфейс.»
Ну вот вроде бы вы должны были понять это сообщение как «в typescript реюз нельзя на ООП строить».
3-е сообщение (вы): «Да ну здрасьте. Что вам мешает наследовать классы в TS и делать всё без HOC? Там очень обычный ООП.»
Ну вот вроде я должен был понять это сообщение как «да ну шо вы говорите, в typescript на ООП отлично делает реюз»
4-е сообщения (я): «Например, то, что в TS нет поддержки мульти-наследования. Не считая миксинов, но см. выше»
Ну вот вроде бы вы должны были понять, что «я крайне несогласен с тем, что TS можно делать реюз на ООП, потому что отсутствует мульти-наследование»
5-е сообщение (вы): «Угу, а концептуально мульти-наследование — штука очень интересная и способная породить бесконечно количество граблей для последующего наступания.»
Я вот должен это как понять? Что если мульти-наследование — штука плохая, то это значит, что в typescript круто делается реюз через ООП?
Такой вариант мне просто даже в голову не приходил до тех пор, пока я не начал прочесывать сообщения.
Если вы имели в виду именно это, то имхо, 1) удельный КПД этого действия слишком мал, чтобы его всерьез рассматривать; 2) подобный реюз не «атомарен» и не прячет деталей «абстракции».
Например, если реюзаемая логика sharedLogic требует участия в lifecycle методе componentDidMount и componentDidUnmount, то в компоненте A нужно будет вызвать componentDidMount и componentDidUnmount руками. Потом, если в будущем sharedLogic захочет участия в componentDidUpdate, то его нужно будет добавить во все компоненты, которые используют sharedLogic. Без наследования это бессмысленно.
Также подобный подход не обеспечит нормальной типизации для state, если вам нужно реюзать логику состояния компонента.
Как ни крути, все равно бред получается пока что.
В typescript для реюза:
В javascript для реюза:
Наследование — это пример идеи хорошей в теории, но почему-то на практике редко используемой. Как вы думаете, почему?
Потому что джаваскриптеры не умеют в ООП.Потому что наследование на практике не работает.Например, то, что в TS нет поддержки мульти-наследования. Не считая миксинов, но см. выше.
Мне однако безынтересно обсуждать код без кода. Если вы верите в наследование, то попрошу вас предоставить сэмпл «реюзабельного кода» на наследовании. Так, чтобы его аналогом был компонент с четырьма хукам (hooks) или четырьма хоками (HoC). Например: connect, использование двух контекстов и мемоизация коллбека.