VS
а зачем это? что это дает то? ну это как писать public на паблик поля и методы, только по-умолчанию этого нет в ангуляре, а кто-то пытается запихнуть, потому что нравится
ну типа, чтоб было понятно, что это интерфейс)))
Size: a a a
2020 June 16
AH
Не оч, если ты захочешь взять свою работу с формами (контролы, вывод ошибок, директивы и прочти вспомотельные ништяки) и вынести в отдельный модуль чтобы переиспользовать в другой апке, ты будешь бегать по всему проекту и выкусывать из папок conponents helpers и и.д. нужные кусочки?
ты имеешь в виду в другом приложении?
IB
ты имеешь в виду в другом приложении?
Ну например
ЭП
ну типа, чтоб было понятно, что это интерфейс)))
почему тогда не добавлять T перед типом или C пред классом модели?
E
а зачем это? что это дает то? ну это как писать public на паблик поля и методы, только по-умолчанию этого нет в ангуляре, а кто-то пытается запихнуть, потому что нравится
если ты private на приватные пишешь, то зачем публичные обижать?
ЭП
если ты private на приватные пишешь, то зачем публичные обижать?
приватные станут приватными, когда ты их такими опишешь, а с публичными ничего не меняется
VS
приватные станут приватными, когда ты их такими опишешь, а с публичными ничего не меняется
зато явно указано, что это публичное поле)
E
приватные станут приватными, когда ты их такими опишешь, а с публичными ничего не меняется
меняется. читаемость кода. понимание кода. а еще ты включаешь голову и думаешь, когда ставить public, когда private.
AS
я пишу public когда совершенно точно ясно что метод публичный. и не пишу, когда еще не определил
VS
почему тогда не добавлять T перед типом или C пред классом модели?
да, согдласен, это тупо))
AH
Самое смешное, что прошлые разрабы сделали на каждый пук общий компонент, а вот то, что в 376 местах у нас используется конструкция:
ngOnChanges(inputs) {
if (inputs.accounts && inputs.accounts.currentValue && inputs.accounts.currentValue !== inputs.accounts.previousValue) {
А сделать по человечески (на скрине) догадалась только я. Теперь это выглядит просто вот так:ngOnChanges(changes: SimpleChanges): void {
if (isOnChanges(changes.document)) {AK
если бы дали сделать это с самого начала, когда я просил, то это заняло бы день-два, когда компонентов было штук 10-15, а разделов всего 2
А ты как доносил?
1.Все говно, так не делают и надо переписать
2. Переписываем это и вот и вот тут ещё все, это сэкономит нам x часов и позволит внедрить фичи а и б на N дней раньше
1.Все говно, так не делают и надо переписать
2. Переписываем это и вот и вот тут ещё все, это сэкономит нам x часов и позволит внедрить фичи а и б на N дней раньше
AS
Самое смешное, что прошлые разрабы сделали на каждый пук общий компонент, а вот то, что в 376 местах у нас используется конструкция:
ngOnChanges(inputs) {
if (inputs.accounts && inputs.accounts.currentValue && inputs.accounts.currentValue !== inputs.accounts.previousValue) {
А сделать по человечески (на скрине) догадалась только я. Теперь это выглядит просто вот так:ngOnChanges(changes: SimpleChanges): void {
if (isOnChanges(changes.document)) {а лучше вообще избегать onChanges
E
в своем я стала делать так. и импорчу только модуль конкретного компонента, который мне нужен
ууу
E
@dersizes дяденька оператор, несите валидол
IB
а лучше вообще избегать onChanges
@thekiba тут на твои любимые onchanges покусились
N👩
ЭП
меняется. читаемость кода. понимание кода. а еще ты включаешь голову и думаешь, когда ставить public, когда private.
может это вкуса и восприятия, но для меня это бессмысленно, особенно когда ангуляр этого и не делает
ЭП
а лучше вообще избегать onChanges
чего?
VS
А ты как доносил?
1.Все говно, так не делают и надо переписать
2. Переписываем это и вот и вот тут ещё все, это сэкономит нам x часов и позволит внедрить фичи а и б на N дней раньше
1.Все говно, так не делают и надо переписать
2. Переписываем это и вот и вот тут ещё все, это сэкономит нам x часов и позволит внедрить фичи а и б на N дней раньше
ну примерно, причем лид тоже это говорил, но -