Comments 18
Хорошая статья и написана с юмором. Я сам не люблю Angular и пишу на Vue/Nuxt +Node но ваша статья мне понравилась.
Красивая популяризация Angular.
ps:
Хотя по личным понятиям, сайт-визитка должен использовать что полегче.
Но разве это сайт-визитка? Выглядит скорее как pet-project, чтобы показать свои скилы в дальнейшем. Визитка всё-таки должна представлять самого автора, кто он, откуда, контакты.
Слышал, такое мнение, что у Angular получается большой размер бандла - поэтому для сайтов, где планируется SEO-оптимизация, отдают предпочтение NextJS (React). Подскажите, пожалуйста, действительно ли это актуально, и какой размер бандла у вас получился?
Не сжатая будет примерно 850 kB для показа главной страницы. Сжатая версия будет примерно 200 kB.
Состав Main.js на 618 kB
angular core - 118.92 kB
angular router - 68.86 kB
angular animation - 60.4 kB
angular common 58.96 kB
angular material - 53.58 kB
angular cdk - 37.24 kB
angular forms - 32.77
angular platform - 24.8
ngrx - 48.39 kB
rxjs - 32.18 kB
hammerjs - 20.64 kB
custom core - 50 kB
localization - 5.47 kB
app - 2.41 kB
Есть практики, которые позволяют минимизировать объем итогового билда. Но это нужно отдельно настраивать сборку и немного менять приложение.
В целом, если сравнивать с React, то Angular в дефолтных настройках поиграет из-за большого количества используемых библиотек.
Весьма интересно, спасибо за статью.
Скажите, а вы пробовали другие стейт менеджеры для angular кроме ngrx?
Я разбирал одно время ngxs, но в продакшне никогда не использовал. Akita мне не зашла концептуально, но это было давно. Возможно если посмотреть сейчас, то может пересмотрю свое отношение к Akita.
Одно время работал с vuex в Vue, но тоже давненько.
Сейчас, немного глубже погрузившись в ядро Angular, я хочу попробовать реализовать всю необходимую логику приложения без Redux, а с помощью сервисов Angular и правильной организации потоков. Основная цель - сравнить производительность.
Просто многие хейтят Ngrx за громоздкость, но под капотом, там много оптимизации. И если сильно не жестить с вложенностью объектов и делать простые мутации state, то в целом, все не так грустно.
Думаю у вас достаточно свежая нода для поддержки async iterator.
Предлагаю немного видоизменить функцию getServerData.
Следующую конструкцию:
const req = https.request(options, (res) => {
let body = '';
res.on('data', (chunk) => {
body += chunk;
});
res.on('end', () => {
const response = JSON.parse(body);
if (response.values) {
for (const product of response.values) {
data += getSitemapUrl({...});
}
}
cb(data);
});
});заменить на:
const req = https.request(options, async (res) => {
let body = '';
for await (const chunk of res) {
body += chunk;
}
const response = JSON.parse(body);
if (response.values) {
for (const product of response.values) {
data += getSitemapUrl({
loc: `/product/${product[0]}`,
lastmod: new Date().toISOString(),
changefreq: 'daily',
priority: '0.8',
});
}
}
cb(data);
});
Годная статья, спасибо автору за подробнейший рассказ и погружение в процесс разработки Angular SSR-friendly приложения. Тоже не поворачивается назвать этот проект сайтом-визиткой. Скорее полноценный пет-проджект с демонстрацией многих аспектов современной веб-разработки.
У меня парочка комментариев осталось после прочтения:
Маппинг
FormControlизFormGroup;
Что здесь имелось в виду?
Контроль
observable, которые не должны уходить в бесконечный цикл.
Тут стоит также отметить, что если в каком-то месте это просочилось в SSR в бизнес-логике, то отловить некорректное поведение можно будет только в рантайме, которое будет выглядеть как "повисший" процесс ноды без каких-либо намеков на ошибки в логах. Прям боль. ?
При создании FormGroup, все элементы формы будут иметь тип AbstractControl, а не FormContol. Например:
const form = new FormGroup({
field: new FormControl(),
});
// fieldControl - AbstractControl
const fieldControl = form.get('field');
// или так fieldControlNext - AbstractControl
const fieldControlNext = form.controls['field'];Это иногда важно, особенно если включить strict режим.
Типизация форм должна появиться в следующем релизе - очень ждем.
А то, может быть много ошибок со значениями форм и их явно стоит проверить на соответствие типа:
const form = new FormGroup({
field: new FormControl(null, [Validators.required, Validators.pattern(/\d+/)]),
});
form.patchValue({ field: '123' });
console.log(form.valid); // Выведет true
console.log(form.value); // Выведет { field: '123' }
Выше приведена валидация шреденгера. Она как бы есть, но и ее как бы нет.
а есть варианты локализации сео френдли в случае ngx-translate + po loader?
Все зависит от того, что вы подразумеваете от "сео френдли". В ngx-translate, на сколько я помню, нет проблем с мультиязычностью и seo.
Если вы про то, чтобы вынести переводы в "отдельный файл", то это тоже возможно.
Вопрос про то как подружить angular universal + ngx-translate - есть какой-то пример?
Так в обычном режиме все работает нормально. А вот как сделать доступным для индексации такой вариант - мне не очень понятно. Выбор языка происходит либо по инпуту либо из куков либо из Accept-Language хедера в порядке приоритета.
Как я делал сайт визитку на Angular