KA
Dragon3DGraff DGN
Господа, как считаете, Svelte JS вытеснит ангуляр?
Жырный наброс
Size: a a a
2020 January 01
DD
Да никакого наброса. Вчера наткнулся на статью про него и там было такое настроение
K
очень странное настроение, почему именно ангуляр, а не реакт и вью? Вот последнее на чтобы я подумал, так это ангуляр. Сейчас очень редко встретишь сайт в инете на втором ангуляре, он живет в корпоратах и вопросы величины бандла там не так актуальны. А вот возможность легко строить огромные динамические формы нужна сильно и тут свелт ничего не дает. Так что очень похоже на наброс
2020 January 08
RG
Всем привет) Подкиньте пожалуйста информации по angular по структуре проекта + ещё если можете поделитесь информацией по angular universal) Буду очень признателен) А то я выпал после 6-ой версии, писал на React, но понял что с angular ничего не может сравниться)
RG
Спасибо заранее, знаю что вы опытыные люди и вам не трудно накидать инфы)
GK
@romka9876 Angular-universal-ru
Общаемся на темы SSR, Angular Universal. GitHub: https://goo.gl/ozFA8i По вопросам Angular 4+, его экосистемы, TypeScript, NativeScript и т.д. @angular_ru См. также: @typescript_ru, @react_js, @nodejs_ru, @js_ru. Вакансии и поиск работы: @javascript_jobs
https://t.me/angular_universal_ru
Общаемся на темы SSR, Angular Universal. GitHub: https://goo.gl/ozFA8i По вопросам Angular 4+, его экосистемы, TypeScript, NativeScript и т.д. @angular_ru См. также: @typescript_ru, @react_js, @nodejs_ru, @js_ru. Вакансии и поиск работы: @javascript_jobs
https://t.me/angular_universal_ru
RG
В принципе по большей части был осведомлен)
K
Привет, сам я не так долго пишу на ангуляре, около полугода, могу перечислить основные моменты, которые я для себя за это время отметил
1) Разберись как работает стратегия детекции изменений OnPush и старайся везде использовать ее. Это улучшит быстродействие и заставит лучше продумывать архитектуру приложения. Если изначально не планировать архитектуру с учетом особенностей OnPush, то когда столкнешься с тем, что на дефолтной стратегии слишком много времени тратится на лишний чейндетекшн, то окажется, что это так просто не исправить и требуется переделка сервисов. Под OnPush сервисы становятся похожи на минимальный Redux, в сервисах будет куча subject, компоненты подписываются на эти subject(желательно через async pipe), сервис содержит в себе функции при вызове которых меняется содержимое subject и все подписанные компоненты получают последние изменения. Научись подключать профайлер для ангуляра и как замерять время на чейндетекшн.
2) Разберись хорошо с rxjs, особенно с тем, что касается отписок и hot/cold observables. Если забывать отписаться, то будут возникать утечки памяти, если не понимать разницу между hot и cold, то можно слать по несколько запросов вместо одного. Еще важно почитать про антипатерны rxjs и научится их обходить (к примеру не подписываться внутри подписки, а юзать mergeMap/switchMap)
1) Разберись как работает стратегия детекции изменений OnPush и старайся везде использовать ее. Это улучшит быстродействие и заставит лучше продумывать архитектуру приложения. Если изначально не планировать архитектуру с учетом особенностей OnPush, то когда столкнешься с тем, что на дефолтной стратегии слишком много времени тратится на лишний чейндетекшн, то окажется, что это так просто не исправить и требуется переделка сервисов. Под OnPush сервисы становятся похожи на минимальный Redux, в сервисах будет куча subject, компоненты подписываются на эти subject(желательно через async pipe), сервис содержит в себе функции при вызове которых меняется содержимое subject и все подписанные компоненты получают последние изменения. Научись подключать профайлер для ангуляра и как замерять время на чейндетекшн.
2) Разберись хорошо с rxjs, особенно с тем, что касается отписок и hot/cold observables. Если забывать отписаться, то будут возникать утечки памяти, если не понимать разницу между hot и cold, то можно слать по несколько запросов вместо одного. Еще важно почитать про антипатерны rxjs и научится их обходить (к примеру не подписываться внутри подписки, а юзать mergeMap/switchMap)
RG
Привет, сам я не так долго пишу на ангуляре, около полугода, могу перечислить основные моменты, которые я для себя за это время отметил
1) Разберись как работает стратегия детекции изменений OnPush и старайся везде использовать ее. Это улучшит быстродействие и заставит лучше продумывать архитектуру приложения. Если изначально не планировать архитектуру с учетом особенностей OnPush, то когда столкнешься с тем, что на дефолтной стратегии слишком много времени тратится на лишний чейндетекшн, то окажется, что это так просто не исправить и требуется переделка сервисов. Под OnPush сервисы становятся похожи на минимальный Redux, в сервисах будет куча subject, компоненты подписываются на эти subject(желательно через async pipe), сервис содержит в себе функции при вызове которых меняется содержимое subject и все подписанные компоненты получают последние изменения. Научись подключать профайлер для ангуляра и как замерять время на чейндетекшн.
2) Разберись хорошо с rxjs, особенно с тем, что касается отписок и hot/cold observables. Если забывать отписаться, то будут возникать утечки памяти, если не понимать разницу между hot и cold, то можно слать по несколько запросов вместо одного. Еще важно почитать про антипатерны rxjs и научится их обходить (к примеру не подписываться внутри подписки, а юзать mergeMap/switchMap)
1) Разберись как работает стратегия детекции изменений OnPush и старайся везде использовать ее. Это улучшит быстродействие и заставит лучше продумывать архитектуру приложения. Если изначально не планировать архитектуру с учетом особенностей OnPush, то когда столкнешься с тем, что на дефолтной стратегии слишком много времени тратится на лишний чейндетекшн, то окажется, что это так просто не исправить и требуется переделка сервисов. Под OnPush сервисы становятся похожи на минимальный Redux, в сервисах будет куча subject, компоненты подписываются на эти subject(желательно через async pipe), сервис содержит в себе функции при вызове которых меняется содержимое subject и все подписанные компоненты получают последние изменения. Научись подключать профайлер для ангуляра и как замерять время на чейндетекшн.
2) Разберись хорошо с rxjs, особенно с тем, что касается отписок и hot/cold observables. Если забывать отписаться, то будут возникать утечки памяти, если не понимать разницу между hot и cold, то можно слать по несколько запросов вместо одного. Еще важно почитать про антипатерны rxjs и научится их обходить (к примеру не подписываться внутри подписки, а юзать mergeMap/switchMap)
Это я и так все знал) Особых проблем не было, только освежить) Я с 6-ого ушел на react)
RG
Но спасибо все равно, я по большей части все эти вопросы на собесах спрашивал, ну и по формам ещё и про сервисы)
K
Да не за что, я сам с реакта ушел на ангуляр и первое время не мог понять, как же делать правильно, а в компании не особо парились над вопросами оптимизации и приходилось собирать инфу по форумам и статьям.
RG
Да не за что, я сам с реакта ушел на ангуляр и первое время не мог понять, как же делать правильно, а в компании не особо парились над вопросами оптимизации и приходилось собирать инфу по форумам и статьям.
а я наоборот с ангуляра на реакт и после реакта обратно да и плюс на angular universal!
2020 January 09
D
Всем привет) Подкиньте пожалуйста информации по angular по структуре проекта + ещё если можете поделитесь информацией по angular universal) Буду очень признателен) А то я выпал после 6-ой версии, писал на React, но понял что с angular ничего не может сравниться)
1) Можно попробовать начать с @ngrx. На самом деле очень помогает соблюдать качественную архитектуру проекта.
2) Ещё хороший паттерн — это разделение компонент на smart and dump.
3) Ну и общее для всех: ресёрч цели, требований, только понимая их можно выбрать нормальную архитектуру (для каких-то вещей нужно одно, для каких-то другое).
Ещё важно очень следовать stylegide: не создавать огромных компонент, использовать lint.
2) Ещё хороший паттерн — это разделение компонент на smart and dump.
3) Ну и общее для всех: ресёрч цели, требований, только понимая их можно выбрать нормальную архитектуру (для каких-то вещей нужно одно, для каких-то другое).
Ещё важно очень следовать stylegide: не создавать огромных компонент, использовать lint.
K
Ngrx говно
K
Такой вот вброс. Я переписала наш проект на ngrx, ngxs и Akita поочередно
A
а чу говно-то?
K
Невыносимый бойлерплейт
A
и в чем выигрыш xs/akita?