Круто! Альтруизм — это важно). Меня интересует, сколько часов потрачено на прототип, и сколько людей пользуется этой штукой. Как вообще рассказать миру про свой сервис, чтобы это заметили люди? Откуда взять психологов добровольцев?
О! А я наоборот, не могу перейти в WebStorm) Он манил меня некоторыми фичами, но UI/UX… Чувствую себя у штурвала космического корабля.
По мне, главное, при начале работы с VSCode, настроить авто форматирование при сохранении, и авто исправление ошибок. Исправление ошибок делают расширения Eslint, Tslint. Настроив это, VSCode превращается в пушку, которая пишет код за тебя. (Предполагаю, что WebStorm умеет не хуже, но много раз встречал людей, у которых и половины функционала из VSCode не работало в платной WebStorm)
Недавно наткнулся на лучшее, что мне попадалось, расширение для рефакторинга Abracadabra. Не такое популярное, но реально удобное. Хочу туда контрибьютнуть Extract class в ближайшее время, если кому интересно.
Интеграционные тесты позволяют проще рефакторить внутренности разных модулей… Очень спорное утверждение… По факту функциональный тест из статьи зависит и от разметки (h3, div), и от контента («Найти»), и от endpoint url ('api/search'). А мы проверили всего один простейший сценарий.
По своему опыту могу сказать, что такого рода тесты (функциональные, интеграционные, e2e) очень хрупкие. Ломаются неожиданно, фиксятся не очевидно, всякие проблемы с await waitRerendering(), await waitMounting(), setTimeout. И писать моки и pageObjects не радует, это сложные низкоуровневые манипуляции, как их не пряч. Даже переиспользование утильных функций для тестов в перспективе ни к чему хорошему не приведёт.
Мне кажется, основная проблема с тестированием на фронте кроется в том, что мы не умеем в модели/презентаторы. Поэтому и юнитами ничего проверить не можем.
Выделяйте модель, пишите на все кейсы юниты, пишите один-два интеграционных (e2e), чтобы убедиться, что модель к компоненту приклеилась ровно, и пейте кофе.
Никак в разработке не убежать от навыков проектирования. Если у вас проблемы с юнитами, значит вы что-то делаете неправильно. А обмазывание снепшотами, e2e тестами, переворачивание пирамид — это самоуспокоение.
В общем, заранее извиняюсь, фигню какую-то написал, удалять жалко, а настроение холиварное
Пример юнит тестов
interface SearchApi {
search(term: string): Promise<SearchResult>;
}
interface SearchResult {}
class SearchPresenter {
pending: boolean = false;
result?: SearchResult;
constructor(private api: SearchApi) {}
async search(term: string): Promise<void> {
try {
this.pending = true;
this.result = await this.api.search(term);
} finally {
this.pending = false;
}
}
}
describe(SearchPresenter.name, () => {
describe(SearchPresenter.prototype.search.name, () => {
it('should resolve result', async () => {
const result = {} as SearchResult;
const searchPresenter = new SearchPresenter({ search: async () => result });
await searchPresenter.search('term');
expect(searchPresenter.result).toBe(result);
});
it('should change pending', async () => {
const searchPresenter = new SearchPresenter({ search: async () => ({} as SearchResult) });
const searchPromise = searchPresenter.search('term');
expect(searchPresenter.pending).toBe(true);
await searchPromise;
expect(searchPresenter.pending).toBe(false);
});
it('should set pending to false on error', async () => {
const searchPresenter = new SearchPresenter({ search: () => Promise.reject({}) });
await searchPresenter.search('term').catch(() => {});
expect(searchPresenter.pending).toBe(false);
});
it('should preserve prev result on error', async () => {});
it('should use last search term on double call', async () => {});
});
});
Но у меня есть предположение о том, что создать всеобъемлющую библиотеку компонентов невозможно. Всё равно каждый проект/дизайнер требует тюнинга того или иного элемента. Причём зачастую затюнить сложнее, чем написать свой велосипед. Мы зациклились на компонентах.
Мне кажется, что следующим шагов в эволюции фронта должен быть инструмент, который позволяет на высоком уровне решать рутинные задачи, связанные с UX. Под UX я подразумеваю поведение элементов. Эдакий конструктор для создания input, select, datepicker, который предоставляет разработчику полную кастомизацию HTML, CSS. Но сохраняет основное поведение.
Дело в том, что UI меняется от проекта к проекту. А вот UX остаётся примерно одним и тем же. Но наши любимые фреймворки оперируют только UI-компонентами, и заточены только под это.
Почему автор не привёл свой вариант рефакторинга всех этих классов?
Давайте относиться с уважением к хорошим книжкам, которые не являются истиной в последней инстанции. Но задают неплохие принципы кодирования в достаточно простой форме.
Примеры в статье вырваны из контекста. Например SetupTeardownIncluder — это не идеал. Где Мартин сказал, что это супер классный кусок кода? Это результат рефакторинга, через разбиение толстых методов на маленькие. Который приводится, чтобы объяснить, что маленькие функции — это очень важно. Даже если не применять другие принципы из книги вовсе.
И вот мне интересно, какой процент из голосовавших читал эту книжку, и может сказать, что она являлась бесполезной тратой времени?
Что вообще вы ожидаете от книги? Волшебный секрет «Тайны драконы», который прибавит 200К к ЗП?
Я считаю, подобного рода статьи без весомых альтернатив, не больше чем оправданием школьника, который не стал учить физику, потому что «в жизни не пригодится». Но давайте поплюсуем за очередной холивар до 100?
я знаю… но одной командой вы не разобьёте компонент на два.
Angular Language Service — постоянно тормозит для VSCode.
Короче, я считаю Angular прекрасным фреймворком. В нём заложено много здравых вещей — ReactiveForms, HttpInterceptors, RouteGuards, стили инкапсулируются для компонента автоматически, CLI прекрасно справляется со своими обязанностями, всё однообразно и со вкусом.
Но в плане удобства написания/сопровождения компонентов — он жёстко уступает React.
Я бы с радостью писал на React, в котором есть все основные фишки из Angular. Или наоборот, с радостью писал бы на Angular, если бы компоненты можно было так же легко писать/рефакторить.
Короче, жду Angulareact/Reangular. И поддерживаю сторонников обоих фреймворков.
Мне тоже казалось странным, что реактщики любят своебразный синтаксис придумывать. Который и так есть в классах, например. Но оказывается, краткость — экономия пары символов, имеет значение.
На своём опыте убедился, что компонент React рефакторится одной командой IDE — extract function. В Angular нужно создать 3+ файла, и перетаскивать руками html, ts. Удобство — это немаловажный фактор.
Мне кажется, что стоит рассматривать React компоненты со всеми хуками как самостоятельный язык для рисования интерфейса. Как прокачанный HTML. Но отсюда следует, что логики в этих компонентах должно быть как можно меньше.
Я всё равно не понимаю, что вы предлагаете упростить со стороны SPA или конкретного компонента. В статье приведено решение в лоб — дергаем сервис при изменении orderId.
После манипуляций с провайдерами, компоненту вообще стало пофиг откуда организации берутся и как обновляются. Компонент теперь зависит только от Организаций, а не способа их получения. (Я предпочитаю использовать State + Resolver, чтобы на роут юзера перебрасывало только после загрузки данных. Но это дело даже не вкуса, а UX.)
Другое дело, что boilerplate не очень приятный получается вокруг провайдеров, но это отдельная проблема.
Можете более информативно пояснить, какое упрощение можно сделать в данном кейсе? Ситуация распространённая: в зависимости от роута подгружать данные по id.
По мне, главное, при начале работы с VSCode, настроить авто форматирование при сохранении, и авто исправление ошибок. Исправление ошибок делают расширения Eslint, Tslint. Настроив это, VSCode превращается в пушку, которая пишет код за тебя. (Предполагаю, что WebStorm умеет не хуже, но много раз встречал людей, у которых и половины функционала из VSCode не работало в платной WebStorm)
Beautify — слишком много настроек… Заменил на Prettier и счастлив.
Извините, если много спама к одному посту
Я использовал атрибуты testId=«sumbit-button».
По своему опыту могу сказать, что такого рода тесты (функциональные, интеграционные, e2e) очень хрупкие. Ломаются неожиданно, фиксятся не очевидно, всякие проблемы с await waitRerendering(), await waitMounting(), setTimeout. И писать моки и pageObjects не радует, это сложные низкоуровневые манипуляции, как их не пряч. Даже переиспользование утильных функций для тестов в перспективе ни к чему хорошему не приведёт.
Мне кажется, основная проблема с тестированием на фронте кроется в том, что мы не умеем в модели/презентаторы. Поэтому и юнитами ничего проверить не можем.
Выделяйте модель, пишите на все кейсы юниты, пишите один-два интеграционных (e2e), чтобы убедиться, что модель к компоненту приклеилась ровно, и пейте кофе.
Никак в разработке не убежать от навыков проектирования. Если у вас проблемы с юнитами, значит вы что-то делаете неправильно. А обмазывание снепшотами, e2e тестами, переворачивание пирамид — это самоуспокоение.
В общем, заранее извиняюсь, фигню какую-то написал, удалять жалко, а настроение холиварное
Но у меня есть предположение о том, что создать всеобъемлющую библиотеку компонентов невозможно. Всё равно каждый проект/дизайнер требует тюнинга того или иного элемента. Причём зачастую затюнить сложнее, чем написать свой велосипед. Мы зациклились на компонентах.
Мне кажется, что следующим шагов в эволюции фронта должен быть инструмент, который позволяет на высоком уровне решать рутинные задачи, связанные с UX. Под UX я подразумеваю поведение элементов. Эдакий конструктор для создания input, select, datepicker, который предоставляет разработчику полную кастомизацию HTML, CSS. Но сохраняет основное поведение.
Дело в том, что UI меняется от проекта к проекту. А вот UX остаётся примерно одним и тем же. Но наши любимые фреймворки оперируют только UI-компонентами, и заточены только под это.
Почему автор не привёл свой вариант рефакторинга всех этих классов?
Давайте относиться с уважением к хорошим книжкам, которые не являются истиной в последней инстанции. Но задают неплохие принципы кодирования в достаточно простой форме.
Примеры в статье вырваны из контекста. Например SetupTeardownIncluder — это не идеал. Где Мартин сказал, что это супер классный кусок кода? Это результат рефакторинга, через разбиение толстых методов на маленькие. Который приводится, чтобы объяснить, что маленькие функции — это очень важно. Даже если не применять другие принципы из книги вовсе.
И вот мне интересно, какой процент из голосовавших читал эту книжку, и может сказать, что она являлась бесполезной тратой времени?
Что вообще вы ожидаете от книги? Волшебный секрет «Тайны драконы», который прибавит 200К к ЗП?
Я считаю, подобного рода статьи без весомых альтернатив, не больше чем оправданием школьника, который не стал учить физику, потому что «в жизни не пригодится». Но давайте поплюсуем за очередной холивар до 100?
(Рискую кармой, а не головой.)
Angular Language Service — постоянно тормозит для VSCode.
Короче, я считаю Angular прекрасным фреймворком. В нём заложено много здравых вещей — ReactiveForms, HttpInterceptors, RouteGuards, стили инкапсулируются для компонента автоматически, CLI прекрасно справляется со своими обязанностями, всё однообразно и со вкусом.
Но в плане удобства написания/сопровождения компонентов — он жёстко уступает React.
Я бы с радостью писал на React, в котором есть все основные фишки из Angular. Или наоборот, с радостью писал бы на Angular, если бы компоненты можно было так же легко писать/рефакторить.
Короче, жду Angulareact/Reangular. И поддерживаю сторонников обоих фреймворков.
На своём опыте убедился, что компонент React рефакторится одной командой IDE — extract function. В Angular нужно создать 3+ файла, и перетаскивать руками html, ts. Удобство — это немаловажный фактор.
Мне кажется, что стоит рассматривать React компоненты со всеми хуками как самостоятельный язык для рисования интерфейса. Как прокачанный HTML. Но отсюда следует, что логики в этих компонентах должно быть как можно меньше.
После манипуляций с провайдерами, компоненту вообще стало пофиг откуда организации берутся и как обновляются. Компонент теперь зависит только от Организаций, а не способа их получения. (Я предпочитаю использовать State + Resolver, чтобы на роут юзера перебрасывало только после загрузки данных. Но это дело даже не вкуса, а UX.)
Другое дело, что boilerplate не очень приятный получается вокруг провайдеров, но это отдельная проблема.