Это сделано для тех, кто привык использовать static propTypes, очевидно. Но засорять тельце компонента — как-то совсем, на мой вкус. И не добиться единообразия с функциональными компонентами.
Спорно. Помнится, ещё в Delphi можно было отдельно объявить тип для использования, и описывать его где-нибудь ниже по коду. Ностальгия. Я применяю деструктуризацию для props, т.е. имена аргументов видно сразу. А разглядывать их типы не особо интересно — информационный шум.
WebStorm сворачивает импорты. В результате, когда открываю файл, то первым делом вижу реализацию компонента. А типы по переходу в конец файла [CTRL]+[END]. Привычка.
v4 is a complete rewrite. As such, there is no singular breaking change. We have some similar-looking things (<Route path="/foo" component={Foo} />), but the behaviors are completely different. You should expect none of your existing react-router usage to work under 4.0.
As for the on* hooks, they were removed because they already exist in React as the lifecycle methods. We were reimplementing them inside the Router, but they didn't exactly behave like they should. So, why provide an inferior or conflicting API? Everything is way more React-y now, and it's way better as a result. You no longer have to mix paradigms or code for two different systems. It's just React now. It's a much lower cognitive load.
The approach being taken for 4.0 is to strip out all the "batteries included" kind of features and get back to just basic routing. If you need query string parsing or async loading or Redux integration or something else very specific, then you can add that in with a library specifically for your use case. Less cruft is packed in that you don't need and you can customize things to your specific preferences and needs.
Ага, react-app-rewired уже заюзал для подключения прекрасного пакета Styled JSX:
Теперь CSS-блоки живут внутри файлов компонентов естественным для себя образом — в CSS-формате (против инлайн-стилей JS-объектов). И не нужно беспокоиться за глобальную область видимости.
Недостаток конфигурации легко обойти, react-app-rewired прекрасен.
Это сделано для тех, кто привык использовать static propTypes, очевидно. Но засорять тельце компонента — как-то совсем, на мой вкус. И не добиться единообразия с функциональными компонентами.
Спорно. Помнится, ещё в Delphi можно было отдельно объявить тип для использования, и описывать его где-нибудь ниже по коду. Ностальгия. Я применяю деструктуризацию для props, т.е. имена аргументов видно сразу. А разглядывать их типы не особо интересно — информационный шум.
babel-plugin-tcomb — транспайлит код с применением tcomb.
Nuclide точно поддерживает. Очевидно, что Visual Studio не отстает, но этого я не пробовал.
Настройка WebStorm:
WebStorm сворачивает импорты. В результате, когда открываю файл, то первым делом вижу реализацию компонента. А типы по переходу в конец файла [CTRL]+[END]. Привычка.
о применении typeof
Про onEnter, получите и распишитесь. :)
Никогда раньше такого не видел, зачем тут default?
А кто знает, уже починили спреды?
Чем больше сдадим, тем лучше! :)
В статье ни слова про это: https://habrahabr.ru/post/320306/
Возьмите date-fns :)
Ага, react-app-rewired уже заюзал для подключения прекрасного пакета Styled JSX:
yarn run eject — в этом месте уже страшно :)
https://habrahabr.ru/post/326018/ — написал заметку по теме
Проходили. Как следствие размножения подпапок, плодятся компоненты с одинаковыми именами. Можно повеситься, перебирая List.js, Button.js etc. :)
Perfect World:
IDE подкручивал для навигации по абсолютным путям — в любом случае нужно.