Действительно, в рамках этой статьи не было рассмотрено копирование статических свойств в HoC, можем рассказать об этом в одной из следующих публикаций.
У нас используется собственная разработка, которая складирует все ошибки в БД для последующего анализа. Сам сервис доступен всегда по определенному URL'у.
Верное замечание, storybook отлично подходит для проектов на начальном этапе. По мере развития проекта, функциональности может не хватать. В ЕФС мы используем собственное решение для генерации гайдлайнов на базе Confluence: текст стягивается из Conflunce, в специальных вставки отрисовываются React-компоненты. Такой подход позволяет разнообразить гайдлайны, даже если человек никогда в своей жизни не видел исходный код.
Если над приложением работает одна команда, то да, это реализуется без проблем, но когда над разными кусками работают разные команды, могут возникать коллизии имен action'ов, отсюда вырастает потребность в синхронизации. С реализией в несколько store'ов такая проблема отпадает.
В hash у нас хранится ID загруженного приложения и ID операции, таким образом, история браузера сохраняется. Более того, перезагрузив страницу и имея оба ID, мы можем восстановить приложение на том экране, которые нужен и бек при этом пришлет данные для предзаполнения форм.
Приложения могут разрабатываться разными командами, у них есть некоторые контракты, по которым они работают. Допустим, одно из приложений реализует broadcast-сообщения внутри себя, например, сервис уведомлений, тогда соседнее приложение может подписаться на этот канал и реагировать соответствующе при наличии срочных сообщений, на которые оно настроено. Внутри приложений компоненты используют общий store, поэтому это проблем с коммуникацией не вызывает.
Генератор сам по себе основан на typedoc, для себя внутри команды мы начали генерировать документацию изначально с помощью него. Конечно, мы еще не все фишки генератора перетащили на гитхаб, но мы работаем над этим и скоро проект пополнится новыми фишками :)
Если интересно, можете оставить контакты на NVNadorichev.SBT@sberbank.ru и будем держать в курсе событий
Пример пока можно посмотреть в папке examples
https://github.com/Sberbank-Technology/ufs-react-doc/tree/release/1.0/examples/simple
Планируем добавить на gh-pages
а зачем в 2020 году его использовать, если та же функциональность появилась в самом TS?
https://github.com/Microsoft/TypeScript/wiki/Writing-a-Language-Service-Plugin
Действительно, в рамках этой статьи не было рассмотрено копирование статических свойств в HoC, можем рассказать об этом в одной из следующих публикаций.
У нас используется собственная разработка, которая складирует все ошибки в БД для последующего анализа. Сам сервис доступен всегда по определенному URL'у.
Верное замечание, storybook отлично подходит для проектов на начальном этапе. По мере развития проекта, функциональности может не хватать. В ЕФС мы используем собственное решение для генерации гайдлайнов на базе Confluence: текст стягивается из Conflunce, в специальных вставки отрисовываются React-компоненты. Такой подход позволяет разнообразить гайдлайны, даже если человек никогда в своей жизни не видел исходный код.
Если над приложением работает одна команда, то да, это реализуется без проблем, но когда над разными кусками работают разные команды, могут возникать коллизии имен action'ов, отсюда вырастает потребность в синхронизации. С реализией в несколько store'ов такая проблема отпадает.
В hash у нас хранится ID загруженного приложения и ID операции, таким образом, история браузера сохраняется. Более того, перезагрузив страницу и имея оба ID, мы можем восстановить приложение на том экране, которые нужен и бек при этом пришлет данные для предзаполнения форм.
Приложения могут разрабатываться разными командами, у них есть некоторые контракты, по которым они работают. Допустим, одно из приложений реализует broadcast-сообщения внутри себя, например, сервис уведомлений, тогда соседнее приложение может подписаться на этот канал и реагировать соответствующе при наличии срочных сообщений, на которые оно настроено. Внутри приложений компоненты используют общий store, поэтому это проблем с коммуникацией не вызывает.
в отсутствии ActiveX это пока единственный способ подружить браузер с железом, если есть предложения, как это сделать, будем рады услышать
стандартный подход к раскладке форм по Grid'у: задаются колонки, строки, внутри них вставляются компоненты
Согласен, об этом я писал выше: главное подходить к stateless-компонентам без фанатизма
Да, у React очень низкий порог входа, поэтому на собеседовании мы не спрашиваем знания React.
тащить всё в store нет нужды, некоторые компоненты в действительности stateful, для DateInput API следующее:
Если интересно, можете оставить контакты на NVNadorichev.SBT@sberbank.ru и будем держать в курсе событий
https://github.com/Sberbank-Technology/ufs-react-doc/tree/release/1.0/examples/simple
Планируем добавить на gh-pages