Angular — Хорошие практики в Angular.


Содержание

Команда Angular выпустила инструменты, упрощающие переход с AngularJS на Angular

Команда разработчиков JS-фреймворка AngularJS выпустила два пользовательских «помощника» — ngMigration Assistant и Forum. Инструменты позволяют узнать, какой переход с AngularJS на Angular является верным, как максимально упростить процесс и избежать ошибок.

ngMigration Assistant

ngMigration Assistant — инструмент командной строки, который анализирует любое, независимо от размера, приложение AngularJS и рекомендует оптимальный путь миграции. В помощь пользователю предлагается статистика, рассказывающая о сложности, размере, содержании и шаблоне приложения. На основе этих данных программа предлагает список понятных рекомендаций, упрощающих переход с AngularJS на Angular, с учётом размера и сложности кода.

Ниже — пример использования ngMigration Assistant для приложения AngularJS phone catalog. С помощью команды ngma , прописанной в директории, выполняется анализ и прописываются рекомендации.

Вначале инструмент показывает статистику имеющихся данных, а после — этапы подготовки к миграции на Angular.

ngMigration Forum

В новом сообществе ngMigration Forum собрана актуальная информация о путях миграции и инструментах, обеспечивающих переход с AngularJS на Angular. ngMigration Forum — место для обмена опытом, решения проблем и вопросов фреймворк-экспертам.

Последнее обновление Angular 6.1 вышло в конце июля 2020 года. В Angular была добавлена поддержка TypeScript 2.8 и 2.9, а также возможность настройки роутера на запоминание и восстановление положения прокрутки.

Angular — Лучшая практика структурирования модулей

Я новичок в angular, поэтому, пожалуйста, несите меня. На днях я читал статью/документацию, в которой был показан лучший способ структурирования модулей в вашем приложении, и можно только помнить об этом свободно.

Этот пример кода, скорее всего, будет неправильным, но дело в том, чтобы группировать контроллеры, службы и т.д. вместе в одном пространстве имен.

Может ли кто-нибудь расширить этот подход?

Организация корпоративного проекта

Способ организации моего проекта angular:

Альтернативная организация проектных организаций (упрощенная)

Средняя организация проекта (без модулей)

Простая организация проекта (как семя)

Используйте способ, которым должен быть организован ваш проект, и не выбирайте способ, который излишне усложняет ваш проект.

Этот подход предоставляется Angular Seed и его только один из способов orginize структуры приложения. Это полезно для отладки: если вы видите ошибку в некоторой службе, переходите к services.js и ловите ее.

Единственный оставшийся вопрос заключается в том, как подразделить контроллеры, директивы, службы и фильтры на модули. Angular Seed помещает фильтры, службы и директивы в отдельные модули, но для меня это кажется немного глупым. В зависимости от приложения, я был бы более склонным к организации модулей по страницам/маршрутам. С точки зрения производительности, на самом деле не имеет значения, как вы организуете свои модули, поэтому выберите любой метод, наиболее подходящий для вашего проекта.

Он также предлагает разные структуры приложений, где каждая директива или служба является одним отдельным файлом (см. статью выше).

Из Руководство по дизайну John Pappa AngularJS. Это становится стандартной структурой Angular для более крупных приложений.

Структура папок по функциям: Создавайте папки с именем для функции, которую они представляют. Когда папка растет, чтобы содержать более 7 файлов, начните рассматривать создание для них папки. Ваш порог может быть другим, поэтому при необходимости отрегулируйте его.

Почему?: Разработчик может найти код, определить, что каждый файл представляет с первого взгляда, структура плоская, как может быть, и нет повторяющихся или избыточных имен.

Почему?: Руководящие принципы LIFT охвачены.

Почему?: Помогает снизить нагрузку на приложение путем организации контента и поддержания их соответствия рекомендациям LIFT.

Почему?: Когда есть много файлов (10+), их легче найти с помощью последовательных структур папок и сложнее в плоских структурах.


Angular архитектура и лучшие практики

Angular Architecture and Best Practices

Узнайте, как создать надежную архитектуру приложений Angular, которую легко реорганизовать и поддерживать. Охватываемые темы включают в себя организацию кода / компонента / модуля, взаимодействие компонентов, RxJS, управление состоянием, лучшие практики и многое другое.

Существует много вопросов об основных концепциях Angular, в том числе: следуете ли вы лучшим практикам? Насколько легко будет поддерживать и делать рефакторинг приложение в будущем? Если вы запускаете новое приложение с нуля, какую архитектуру приложения следует использовать? В этом курсе «Angular архитектура и лучшие практики» вы узнаете об архитектурных концепциях, лучших практиках и о том, как решать некоторые из наиболее сложных задач, которые возникают. Во-первых, вы откроете для себя методы связи компонентов. Далее вы изучите управление состоянием и организацию кода. Наконец, вы ознакомитесь с общими рекомендациями, характеристиками производительности и многим другим. Когда вы закончите этот курс, у вас будут навыки и знания архитектуры приложений Angular, необходимые для продумывания процесса создания надежной архитектуры приложений, которую легко реорганизовать и поддерживать.

RxJS best practices in Angular

This article is all about the do’s and don’ts when it comes to writing reactive applications with RxJS in Angular applications. The best practices described in this article are based on personal experiences and can be assumed as personal opinions.

The topics we will tackle in this article are:

Note: We will refer to observables as streams in this article. Since the streams in this article use the $ -suffix, a short explanation. First of all, there is a lot of debate about the $ -suffix but I believe this should be a personal preference. The reason why I prefer to use it, is because I find it very easy to separate streams from regular objects. That being said, I would not consider it a best practice, just a personal choice.

Learning how to think reactive

Reactive programming is completely different than imperative programming. It requires us to make a certain mind switch. This mind switch is rather important if we want to benefit from RxJS completely. We want to stop thinking in specific actions and we want to start thinking in streams. It requires us to forget a part of practices that we already know (at least for a moment). In this article we can find some tips and practical examples on how to start thinking reactive in RxJS.

Pipeable operators

The first best practice is the use of pipeable operators. The operators being used in this article are pipeable. Since version 5.5 RxJS has introduced these so called pipeable operators which are easier to import than patch operators, and also have treeshaking advantages. More information about pipeable operators can be found here and here.

This example illustrates the difference between doing it the old way and the new way.

ASCII marble diagrams

Some developers tend to say: “Great code should be self-explanatory, writing documentation is something that we might want to avoid.” In some cases I would agree with that statement, but for complex RxJS code we might want to reconsider. Streams can become complex in the following scenarios:

  • When we take the lifecycle of streams into account, (how long do they live? when do they start living? what destroys them?)
  • When we start combining streams (every stream has a different lifecycle remember?)
  • When we subscribe multiple times or even subscribe after a while, or even never subscribe to them

marble diagrams are a cool way of visualising streams but it’s hard to put those marble-diagrams in our code right?! There is an ASCII variant of these marble-diagrams that we can use to describe and document our complex streams and how they interact with each other.

ASCII diagrams have more advantages then just documenting:

  • It gives us a graphic thinking model
  • It becomes easy to review someones code and validate to see if it really does what it’s supposed to be doing
  • Great to draw on a whiteboard before we start coding
  • You can type them in your IDE or editor before you actually start coding. (An easy way to trick your mind into thinking reactively)
  • We can use them to write unit tests as well: Checkout this awesome article

The concepts behind ASCII marble documentation are quite simple. Take this easy example for instance:

  • — (stands for a time frame)
  • a-z (are the values that are next’ed in the stream)
  • | (indicates that the stream has completed)
  • . (indicates that the stream will keep on living)
  • # (indicates that an error occurred)
  • ^ (indicates where we start subscribing (only for hot streams)
Цукерберг рекомендует:  Новичок - Помогите трудолюбивому новичку

Perhaps it’s time to check a real example and how we might document it:

Take a minute to let this sink into your brain, because this might be THE WAY of making a complex code snippets readable for anyone. When we take a look at this diagram, it’s fairly easy to comprehend what happens, and how every operator affects the new$ stream we can see above. There is no “one way of doing things” when it comes to writing ASCII marble-diagrams. You can put them where and how you want. As we want to do for all other documentation: keep it up to date!

Using pure functions


RxJS follows the concepts of functional reactive programming which basically means that we will use pure functions to create our reactive flow. A function is pure when:

  • It doesn’t mutate anything
  • It will always return the same value based on the same parameters
  • It doesn’t have any side effects. It can’t mutate state outside of the function

In the beginning it might seem pragmatic to use side effects, but that mostly means we aren’t fully thinking reactively. Therefore avoid side effects at much as possible.

Avoiding memory leaks

To consume a stream we need to subscribe to that stream. When we subscribe to that stream a subscription will be created. That subscription will keep on living until the stream is completed or until we unsubscribe manually from that stream. Managing subscriptions is very important and in a number of cases we will have to manually unsubscribe an existing subscription to avoid memory leaks. Take this example for instance:

To remove the memory-leak in this component we can keep track of the subscriptions by taking advantage of the ngOnDestroy() lifecycle hook of Angular:

However, when we are using a bunch of subscriptions, it can become quite dirty. Before, we talked about the fact that a subscription will live until we manually unsubscribe (like we just did in the snippet above), but also until the stream gets completed. A cool way to handle this issue is to use a Subject that we next in the ngOnDestroy() lifecycle hook of Angular:

Avoiding nested subscribes

Nesting subscribes is something that needs to be avoided as much as possible. It makes the code unreadable, complex, and introduces side effects. It basically forces you to NOT think reactively. Take this Angular example for instance:

The previous implementation is considered a bad-practice. It’s recommended to use higher-order streams like mergeMap or switchMap . Let’s have a look at this example:

Avoiding manual subscribes in Angular

To consume a stream we need to subscribe that stream, that’s simply how observables work. But what if a component needs values from 5 different streams… Would that mean, that we want to subscribe to all of these streams and manually map all the values to unique properties, just to make it work? That would suck, right?!

Angular has this super cool feature called the async pipe . It’s used to consume streams directly in the template The async pipe does 3 things for us:

  • It subscribes to the stream and passes the value to a component
  • It unsubscribes automatically when the component gets destroyed (removes a lot of unsubscribe logic)
  • Triggers change detection automatically

This means we don’t have to manually subscribe nor unsubscribe anymore. Which cleans up the code a lot. Let’s have a look at the cleaned up previous example:

If you are into React, I’ve created this lib called react-rx-connect that would solve this problem. It binds the streams to the state, and unsubscribes from them when the component gets destroyed.

Don’t pass streams to components directly

One of the most important aspects of software architecture might be the concept of decoupling pieces of code. Therefore we could consider passing streams to child components as a bad practice because it creates a very tight link between the parent component and the child component. They are no longer decoupled since subscriptions in the child component might trigger actions in the parent component. We never want the child component to be responsible of initiating data calls right?! That’s the task of the smart component. See the difference between smart and dumb components here. A component should always receive an object or value and should not even care if that object or value comes from a stream or not.

It would be better to handle the subscription in the parent component itself:

The responsibility of the component is clear. The user-detail is meant to be dumb and is completely decoupled from its parent.

There are however situations where we would like to create a stream from an input. In that case we could take a look at this library: ngx-reactivetoolkit

Don’t pass streams to services

Although, it might seem like a pragmatic solution to pass streams directly to services, it could be seen as a bad practice if we consider the decoupling again. By passing a stream to a service we don’t know what’s going to happen to it. The stream could be subscribed to, or even combined with another stream that has a longer lifecycle, that could eventually determine the state of our application. Subscriptions might trigger unwanted behavior. And after all, services don’t care that your components are using streams. Take this example for instance:

It would be better to use higher order streams for these situations. Use switchMap over mergeMap if possible, since it will unsubscribe the previous stream. The following example is better since all the RxJS logic is centralized in one place where the subscribing and unsubscribing happens: The smart component.

Sharing subscriptions


Since most streams are cold by default, every subscription will trigger the producer of these streams. The execution of the producer logic on every subscription, might not be what we want if we have multiple subscriptions. Eg. Subscribing to Angular its http.get() multiple times will actually perform multiple xhr calls. The following example will trigger the xhr call twice because numberOfUsers$ depends on users$ .

In those cases we might want to share the subscriptions. The following example uses the share() operator:

Sharing a stream makes it hot. This means that if we subscribe after the value is produced, we will miss that value. In that case we might want to use shareReplay(1) instead of share() . This will keep the last value in memory for us.

It’s a common mistake to share everything. We don’t always want to work with hot streams and sharing subscriptions comes with a small performance cost.Also, lazy streams have their advantages.

Angular also provides a great alternative that can reduce the sharing of streams to a minimum by using the async as else syntax.. Personally I would consider the use of this feature as a best practice. The following example reduces the number of streams, the number of subscriptions and gives us an easy way to show a loading indicator.

When to use Subjects

A Subject is both a hot observable and an observer at the same time. This gives us the opportunity to next values into the stream ourselves. Subjects tend to be overused by people that didn’t make the mind switch towards reactive programming yet.

Only use them when really needed, for instance it’s ok to use Subjects in the following scenarios:

When mocking streams in tests

When we want to create streams from outputs in Angular

When handling circular references

I’m not going to dive in this to deep, but Dominic Elm does an awesome job explaining this in this great article

For most other cases an operator or Observable.create might be enough.

Note: A BehaviorSubject is commonly used because it has a getValue() function. That would also be considered a bad practice. When we are trying to fetch a specific value it usually means we are not thinking reactive.

Clean code practices

Consistent code indentation and formatting can improve the readability of complex streams:

  • Align operators below each other
  • Extract into different streams when it becomes unreadable
  • Put complexer functionality in private methods (make the reactive flow clear)
  • Avoid the use of brackets for readability, that’s personal preference.

Angular embraces RxJS

We already saw a glimpse of why Angular is a framework that really embraces the use of RxJS. Therefore it’s recommended to use the functionality that Angular provides.

  • The ActivatedRoute has exposes a params stream.
  • The Http and HttpClient both return streams
  • The Form and FormControl both have a valueChanges property that returns a stream
  • The async pipe is an awesome feature that really helps us to use the streams in our templates
  • Using the ngOnInit() lifecycle function to initialize streams can help us for mocking purposes

Conclusion


Still here? Awesome! We learned a lot! If this article interests you, you might want to check out the “Advanced RxJS in Angular workshop” from Strongbrew, where me and Kwinten Pisman teach how to use advanced RxJS in real Angular applications.

Цукерберг рекомендует:  Visual studio - C# Visual Studio разница.

Angular Constant Best Practice

I have an angular constant which defines webservice end point

The problem is that for dev I have a different end point while staging and production its different. Every time I try to check in to git I have to manually reset this file.

  1. Is there any way git permenantly ignore this file but checks out the file while clone or checkout ?
  2. Is there any way I can make angular pickup file dynamically from something like environment variable.

NOTE: I don’t want to depend on server to do this, ie I don’t want to use apach SSI or any of those technologies as it will work only one set of servers.

Best Practices in Angular

This is a simple introduction to the best practices you can apply to your Angular project. Note that these best practices can be applied to other languages, but our focus in this article will be Angular with TypeScript.

What are best practices and readable code? This is not a science and my opinion can be different from yours. The aim of this article is to provide you with information and some tips which allow you to decide the best approach in each scenario. These tips received a lot of good feedback from conferences, colleagues, and clients. Thus, I hope I can help you.

Let’s start with a question that you should answer with total sincerity. Do your code reviews look like this?

If so, how do you make your code easier to read?

Simple! You only need to follow some advice that this article will give you. Again, this is the way I work and I love it. You can have a different opinion than me and be totally valid as well. So, let’s actually start this time. ��

Angular CLI

The Angular CLI is the best way to build Angular Applications. To install it globally, run the following command:

The CLI has scaffolding (aka schematics) tools for creating new projects and generating new code for you. However, this isn’t the main benefit. The main benefit of the CLI is the way it automates the build pipeline for both live development with ng serve , as well as for production code that you would ship down to browsers with ng build -prod .

LIFT Principle

Let’s take a look at the LIFT principle is.

This principle helps you to find code quickly. So, if you don’t use this principle, ask yourself: How quickly can you open and work in all of the files that you need in order to build a feature? My advice: Respect and use LIFT.

Meaningful Names

It’s very important that you give good names to methods, variables, and parameters.

This example of code shows that it’s hard to read and understand this method’s behavior. But if you look to the next example you note that it’s easier.

5 seconds rule

If you can’t understand in 5 seconds you probably need a refactor. Relax, I know that you are thinking that I am crazy, but when I say 5 seconds is a figure of speech. The goal is understanding that your code needs to be easy to get for everyone.

Organization for readability

  • The most important stuff goes first.

  • Properties followed by methods.
  • Grouped and sorted.
  • Consistent naming and spelling matter.
  • One item per file
    → One file must have only one component and the same is val >Single Principle Responsibility
    → Single >Symbol naming
    → Properties and methods must be camel case (e.g. currentUser).
    → Classes (components, services, directives…) must be upper camel case, called Pascal case (e.g. UserComponent).
    → Components and services should have the respective suffix on the name.

Give a blank line before the import files from own app

This give us an easy way to identify the external and app files

  • Small Functions
    → Small functions are better to read and faster to understand the purpose. If your function has more than 10 lines you need to ask yourself if it would be better to break it into smaller functions. This might be hard to do, but unfortunately in the real world, we see a lot of huge functions that are hard to read due to the size and complexity. In my opinion, this is an important practice that everyone should follow.

Prov >Self-describing code
  • Replace magic strings with constants (code reuse)
  • Explain in code, not in comments
  • Comments must be readable and maintained
  • Avoid comments when:
    → Explains “What” the code does.
    → Outdated and incorrect (wrong comments are worse than no comments).
    → Instead, have a well-named function.
    → THE CODE NEVER LIES, COMMENTS SOMETIMES DO.
  • Use comments when:
    → Explain “Why” you do that.
    → Explaining consequences.
    → API Docs.
  • Angular components best practice

    • Prefixing your components is recommended. If you use Angular CLI to create the component, by default the CLI will prefix your component like this: selector: ‘app-component-name’ . You can dec >DIGITALSTORE’ you can put ‘ds’ as prefix. (‘ds-component-name’).
    • Separating the HTML, CSS and TypeScript files is also a good practice. This allows us to have more organized and readable files.
    • Inputs
      → You can declare the input decorator ins >

    → For the output decorator, the rule is exactly the same.


    • Delegating complex logic to services
      → We want our components to be as simple as possible. This means if our component needs to do some complex logic we need to dec >Component member sequence
      → Public methods must be declared before private ones. This is easier to read or find, because in this way we can prevent private methods from getting lost in the m >
    • Implementing life cycle hook interface
      → We must declare the life cycle hook interfaces to alert us if we are not using the interface that we declare. For example, when we use the ngOnInit if we declare the implementation like this:

    then if we do not create this we will receive an alert telling us that we are missing the ngOnInit :

    Angular Services Best Practices

    • Make services as injectable
      → This is necessary only when a service injects another service, but is recommended to use every time, because you never know when the service will need to inject another one (dependency injection) and it will be hard to remember that we dec >

    → We can use the @Inject ins >@Injectable but this is not recommended unless it is needed. For example, if the service that you are injecting is not using the service datatype as this service. This requirement is rare and usually we will not need this. The recommendation is to use @Injectable always. Also, we will need more code because we will need to do this for all the parameters.

      Using services for data retrieval
      → Like we talked above, you should use the Single Principle Responsibility. Our component must call a service to get some data. For example, we can directly call an API in the component… ok the code is simple, but to respect this principle it’s a best practice to put this logic in a service. The service can call an API, localStorage, or also a dummy structure that helps us during development, but for our component this should be transparent. If we need to update the call in our service, the component remains the same. The component shouldn’t have to think how to get the data and it shouldn’t have to know if the data comes from an API or localStorage. The responsibility of the component is only to know that he had the necessity to call the service. The service has the duty to know where and how to get the data. So, please, avo >To improve the performance of your app I recommend that you consider the use of Ahead-of-time compilation, lazy loading, and paying attention to bundle sizes. In my next articles I will go deeper into these, so stay tuned!

    Курс по Angular

    Этот онлайн-курс посвящён профессиональной разработке веб-приложений с помощью Angular.

    Запись на курс

    Следующий набор на обновленный курс планируется через 2 недели.

    Вы можете запросить уведомление:

    Программа

    Курс даст возможность быстро и качественно начать создавать приложения с использованием современного фреймворка — Angular, отлаживать уже существующие приложения и проводить их рефакторинг. В процессе прохождения курса мы шаг за шагом будем рассматривать составные части фреймворка и его модули и применять эти знания для решения практических задач. Вы хорошо разберетесь в специфике Angular и библиотек которые его окружают.

    Вы будете получать актуальную информацию, писать правильный код, показывать его преподавателю, получать обратную связь и советы, и затем – двигаться дальше.

    Мы внимательно следим за развитием Angular и будем использовать самые новые подходы и версии как фреймворка так и библиотек.

    Курс можно условно разделить на три части.

    Детали программы смотрите далее.

    Цукерберг рекомендует:  Ajax - Загрузка формы без перезагрузки страницы (ajax)

    Основные темы программы

    Первая часть курса

    Быстрый старт с Angular

    • Знакомство с angular-cli и экосистемой.
    • Разработка простого компонента, инкапсуляция стилей.
    • Специфика синтаксиса шаблонов Angular.
    • Интерполяция и связывание.


    Компоненты, Директивы, Пайпы

    • Вложенные компоненты и передача данных в компонент и из него.
    • Вывод контента с помощью ng-content (content projection).
    • Доступ к елементам шаблона через ViewChild/ContentChild.
    • Применение директив из коробки (ngIf, ngClass, ngFor..).
    • Pipe и фильтрация данных. Impure pipes.
    • Структурные директивы. ViewRef/TemplateRef.

    Сервисы, работа с сетью и внедрение зависимостей

    • Концепция и способы создания провайдеров.
    • Примеры сервис-провайдеров из коробки.
    • Работа с http протоколом. HTTPClient.
    • Передача данных между копонентами.
    • Создание динамических компонентов.

    Формы и навигация

    Работа с формами

    • Работа с формами от шаблона (template-driven forms).
    • Работа с формами от компонента (reactive forms).
    • Единицы постороения форм FormControl, FormGroup, FormArray.
    • Синхронная и асинхронная валидация данных.
    • Создание своего сложного элемент ввода. Работа с ValueAccessor.

    Навигация и маршрутизация

    • Определение состояний, вложенные и абстракные состояния
    • Сервис для доступа к параметра состояния и передача данных в состояния.
    • Стражи(guards) роутера. Аунтификация и контроль доступа к состояниям
    • Множественное представление (для сложных состояний)
    • Ленивая загрузка(lazy loading) и предзагрузка модулей

    Третья часть

    Redux-архитектура для более сложных приложений

    • Основные концепции Redux
    • Платформа NgRX и ее модули
    • Обработка асинхронных событий. Эффекты
    • Агрегация даных. Cелекторы
    • Отладка приложения

    Тесты

    • Unit-тесты для сервисов
    • Специфика тестирования при использовании HttpClient
    • Unit-тесты для компонентов
    • Unit-тесты для директив
    • e2e интеграционные тесты

    Внутренности фреймворка Angular

    • ZoneJS/ NgZone для удобного управления асинхронностью
    • Механизм обновления состояния (change detection). Статегия OnPush
    • Погружение в исходный код фреймворка


    Как проходит обучение?

    Курс включает в себя 10 насыщенных занятий. Первая встреча традиционно является собранием и не входит в основной блок.

    На каждом занятии мы изучаем что-то новое. Каждый смысловой модуль будет заканчиваться домашним заданием.

    На протяжении всего курса вы можете работать над проектом, который является веб-приложением включающим в себя все разбираемые темы.

    Чтобы получить от курса максимум результата, нужно не только слушать, но и делать что-то дома, а затем – показывать преподавателю. Только так, постепенно, с обратной связью от преподавателя, создавая проект на Angular, вы действительно разберётесь, что и как.

    Результат обучения

    1. Вы знаете, как быстро сделать прототип проекта, а после чего превратить его в большое структурное веб приложение, стабильно работающее и не имеющее проблем с производительностью, легко расширяемое и поддерживаемое.
    2. Вы хорошо понимаете тонкости компонентного подхода Angular. Можете создавать и отлаживать сложные компоненты (приложения) и решать любую бизнес задачу.
    3. Вы знаете как использовать разные архитектурные подходы для построения Angular приложений.
    4. Вы эффективно работаете как с фреймворком, так и со всей Angular экосистемой.
    5. Понимаете структуру исходного кода и ориентируетесь в нем.

    Гарантия

    • Если объяснения будут вам непонятны
    • Если курсы не дадут вам новых знаний и умений
    • Если вы не сможете подключиться к системе онлайн-обучения

    …то вы сможете получить деньги назад.

    Для этого достаточно не позже окончания первой недели курса написать, указав причину из этого списка и что именно вас не устраивает, и тогда ваше участие будет прекращено, а вы получите деньги обратно, удобным для вас способом.

    Преподаватели

    Занимаюсь современной frontend-разработкой с использованием Angular с 2013 года. С 2020 года веду обучение Javascript, Typescript и Angular. Также имею большой опыт преподавания математических дисциплин в ВУЗе.

    Также работаю как Team/Tech Lead в разработке enterprise-приложений для CША, а также приложения для работы с блокчейн, например система для рекламы, основанная на цифровой валюте cresttoken.com. Предпочитаю стек MEAN.


    JavaScript разработчик и консультант, спикер, активный участник фронтенд сообщества. Занимаюсь программированием более 14 лет(из них 9 лет страстно увлечен JavaScript, 6 лет исследований и экспериментов с Angular).

    Angular — Лучшая практика структурирования модулей

    Я новичок в angular, поэтому, пожалуйста, несите меня. На днях я читал статью/документацию, в которой был показан лучший способ структурирования модулей в вашем приложении, и можно только помнить об этом свободно.

    Этот пример кода, скорее всего, будет неправильным, но дело в том, чтобы группировать контроллеры, службы и т.д. вместе в одном пространстве имен.

    Может ли кто-нибудь расширить этот подход?

    Организация корпоративного проекта

    Способ организации моего проекта angular:

    Альтернативная организация проектных организаций (упрощенная)

    Средняя организация проекта (без модулей)

    Простая организация проекта (как семя)

    Используйте способ, которым должен быть организован ваш проект, и не выбирайте способ, который излишне усложняет ваш проект.

    Этот подход предоставляется Angular Seed и его только один из способов orginize структуры приложения. Это полезно для отладки: если вы видите ошибку в некоторой службе, переходите к services.js и ловите ее.

    Единственный оставшийся вопрос заключается в том, как подразделить контроллеры, директивы, службы и фильтры на модули. Angular Seed помещает фильтры, службы и директивы в отдельные модули, но для меня это кажется немного глупым. В зависимости от приложения, я был бы более склонным к организации модулей по страницам/маршрутам. С точки зрения производительности, на самом деле не имеет значения, как вы организуете свои модули, поэтому выберите любой метод, наиболее подходящий для вашего проекта.

    Он также предлагает разные структуры приложений, где каждая директива или служба является одним отдельным файлом (см. статью выше).

    Из Руководство по дизайну John Pappa AngularJS. Это становится стандартной структурой Angular для более крупных приложений.

    Структура папок по функциям: Создавайте папки с именем для функции, которую они представляют. Когда папка растет, чтобы содержать более 7 файлов, начните рассматривать создание для них папки. Ваш порог может быть другим, поэтому при необходимости отрегулируйте его.

    Почему?: Разработчик может найти код, определить, что каждый файл представляет с первого взгляда, структура плоская, как может быть, и нет повторяющихся или избыточных имен.

    Почему?: Руководящие принципы LIFT охвачены.

    Почему?: Помогает снизить нагрузку на приложение путем организации контента и поддержания их соответствия рекомендациям LIFT.

    Почему?: Когда есть много файлов (10+), их легче найти с помощью последовательных структур папок и сложнее в плоских структурах.

    Angular — Хорошие практики в Angular.

    5412 просмотра

    1 ответ

    363 Репутация автора

    Я только изучаю Angular 5, и я остановился на лучшей практике Master / Detail. В Angular официальном учебном пособии находится раздел Master / Detail (здесь: https://angular.io/tutorial/toh-pt3 ) со следующим шаблоном:

    • Мастер компонент (который содержит список героев)
      • Детальный компонент, используемый внутри мастера (который является деталью выбранного героя)

    Этот пример работает без настройки маршрута, поэтому при выборе героя не нужно изменять URL-адрес. Вся логика работает внутри компонента Master.

    На шаг позже есть раздел Маршрутизатор (здесь: https://angular.io/tutorial/toh-pt5 )

    Пример маршрутизации использует компоненты List и Detail при маршрутизации на одном уровне, и оба работают отдельно со своей собственной логикой.

    Можно ли с любым угловым соглашением объединить эти два образца? Моя цель — создать HeroesContainer, который содержит два компонента — Список героев и Деталь героев.

    • Контейнер героев
      • Список героев (который содержит список героев)
      • Компонент детализации героя (который является деталью выбранного героя)

    Маршрутизатор тогда установлен в:

    И затем, если NO ID не маршрутизируется, то HeroDetailComponent скрыт.

    Если ЛЮБОЙ идентификатор маршрутизируется, HeroesListComponent скрыт.

    Сохранит ли Angular состояние компонента при переходе к тому же компоненту? Вариант использования: пользователь выполняет сортировку и фильтрацию в списке, открывает героя (перейдите к деталям) и затем нажимает кнопку «Назад». Я использовал шаблон, описанный выше в AngularJS, чтобы добиться этого.

    Angular — Лучшая практика для структурирования модулей

    Я новичок в угловой, поэтому, пожалуйста, потерпите меня. На днях я читал статью / документацию, в которой рассказывалось о наилучшем способе структурирования модулей в вашем приложении, и могу только помнить об этом свободно.

    Этот пример кода, скорее всего, будет неправильным, но цель состояла в том, чтобы сгруппировать контроллеры, службы и т. Д. Вместе в одном пространстве имен.

    Может ли кто-нибудь расширить этот подход?

    3 ответа

    Организация корпоративного проекта

    То, как я организовываю свой угловой проект:

    Альтернативная организация проекта предприятия (упрощенно)

    Средняя организация проекта (без модулей)

    Простая организация проекта (как семя)

    Используйте способ организации вашего проекта и не выбирайте способ, который излишне усложнит ваш проект.

    Этот подход предоставляется Angular Seed и его одним из способов организации структуры приложения. Это полезно для отладки: если вы видите ошибку в каком-либо сервисе, вы идете в services.js и ловите ее.

    Единственный оставшийся вопрос — как подразделить контроллеры, директивы, сервисы и фильтры на модули. Angular Seed помещает фильтры, сервисы и директивы в отдельные модули, но мне это кажется немного глупым. В зависимости от приложения, я был бы более склонен упорядочивать модули по странице / маршруту. С точки зрения производительности, на самом деле не имеет значения, как вы организовываете свои модули, поэтому выберите любой метод, который лучше всего подходит для вашего проекта.

    Он также предлагает другую структуру приложения, в которой каждая директива или служба представляют собой отдельный файл (см. Статью выше).

    Из Руководства по стилю AngularJS Джона Паппы . Это становится «угловой стандартной структурой» для больших приложений.

    Структура папок по элементам : создание папок, названных для элемента, который они представляют. Когда папка будет содержать более 7 файлов, начните создавать папку для них. Ваш порог может отличаться, поэтому отрегулируйте по мере необходимости.

    Почему ?: Разработчик может определить местонахождение кода, определить, что представляет каждый файл с первого взгляда, структура плоская, как может быть, и нет ни повторяющихся, ни избыточных имен.

    Почему ?: Руководства LIFT все покрыты.

    Почему ?: Помогает избежать загромождения приложения путем организации контента и поддержания его в соответствии с рекомендациями LIFT.

    Почему ?: Когда есть много файлов (более 10), их легче найти с согласованной структурой папок и сложнее в плоских структурах.

    Понравилась статья? Поделиться с друзьями:
    Все языки программирования для начинающих