D
Берешь расширение файла и в зависимости от него отображаешь нужные иконки. Для картинок можешь через
Andrii
FileReader() в base64 конвертнуть и вывестиAndrii
(change)="onSelectFile($event)"Size: a a a
2020 January 06
D
У ангуляра из коробки нет чего-то отличающегося от обычного js, ивент такой же
VB
Dolgovec
Привет. Я наверно чего-то не понимаю в тестах. У меня в компоненте есть на OnInit() вызов функции из сервиса, в самом сервисе идет вызов MatSnackBar. Вопрос: если я мокаю этот сервис, то он идет пустой и метод
.open() у снекбара не вызывается. И что с этим делать?В тестах тебе и не нужен вызов этого snackBar, ты ж тестируешь именно компонент, а не сервис. В компоненте достаточно проверить что вызвался метод сервиса с нужными параметрами. Это уже для е2е тестов важно что все остальное работает, а для юнит нам пофиг вообще на остальные вложенные зависимости
D
@valburyakov да, я к этому уже сам пришел, мокаю только сервисы и отслеживаю вызов в нем. Спасибо за ответ
ЕУ
https://v6.angular.io/guide/styleguide#interfaces
еще в 6 версии ангуляра появилась рекомендация не использовать I в именах интерфейсов
Лучше вообще не использовать префиксы или постфиксы в названий интерфейсов
еще в 6 версии ангуляра появилась рекомендация не использовать I в именах интерфейсов
Лучше вообще не использовать префиксы или постфиксы в названий интерфейсов
исключительно вкусовщина. зависит от стайлгайда конкретной команды
ДМ
исключительно вкусовщина. зависит от стайлгайда конкретной команды
с этим я согласен
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
ЕУ
с этим я согласен
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
ну так-то согласен. если интерфейсы с префиксом I, то почему enam без Е ))
ДМ
ну так-то согласен. если интерфейсы с префиксом I, то почему enam без Е ))
ед с чем я согласен, это постфиксы ввиде Component, Service и тд. Так как они создаются для избегания коллизий имен, чтобы User компонент и User сервис могли сосуществовать в одном namespace
ДМ
ну и еще _ в приватных членах данных в языках с дин типизацией, где нет возможности сокрыть реализацию
YS
с этим я согласен
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
но тенденция такова, что со временем все начинают уходить от префиксов. Префиксы появились в венгерской нотации, когда еще не было крутых IDE, которые могли сказать нам о типе данных. Названия переменных и сущностей в первую очередь должны отражать то, для чего они были определены. А засилие префиксов и постфиксов только осложняет чтение и отвлекает от деталей(сошлусь на "Чистый код")
у интерфейса ставят I, чтобы при создании класса, его реализующего, различать их
YS
вполне нормальный подход
AH
у интерфейса ставят I, чтобы при создании класса, его реализующего, различать их
интерфейс же должен быть более абстрактным, а класс - уже конкретная реализация, соответственно названия не должны совпадать. Например интерфейс - Door, класс - WoodenDoor
ДМ
у интерфейса ставят I, чтобы при создании класса, его реализующего, различать их
интерфейсы обычно более абстрактны, чем классы, которые их реализовывают
например есть интерфейс Iterator, а реализация может быть как EvenIterator или OddIterator
Нет смысла реализовать интерфейс и класс с одним и тем же названием
И конкретно к тс, В тс можно делать так:
class A (public b: string) {}
const a1 = new A('a1');
const a2: A = { b: 'a2' }; - тогда вопрос, какой префикс ставить у класса A?
например есть интерфейс Iterator, а реализация может быть как EvenIterator или OddIterator
Нет смысла реализовать интерфейс и класс с одним и тем же названием
И конкретно к тс, В тс можно делать так:
class A (public b: string) {}
const a1 = new A('a1');
const a2: A = { b: 'a2' }; - тогда вопрос, какой префикс ставить у класса A?
ДМ
интерфейс же должен быть более абстрактным, а класс - уже конкретная реализация, соответственно названия не должны совпадать. Например интерфейс - Door, класс - WoodenDoor
+
YS
интерфейсы обычно более абстрактны, чем классы, которые их реализовывают
например есть интерфейс Iterator, а реализация может быть как EvenIterator или OddIterator
Нет смысла реализовать интерфейс и класс с одним и тем же названием
И конкретно к тс, В тс можно делать так:
class A (public b: string) {}
const a1 = new A('a1');
const a2: A = { b: 'a2' }; - тогда вопрос, какой префикс ставить у класса A?
например есть интерфейс Iterator, а реализация может быть как EvenIterator или OddIterator
Нет смысла реализовать интерфейс и класс с одним и тем же названием
И конкретно к тс, В тс можно делать так:
class A (public b: string) {}
const a1 = new A('a1');
const a2: A = { b: 'a2' }; - тогда вопрос, какой префикс ставить у класса A?
Использовать класс в качестве типа законно, никакого префикса не надо, это же не интерфейс:)
YS
а про абстрактность интерфейсов кто это сказал?:)
ДМ
лол, интерфейсы по своей природе - это абстракция
ДМ
это некий контракт, который обязан соблюдать тот, кто реализует интерфейс
у интерфейса не может быть реализации
у интерфейса не может быть реализации
YS
interface queryParamsI, class queryParams impelements queryParamsI
YS
это некий контракт, который обязан соблюдать тот, кто реализует интерфейс
у интерфейса не может быть реализации
у интерфейса не может быть реализации
это понятно :)