WbICHA, ну это у них так плагин называется и я как под копирку написал. Конечно, правильнее будет тайп-линтинг. Сам тс у меня глобально установлен. Так-то оно работает, просто не быстро.
Daniil Igumenshev, через курсор (если мы говорим об одном и том же) данные получают, а не записывают. Можете показать фрагмент кода, где вы делаете запрос на сохранение данных в БД?
А как вы вообще работаете с пг из пайтона? Через какой-то орм-диалект или отправляете сырые скл-запросы через провайдера? Как вы данные в него записываете, которые хотите удалить?
Еще не совсем понятно: как у вас на данный момент реализован учет товарных остатков вашего мерча? Видимо, никак. Тогда можно присмотреться к интеграции "МойСклад" и стороннего сервиса интернет-магазина. Это все равно будет проще и быстрее, чем писать свою платформу. Пусть даже придется с какими-то костылями мириться.
GizzaProger, как человек, который в еком логистике почти 10 лет, скажу, что да, сложности есть... Вам по-хорошему нужен либо бекендер с опытом в екоммерс (обычно у таких по умолчанию хороший беграунд в базах данных и навыки бизнес-аналитика), который согласует с вашим фронтом API и реализует всю логику под ваш фронтенд. Это тот путь, по которому мы в свое время пошли и он не сильно быстрый.
Второй вариант вы сами назвали. Если не найдете готового решения, то почему бы не управлять готовым сервисом вроде InSales, у которого уже есть API, в том числе для управления состоянием каталога, заказами и т.д.
Вы, видимо, хотите shop backend as a service? Пульнул метод "Обновить остатки" и там само все как-то обновилось, а вы по другой апишке получаете актуальное состояние склада? Или передал заказ по адресу /orders/create и потом знай только статусы обновляй по тому же api через свой gui?
Просто делали нечто подобное для внутренних нужд в свое время, т.к. готовых решений найти не удалось.
Поскольку у меня веб-серверное приложение и оно используется для обработки запросов, получается, что глобальный контекст (g) действительно часто используется (передается в конструкторы классов) вместе с контекстом самого запроса (ctx). Однако разницу между этими двумя сущностями я вижу в их жизненном цикле: глобальный контекст не меняется за все время работы приложения. Т.е. вне зависимости от пользовательских запросов, состояние условного мейлера или работа пула соединений с БД, неизменно.
В существовании контекста уровня приложения вряд ли есть что-то плохое. Вопрос в реализации. Если я оказываюсь от инкапсуляции этого контекста в объектную переменную g, которая затем передается во все конструкторы "рабочих" классов, то нужно как-то по-другому сделать это состояние доступным, над чем я и ломаю голову :)
Условный мейлер я могу вынести в микросервис. Но сама переменная g выглядит удобным транспортным контейнером, который позволяет, при необходимости, быстро внедрить любой сервис во все приложение, сделав его частью общего состояния.
WbICHA, ну почему? Контекст, который я создаю, можно сделать инстансом класса (у меня вначале так и было). Этот класс не имеет собственного функционала, а является лишь транспортным контейнером для экземпляров "рабочих" классов.
Мне хочется понять, как грамотно внедрять зависимости, которые представляют собой не сами классы, а их экземпляры с состоянием, которое не меняется за время работы приложения.
Наверное, что-то вроде DI-фреймворков, которые активно используются в андроид-разработке. Но и там некоторые советуют ограничиться созданием класса для хранения глобального состояние приложения.
Я правильно понял, что вас смутил переход в @types/node из подсказки в IDE? Но ведь это же не имеет отношение к работе компилятора TypeScript. То есть вы можете вообще писать на JS, подсказки все равно будут подтягиваться из деклараций. И да, когда вы даунгрейдили типы для node, IDE перестала отображать подсказки для более нового синтаксиса.
WbICHA, я похоже понял, в чем моя ошибка: в использовании import. TS переводит файл в модульный режим и его приходится импортировать. Но если объявить тип без использования экспорта, то включается "скриптовый режим" и все декларации оказываются в общей области видимости. Соответственно, декларации из таких файлов не нужно импортировать. То есть мне нужно разобраться с областью видимости и declare (в том числе declare module и declare namespace)
WbICHA, Алексей Уколов, поскольку я плохо знаком с синтаксисом Реакта (а вопрос имеет два тега, один из которых относится к чистому JS), то с ходу и не сообразил, что в пропс key сразу передается объект и фигурные скобки в записи {...obj.pizzas} означают банальную переупаковку, а не метку шаблонизатора. В таком случае (если нужно, чтобы title оказался на первом месте), проще, наверное, записать так: key={ pizza.title, ...pizza }
Да, подсветит все дочерние компоненты. Было бы удобно, если я меняю один компонент на другой, видеть, где нужно выполнить замены. Можно конечно заняться рефакторингом и внутри основного компонента, но бывает, что компонент уже готов и просто нужно заменить.