Demian Smith

Вопрос из разряда, зачем изучать математику, если есть калькулятор)))

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

А так же, создание просто сайта визитки, магазина при помощи конструктора, это удобно и часто быстро. НО!!!

Всем этим нужно заниматься, далеко не все хотят этим заниматься, изучать веб и т.п. Проще отдать деньги и сказать, как я хочу, чем убить огромное кол-во времени.

Все могут сами что-то делать для себя, не тратя свои средства, но время и силы, потраченные на создание лично, далеко не всегда равны тому, что бы просто взять и купить или заказать

у одного пять букв в названии, у другого три

освойте js, и подобные вопросы перестанут вас волновать

В ноде запускается простенький веб-сервер, который отдаёт реакт-приложение браузеру.
Реакт работает на клиенте, он никак не связан с нодой.

По довольно распространённому соглашению, все параметры после двойной черты считаются позиционными (чаще всего это имена файлов). git придерживается этого соглашения.

Например кто-то случайно создал файл с именем -n, а вы хотите вывести все файлы в папке командой cat

$ ls -l
total 8
-rw-rw-r-- 1 lynn lynn 6 Apr 19 12:34 file1
-rw-rw-r-- 1 lynn lynn 6 Apr 19 12:33 -n

если просто выполнить cat *, то получится странное:

 $ cat *
     1	file1

потому что bash раскрыл звёздочку и получилась команда can file1 -n, т.е. вывести файл file1 с нумерацией строк.
А вот так всё выведется правильно:

$ cat -- *
file1
a
b
c

Потому что раскроется в cat -- file1 -n, но по соглашению, после -- не может быть ключей команды, только имена файлов.

Конкретно в git есть ещё более строгое соглашение, по которому параметры после -- могут быть только путями.
Например если у вас есть файл test и ветка test, то будет так:

$ git branch 
* master
  test

$ git status
On branch master
Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git checkout -- <file>..." to discard changes in working directory)

	modified:   test

no changes added to commit (use "git add" and/or "git commit -a")

$ git reset test
fatal: ambiguous argument 'test': both revision and filename
Use '--' to separate paths from revisions, like this:
'git <command> [<revision>...] -- [<file>...]'

$ git reset -- test
Unstaged changes after reset:
M	test

@Directive({
  selector: 'textarea[appText]'
})
export class TextDirective {
  @Output() public hasScrollBar = new EventEmitter<boolean>();

  constructor(private readonly elRef: ElementRef<HTMLTextAreaElement>) {}

  @HostListener('change')
  @HostListener('input')
  public changes() {
    const elem = this.elRef.nativeElement;
    this.hasScrollBar.emit(elem.clientHeight < elem.scrollHeight);
  }
}

<textarea appText (hasScrollBar)="print($event)"></textarea>

ng-container не создает html-элемента, ловить событие click не на чем.
Если у вас таблица то логичней сделать

<tr *ngFor="let ware of task.wares" (click)="deleteWares(ware)">
<ng-container></ng-container>
</tr>

Потому, что это не круг, а овал. Вот я начертил квадрат поверх, и видно, что высота у вашего овала меньше чем ширина

Нет, не нарушает. Композиция порождает зависимость, а не расширяет ответственность. Если зависимый класс соблюдает D, а класс зависимости соблюдает I и L, то всё в порядке.

Тип лучше указывать не через конструктор примитива, а через тип string (тот что из TypeScript, с маленькой буквы).
url: String = '';

Вы не используете возможности RxJS. Этот кусок кода можно сделать иначе:

ngOnInit() {
    this.Preview.url
      .subscribe(new_url => this.url = new_url);
  }

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

public previewUrl$: Observable<string>

ngOnInit() {
    this.previewUrl$ = this.Preview.url
}

<div class="preview" *ngIf="(previewUrl$ | async) as url">
  <img class="preview__img" [src]="url">
</div>

В сервисе так же (https://github.com/BuG1K/task/blob/master/src/app/... вы подписались на http запрос и дальше не используете RxJS. Все манипуляции можно было сделать в tap/map и вернуть поток, с которым удобно работать.

вопросы у вас философские, на каждый можно отвести часы обсуждения

Полноценный CI/CD поднимать не вижу смысла ввиду размеров

вы ж все равно собираетесь какие-то скрипты мутить и чото выдумывать,
какая разница это будут крон скрипты на сервере или джоба в дженкинсе? по-скорости написания - одно и тоже будет. так что по-моему размер тут не имеет значение
единственное что имеет значение - насколько явно у вас описан процесс(алгоритм) билда/разворачивания приложений
с этой точки зрения мое видение примерно такое:

1) git не есть инструмент для развертывания по, git лишь для версионирования кода
и по-идее результатом вашей работы должен быть не код в гитхабе, а какой-то вменяемый артефакт, готовый к деплою (docker-image, pip пакет, npm пакет, deb пакет, jar, war, zip в крайнем случае, и тд и тп). Если производить артефакты то вопрос с тегами отпадет сам собой - у вас будет артефакт какой-то версии и все
сервер не должен знать ни про какие гиты и ни про какие-то теги в нем
Здесь я бы рекомендовал паковать все в докер-имеджи хотя бы только потому, что сервер в итоге не будет знать ничего о зависимостях приложения, нужных библиотеках, ниочем вообще, вам нужно установить только докер
Огромное преимущество использование докера - в Dockerfile вы вынуждены волей/неволей описать точно и явно все шаги требуемые для установки приложения. И что самое замечательное - это все будет храниться в том же репозитории, под контролем гит - шикарно.
Артефакты желательно хранить в каком-то артефактории,
но если реально все просто - то можно хранить несколько последних версий прямо на сервере в какой-нибудь папочке

2) как только вы получили артефакт - его можно деплоить
неплохо было б знать особенности вашего проекта, но грубо говоря допустим что достаточно его зааплоадить на сервер, положить в нужное место
опять же с этим дженкинс справится на ура и займет у вас это все дело 10 минут . Если вы опишете логику в Jenkinsfile вы выиграете еще раз потому что процесс развертывания(алгоритм) будет описан опять же ЯВНО. И будет тоже под контролем гита. (Jenkins должен знать только в каком репозитарии и в каком месте ему искать Jenkinsfile)
Если же вы будете крутить какой-то спрятанный cron скрипт на сервере - о нем никому ничего не будет известно. Поверьте уже через короткое время все это дело начнет усложнятся, что-то забудется, что-то измениться и это все вместе больно ударит вас по яйцам.

В чем еще преимущество такого подхода: если вам нужно сделать roll-back на предыдущую версию вам не нужно собирать проект заново выкачивая все с гита, ведь у вас есть предыдущие артефакты, ролбек в таком случае вообще не проблема - просто указываем предыдущую версию артефакта и деплоим еще раз и все

3) Env Variables
когда приложение стартует - считывает все что ему нужно из переменных окружения
деплой джоба может каждый раз эти переменные устанавливать перед тем как деплоить - это было бы тоже круто потому что вы сделали бы это знание так же явным

Итого имеем
- логика сборки проекта описана в Dockerfile и находится под гитом
- логика деплоя находится в Jenkinsfile и находится под гитом, и что самое главное является кодом (Jenkinsfile пишем на груви, для простых вещей вам понадобиться 30 минут изучения и все)
- на сервере мы ничего не устанавливали совершенно кроме самого докера
- мы храним несколько версий нашего приложения на всякий случай и можем быстро откатиться не прибегая к гиту вообще
- сервер не знает ничего о гитах
- на сервере нет НИКАКОЙ дополнительной логики по разворачиванию вашего приложения
- имея все это очень легко добавлять другие сервера для деплоя - что нам нужно - грубо говоря указать другой айпи и набор env variables к нему ( если они конечно отличаются)

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