A
собственно потому и засмотрелись на атомик, что бы он нам помогал делить компоненты более мелко, чем разработчики это обычно делают
Size: a a a
2020 July 14
VK
во всех статьях, что я читал предлагают насыпать компоненты просто в некую папку components и там делить на организмы, молекулы
Я использую feature slices, но как лучше организовать компоненты внутри фич пока не понял
A
Я использую feature slices, но как лучше организовать компоненты внутри фич пока не понял
то что тут на моем скрине ProfileStream это буквально фича, состоящая из организмов, молекул, атомов
A
но конкретно как там в feature slices делают я не углублялся, пока такой подход норм работает у нас
AS
подскажите, у меня есть пакет
я его собирают tsc в директорию build пакета
у пакета есть interfaces.ts файл с типами
как мне его НЕ прогонять через транспиляцию , чтобы на выходе НЕ было файла interfaces.js
и чтобы типы можно было импортировать из пакета и юзать
вручную только делать в моей компоненте interfaces.d.ts и туда типы складывать (вместо interfaces.ts)?
как обычно делают?
я его собирают tsc в директорию build пакета
у пакета есть interfaces.ts файл с типами
как мне его НЕ прогонять через транспиляцию , чтобы на выходе НЕ было файла interfaces.js
и чтобы типы можно было импортировать из пакета и юзать
вручную только делать в моей компоненте interfaces.d.ts и туда типы складывать (вместо interfaces.ts)?
как обычно делают?
NK
И следующий скучный вторник
https://www.youtube.com/watch?v=xgnUonCky5M&feature=youtu.be
https://www.youtube.com/watch?v=xgnUonCky5M&feature=youtu.be
SP
Всем привет!
Кто-то использовал подобную конструкцию?
<component :is="currentComponent" v-model="items[0]"/>
в данном случае не работает v-model
Кто-то использовал подобную конструкцию?
<component :is="currentComponent" v-model="items[0]"/>
в данном случае не работает v-model
MB
такой подход давно практиковали в реакте и отказываются от него
Для себя так и не понял почему отказываются. Да, появились хуки. Но допустим у меня есть компонент с логикой, который я еще хочу визуально потестить в сторибуке. И без разделения на контейнер/компонент тут никак. Либо заморачиваться с мокированием
Поэтому пока всё ещё разделяю какие-то компоненты
Поэтому пока всё ещё разделяю какие-то компоненты
IK
Sergey Pavlenko
Всем привет!
Кто-то использовал подобную конструкцию?
<component :is="currentComponent" v-model="items[0]"/>
в данном случае не работает v-model
Кто-то использовал подобную конструкцию?
<component :is="currentComponent" v-model="items[0]"/>
в данном случае не работает v-model
Логично, скорее всего у компонента не стандартная конфигурация v-model
IK
Для себя так и не понял почему отказываются. Да, появились хуки. Но допустим у меня есть компонент с логикой, который я еще хочу визуально потестить в сторибуке. И без разделения на контейнер/компонент тут никак. Либо заморачиваться с мокированием
Поэтому пока всё ещё разделяю какие-то компоненты
Поэтому пока всё ещё разделяю какие-то компоненты
Все есть компонент, компоненты сами умеют тягать свои данные
IK
В гитлабе некоторые компоненты даже свои сторы вьюксовские создают
NS
MB
Все есть компонент, компоненты сами умеют тягать свои данные
А в какой момент это стало хорошей практикой, когда компонент знает и умеет всё сам?
Или в данном случае "умеет" != "хорошая практика"?
Или в данном случае "умеет" != "хорошая практика"?
V
Подскажите, у вас в компании тимлиды что делают ? Пишут код ? У кого как?
Вообще не могу понять, как так получается что тимлид может писать 0 кода, не решать тех задачи для упрощения разработки, не заниматься оптимизацией, не помогать , не быть наставником
Что он вообще обязан делать ?
Вообще не могу понять, как так получается что тимлид может писать 0 кода, не решать тех задачи для упрощения разработки, не заниматься оптимизацией, не помогать , не быть наставником
Что он вообще обязан делать ?
пишет, наставничает, следит за спринтами, создает задачки, отчитывается за билд и архитектуру
V
Вообще не понимаю как так может быть что тимлиды не пишут код от силы вообще
но код так лень писать, только если что то прям оч новое, с чем еще не работал
RM
А в какой момент это стало хорошей практикой, когда компонент знает и умеет всё сам?
Или в данном случае "умеет" != "хорошая практика"?
Или в данном случае "умеет" != "хорошая практика"?
Мы практикуем создание полностью изолиронных компонентов. В котором хранится состояние, общение с сервером. Бонусом компоненту можно передать id в качестве key и при изменени сущности, он будет инициализирован заново. Тем самым не нужно обнулять данные, запускать предвариьтельную обработку данных.
Простейщий пример: компонент выбора адреса с поиском. Не вижу приимуществ вынесения бизнес логики и общения с сервером в store.
Простейщий пример: компонент выбора адреса с поиском. Не вижу приимуществ вынесения бизнес логики и общения с сервером в store.
V
ой не так прочел))
V
А в какой момент это стало хорошей практикой, когда компонент знает и умеет всё сам?
Или в данном случае "умеет" != "хорошая практика"?
Или в данном случае "умеет" != "хорошая практика"?
когда не требуется все эти «усложнения»
AP
В какойто момент приходит осознание того что компоненты в которых много логики сильно влияют на перфоманс. Но уже поздно.