Nikita

Потому что он не в функциональном компоненте?

import React, {useState, useEffect, Fragment} from 'react';
const [OperationsList, setOperationsList] = useState([]); // ← ← ←
import {apiGetOperationsLoan} from '../api/Api';

Вы поймали майнер.
Качайте Live USB Касперского, Доктора Веба и сканируйте ПК.

Все эти страшные слова - они на самом деле всегда про одно и то же - про связность. Когда ты хардкодишь внутри класса вызов какого-то конкретного сервиса - ты намертво к нему привязываешься. И чтобы поменять сервис на другой, ты будешь вынужден поменять код класса. Окей, поменял. И тут же в другом месте, где этот же класс использовался, что-то сломалось! И что теперь? Делать два класса, которые различаются одной строчкой? Нет конечно. А как тогда использовать один и тот же класс для обработки разных входящих данных (или одних и тех же данных, но разными способами)? Сделать его поведение изменяемым. То есть сделать изменяемыми те инструменты, которыми он пользуется - т.е. его зависимости.

Поэтому все зависимости обычно передаются через конструктор (и поэтому и называются инъекция зависимостей.)

Таким образом мы можем менять поведение класса, не меняя его код

Но тут надо понимать, что всё это работает только при правильном применении ООП. А точнее просто при применении ООП. Потому что 98% "ООП" кода, который пишется на РНР - это голимая процедурщина, даже если она обёрнута в классы и методы. Если у тебя метод класса представляет из себя стену кода, которую ты тупо перенёс из файла, инклюдившегося в любимое похапешное спагетти - то это не ООП. Это та же процедурщина, вид сбоку. И смысл использования dependency injection ты с ним не почуствуешь. Будешь конечно применять, но в качестве карго культа - потому что тебе это на тостере написали.
А вот когда твой код начнет становиться действительно объектным - тогда стразу станет понятнее.

Похожим на сервис локатор является сервис- или DI-контейнер. Используемый вручную, он является тем же самым сервис локатором. Поэтому вручную его никогда не надо вызывать - что и запрещается в симфоневских конроллерах - а только для автоматического создания классов. В МВЦ у тебя ведь очень многие объекты создаются автоматом - сущности, контроллеры. И вот для того, чтобы при автоматическом создании экземпляра класса у тебя были на руках все требуемые сервисы - и нужен контейнер.

Соотвтственно, ответ на вопрос "что использовать?" очень простой:
- при ручном создании экземпляра объекта, все зависимости передавать в него через конструктор, а не получать "из воздуха" в коде.
- при автоматическом создании экземпляра объекта, использовать dependency injection container

В этим смысле очень полезно освоить Симфони - строгий фрейворк, в котором нет сервис локатора и в котором запрещено пользоваться контейнером напрямую.

Это невозможно и более того противозаконно.

Недавно была похожая задача. Не один объект сделан на оптике, но с GPON не сталкивался и когда стал погружаться в тему, очень удивился, что такое существует, а я об этом не слышал вообще ничего! Основной вопрос был тот же - в чём отличие от обычного соединения точка-точка посредством SFP. Как оказалось, всё просто. Смысл GPON в том, что применяются оптические сплиттеры, например такие: https://shop.nag.ru/catalog/03493.opticheskie-deli..., которые делят одно волокно на несколько, причём такой фокус можно повторять, т.е. поделить одно волокно на 4, потом каждое из четырёх ещё на 8 или на 16 и т.д., но не бесконечно, само собой. Минус в том, что пропускная способность тоже делится. Самое главное - на концах такой линии используется специальное оборудование. Лучше показать на примере. В начале линии, например, такой девайс: https://shop.nag.ru/catalog/03903.gpon--gepon/3375... и на концах, вот такие: https://shop.nag.ru/catalog/03903.gpon--gepon/3375.... Но, возможны варианты в зависимости от поставленной задачи.
Менеджер посоветовал ещё посмотреть вебинар: https://youtu.be/gGmhPnstp8k. Там много воды про коммерческую составляющую и для меня это было лишним, но и полезной инфы хватает.

laravel нежели на CMS- битрикс?

- как можно сравнивать продукт с фреймворком. Если взять любую доступную админку на Ларавел, то она даже близко не превзойдёт админку Битрикс.
Если уж сравнивать тогда ларавел с коммерческим фреймворком Битрикс. По техническим моментам фреймворк битрикса скорее всего уступает ларавел, но как это упрощает и решает задачи бизнеса?

прикрутить личный кабинет пользователя, с графиками + vue

- на самом деле Битрикс это коммерческий фреймворк, а админка это продукт на его основе. Если вы будете писать новый функционал, которого нет в продукте, что в Битриксе, что в ларавел вы будете это делать с нуля, писать и там и там на фреймворке.

1) Удобная система ( админ панель) с быстрой тех поддержкой

- это реальный большой плюс, который сокращает расходы на поддержку проекта.

2) Много функционала из коробки

- это тоже реальный большой плюс, который сокращает расходы на создание аналогичного функционала.

3) Удобно интегрировать с CRM битрикс

- хороший плюс, который сокращает расходы на создание аналогичного функционала.

масштабировать проект очень сложно

- точно также как и в Ларавел пишутся модули и функционал.
Когда имеет смыл рассматривать преимущества Ларавел
- когда не типовой, индивидуальный интернет-магазин
- когда возможностей CMS Битрикс кардинально не хватает
- когда глубокая интеграция ТЗ в готовый функционал занимает больше времени, чем сборка аналога с нуля. И в итоге дороже. В этом случае бизнес считает деньги.
- гибкость для сложных проектов, но нужно эту гибкость представить в виде пункта коммерческого предложения, иначе это для бизнеса просто слово
- создание и полная кастомизация административной панели сайта под не типовые и сложные проекты
- скорость работы, для крупных интернет-магазинов это важно. Интернет-магазин получается реально шустрее тиражных решений.

Читем про CORS, узнаём, что что запросы с неидентичных портов блокируются, прописываем в конфиг CORS http://localhost:4200.