Экономика процесса состоит в том, сначала производитель сам оплачивает свою работу, а затем потребители сами оплачивают работу производителя в той степени, в какой могут это сделать.
Вы мне тут про какой-то коммунизм рассказываете, который с сознательными производителями и потребителями, работающими ради общего блага.
Но мы-то живем в царстве бездушного чистогана, капитализмом именуемым (и на то есть серьезные причины). И в этом царстве сознательность в сколь-нибудь существенных для экономики масштабах не работает. Чисто потому, что в царстве бездушнуго чистогана каждый работает на свое собственное благо. И потому в масштабах экономики потребитель в среднем предпочтет взять себе чужой продукт за минимально доступную ему цену. То есть, потребители в нашем царстве бездушного чистогана оплачивают работу производителя в той степени, в какой они вынуждены это делать.
Реальные работающие механизмы оплаты — они разные на разных стадиях развития ПО, и не всегда это — плата непосредственно за копию ПО. Но про эти подробности я здесь говорить не хочу (как я писал, для этого нужна полноценная статья).
А вот про что хочу все же сказать — это то, что вы демонстрируете ложный, неработающий почти никогда механизм компенсации издержек на разработку ПО. А вот почему вы это делаете — добросовестно ли заблуждаясь или из корысти какой — мне это не ведомо и, в общем-то, не интересно.
И да, Эрик Реймонд в своей классической работе «Собор и базар» рассматривал совсем не тот механизм, который вы тут декларируете — он как-то ближе был к реальной жизни.
Это и есть свободное ПО, которое можно свободно использовать для любых целей.
Теоретически, если исходить из значения слова — да. К сожалению, на практике, как это часто бывает со словом «свободный», название «свободное ПО» («free software») присвоили сторонники другого, не столь свободного подхода: запрета использования «свободного ПО» как основы для разработок с закрытыми исходными текстами: всяческие FSF (Free Software Foundation), GNU с ее GPL и прочие идеологические последователи Столлмена. Поэтому для обозначения ПО, исходные тексты которого можно использовать действительно для любых целей (типа выпущенных под лицензией BSD) приходится использовать другое слово. Не знаю, как там американцы с этим обходятся, но в русском языке издавна используется слово «открытое ПО» (если чо — я это слово в середине 90-х годов слышал и в печати компьютерной видел именно по отношению BSD-версиям Юникса и т.п.)
Так что в этом вопросе явно требется то, что кто-то из древних китайцев (Конфуций, вроде бы) называл «исправлением имён».
Впрочем, конкретно в случае импортозамещения в России сейчас этой разницей можно пренебречь: вряд ли американский FSF сможет засудить хоть какую-нибудь российскую фирму и наказать ее на деньги.
Поэтому при обсуждении данной конкретной статьи такими тонкостями можно не заморачиваться — что автор, в общем-то, и сделал, и был прав.
Производитель, разумеется, волен распоряжаться своим продуктом любым образом. Но когда в отношении "свободного ПО" используется слово "производитель", в этом есть некое лукавство: в идеологии "свободного ПО", в ее исходном виде (типа как у Реймонда в "Соборе и базаре"), вообще не просматривается такого субъекта, как производитель, а ПО полагается продуктом деятельности некоего достаточно аморфного сообщества сообщества. А такое сообщество, в силу своей аморфности, не в состоянии обладать исключительным правом, необходимым для выпуска продукта под другой лицензией.
Что до реальности, в которой производители таки есть, то можно было бы, конечно, поговорить за экономику процесса, как она в вашем преставлении такая удивительная получается, но здесь и сейчас я этот разговор заводить не хочу. Это — тема для очень большого и совсем другого разговора. По-хорошему тут нужна, как минимум, одна статья, как эта экономика выглядела на разных этапах развития. Этих этапов я вижу, как минимум, три. И тиражируемые программный продукты — были основой экономики второго этапа, а не нынешнего. Ибо на нынешнем этапе основные деньги делаются на предоставлении услуг (как правило — централизованном), а не ПО.
В этой же ветки комментариев моей целью яыляется исключительно "исправление имен". А именно, явно указать на то, что прилагательное "свободное" в отношении ПО по факту накладывает дополнительные ограничения на его использование по сравненю с использованием открытого ПО — т.е. доступного всем и для любых целей. То есть — является не на самом деле не тем, чем кажется, как и многое из того, что содержит в своем названии слова "свобода" или "свободный". Если у вас есть возражения именно поэтому пункту, то дискуссию имеет смысл продолжить, иначе ее стоит закончить.
Вы читали невнимательно. Я писал не про просто «коммерческие программы», а про тиражируемые программные продукты: те, которые можно использовать «как есть» — в виде двоичных исполняемых файлов и без необходимости помощи со стороны производителя. Поскольку тиражируемые программные продукты легко копировать, то производитель, чтобы не потерять доходы, по чисто экономическим причинам блокировал доступ к исходному коду тиражируемых программ.
И движение за «свободное ПО» было как раз ответом на эту политику производителей тиражируемых программных продуктов.
PS Русская Википедия, кстати, в целом, согласна с моим использование терминологии, касающейся открытого и свободного ПО.
Нет, отнюдь. "Свободное ПО" это когда клиент получает доступ к исходникам, может менять и даже совершенствовать их, но не имеет право делать на их основе тиражируемый программный продукт, который можно продавать. Классическая лицензия "свободного ПО" — GPL.
А открытое ПО (классическая лицензия его — BSD) позволяет использовать полученный исходный код, как угодно, лишь бы было указано его авторство. В том числе — и для разработки комерческого тиражируемого программного продукта.
Переводы статей Хассена есть на сайте упомянутого ниже Евгения Волкова.
Но с Хассеном надо поосторожнее: его иногда заносит. Например, помню, как после 9/11/2001 он настойчиво продвигал версию, что осуществившие этот теракт люди были членами деструктивного культа (на самом деле таких данных нет).
Зачем статья?
Есть целая (и очень хорошая IMHO) книга про пропаганду: "Эпоха пропаганды" Пратканиса с Аронсоном (вот ее описание с сайта переводчика). Правда, она сделана, в основном, на материале Америки 90-х, но с тех пор в основах социальной психологии поменялось немного.
PS На переводчика — некогда широко известного в узких кругах Евгения Волкова, борца с тоталитарными сектами AKA destructive cults — тоже IMHO стоит обратить внимание, если такие вопросы интересуют. Например, у него есть большая подборка материалов по теме.
Ну и замечательную (IMHO) книгу Чалдини "Влияние" (в ранних изданиях — "Психология влияния") перевел тоже Евгений Волков.
важно его удерживать за счет регулярного подтверждения своих компетенций и результатов
Это — не единственный реально используемый способ удержания положения. Выявлять и топить конкурентов — способ IMHO куда более распространенный.
Так что, может, не надо заставлять руководителей тратить силы на удержание своего положения? А то ведь у вас никого, кроме специалистов по удержанию и не останется.
чтобы знать об операциях в полете
А можно это на русский перевести? Чтобы читателям не приходилось переводить сначала дословно на английский, а потом — по смыслу на русский.
PS Это не единственный огрех перевода, но самый выразительный IMHO
Как получают — важно, потому что если это — глобальный объект, который используют все, то предыдущий варинат не пройдет.
И если один объект реализует много разных методов, то и объект, созданный на на основе него как прототипа, будет реализовать те же самые методы, в принципе (детали возможны, да).
Ну, это ваш выбор. Не смею навязывать свой.
Хотя… Если прикладные программы всегда получают его через new Api, как у вас в примере, то можно совершенно прозрачно поменять функцию Api так, чтобы она возвращала новый объект, унаследованный от основного объекта Api, но со своим собственным AbortController.
Привет, спасибо за такой подробный комментарий, но вы многое упускаете :)
«Нельзя объять необъятное» (Козьма Прутков). Я всего лишь демонстрирую взгляд с другой стороны.
Мы всегда стараемся показать данные как можно быстрее в хорошем интерфейсе.
А эти данные в таком неполном виде точно для пользователя какую-то ценность имеют? Если да, и если данные отображаются в нескольких частях (типа основной записи и детализации или наоборот, каких-то суммарных значение), то ваш варинт — обновление интерфейса несколько раз в процессе запроса — имеет смысл, и однократной проверкой номера версии тогда не обойтись. Но в примере — в коде, а не на диаграмме- обновление интерфейса было одно, и я на это обратил внимание.
Тем не менее, идея с версией обновления мне лично не кажется особо хорошей, шаблон скоординированной отмены мне нравится больше. Может, потому что привык — он в C# уже больше 10 лет существует.
встречаются более сложные примеры с несколькими отдельными визуально, но связанными логически интерфейсами,
Мое мнение — делать обновление таких частей методом(ами) одного объекта, который и будет контекстом для всей цепочки. Благо JS позволяет много чего лишнего, чего лишены разработчики на языках со статической типизацией ;-), в данном случае — заимствование методов из других объектов.
нужно понимать про какой контекст мы говорим, в каком контексте
В контексте здешнего обсуждения контекст это исключительно про набор взаимосвязанных асинхронно выполняющихся запросов к серверу. Контекст приложения оставляем в стороне, как и само приложение, каково бы оно ни было (а они ведь разные бывают, не так ли?).
у нас такая культура во фронте
Дык, я в чужой монастырь со своим уставом лезть и не собираюсь. Нелюбовь к зависимостям — это мое личное предпочтение. А насчет библиотек — которые не от лидеров рынка, а от таких же разработчиков — я бы не был столь оптимистичен Хотя, возможно, у вас там на фронте с кодом приложений ещё хуже, не знаю.
Это — свой объект для каждой цепочки запросов? Тогда вот вам и готовый контекст, куда можно AbortController засунуть. Ну и, чтобы сделать такой, какой-то особый фреймворк не нужен — достаточно создать объект и прописать в нем нужные методы. Вы согласны?
Дык вопрос-то был, как это сделать без этого вашего $mol в принципе, а не как это сделать красиво. Кароче, вы мне тут напишите — код работать будет вообще, в принципе? Если да, то мне для иллюстрации достаточно.
PS Api — это DI-котейнер, или что? Если DI-котейнер, то Api не нужен потому что я написал PoC: нужные функции передаются напрямую, как параметры. Впихнуть DI-котейнер несложно, только вот он число сущностей умножит, а я старался упростить.
И да, getA и getB просто не читайте: они тут чисто для иллюстрации, кужа скоординированную отмену впихивать, дабы не гадал никто.
Что-то типа такого (основываюсь на вашем примере из второго листинга, а так как JS — не мой родной язык, то если что не так — подправьте)
{
class App {
constructor(controller_name) {
this.сontrollerName = controller_name;
this.controller = new AbortController();
}
async event(getA, getB) {
if(this.controller) controller.abort(controllerName);
this.controller = new AbortController();
const a = await this.getA();
const b = await this.GetB(a);
// controller.throwIfAborted() добавить по вкусу
return b;
}
}
async function getA() {
let a;
//...do smth
this.controller.throwIfAborted();
//...do smth more
//при необходимости повторить предыдущие две строчки до готовности
return a
}
async function getB(a) {
let b;
//...do smth with a
this.controller.throwIfAborted();
//...do smth more with a
//при необходимости повторить предыдущие две строчки до готовности
return b
}
}
Плохая подача материала: в новости совершенно не раскрыты причинно-следственные связи введения санкций. Сравните вашу новость той же новостью, например, на РБК:
США ввели санкции против основанного предпринимателем Алишером Усмановым холдинга USM, предприятия «Металлоинвест» и оператора «Мегафон», а также в отношении компаний и физических лиц, которые, как утверждают американские власти, связаны с бизнесменом, говорится в сообщении Минфина США. Сам Усманов находится под американскими санкциями с прошлого года.
«Усманов имеет в своем распоряжении широкую сеть предприятий в офшорах, а через члены его семьи он может проводить финансовые операции, что потенциально позволяет ему обходить санкции», — отметили в Минфине США.
В результате у вас непонятно, почему санкциям подвергся именно «Мегафон» (ответ: потому что это — дочернее предприятие холдинга USM Усманова).
Уважаемые фронтовики (или передовики, как правильно?)!
Как задовик, я понимаю ваши проблемы и даже немного сочувствую. Но — не разделяю.
Например, я в примере (точнее, на диаграмме) вижу нарушение принципа "дураку полработы не показывают": ну вот зачем после getA надо показывать промежуточные результаты пользователю (которого чисто для пользы дела следует считать дураком)? Лучше было бы дождаться getB, собрать всю полученную инфорацию в кучу и сразу обновить отображаемые данные. Ведь в коде примера, на самом деле, оно так и сделано, если я правильно понял смысл заклинания setState. Версионирование при таком подходе работает на ура — версию достаточно проверить один раз, перед обновлением отображаемых пользователю данных. В примере, насколько я понял это стоит сделать в setState. Благо, вы там на фронте можете себе позволить дождаться конца каждой цепочки, не экономя на запросах к серверу — задовики как-нибудь справятся, да ;-).
Во-вторых, я рад, что до фронта наконец-то добрался шаблон скоординированной отмены (который AbortController, в C# это — CancellationToken и все что вокруг него). Вот проблемы с прокидыванием его я как раз понимаю — у нас так же мучаться приходится. И решение примерно то же самое — контекст. И даже для прокидывания контекста ничего особо изобретать не нужно — для этого есть объекты и ключевое слово this в их методах. У вас на фронте тоже так же можно, только чуть побольше "бойлерплейта" надо — например, писать "function" вместо "=>" (ну, и список параметров переставить по месту). Как по-моему, то лишние 6 символов на функцию того стоят. Может, попробуете? В комменте nin-jin примерно показано, как это делается (подсказка: его любимый $mol для этого, в общем-то, не нужен).
А вот чего, по-моему, делать не стоит — так это использовать для хранения контекста глобальную переменую — даже которая на уровне модуля. Ибо это — костыль жуткий: что вы делать-то будете, когда вам потребуется параллельно выполнять две цепочки? Или это — чисто для примера? Так для примера я бы блок не поленился нарисовать — у вас же модуль и там всегда "use strict", так что всего два символа — и любой приверженец методологии разработки SO-Driven Development будет в безопасности (относительной) ;-)
А что по поводу Reatom, то я к лишней зависмости всегда отношусь с подозрением (я не люблю зависимости, хотя, допускаю, что я просто не умею их готовить). Потому пофантазирую: нельзя ли то же самое сделать через Proxy в чисто конкретных местах?
PS Надеюсь, то что я тут говорю тут про задачи (Task/promise) а не про async/await это никого не смущает? Если вдруг смущает — могу пояснить.
PPS Немного побуду Шишковым: "to track" переводится с английского (в данном контексте) как "отслеживать". Так что, можно вместо изобретения своих словоуродцев использовать его. Впрочем, лично для меня это не страшно — читать русские тексты по IT методом обратного перевода я привык со времен ЕС ЭВМ — но я за других беспокоюсь.
PPS Если чо не то сказал — извиняйте: ну, не фронтовик я (и не передовик).
В самом широком смысле под самооценкой понимают субъективную оценку человеком собственной ценности. И я бы от себя еще добавил в конце слова и собственных возможностей.
А зачем добавлять — если дальше все равно пришлось разделить: то, что общепринято называть просто самооценкой, пришлось выделить и назвать «базовой самооценкой», а оценку возможностей — «ситуативной самооценкой». Потому что по своей сути это — совершенно разные оценки.
Оценка возможностей (точнее, оценки, потому они могут быть разными для разных областей деятельности) — это отражение в сознании простой и понятной вещи: объективных возможностей в этих разных областях. Отражение это, конечно, может быть и малоадекватным, но обычно столкновение с реальностью приводит эту группу оценок себя более-менее в соответствие с действительностью. Хотя бы потому, что человек заинтересован в правильности этого отражения.
А вот самооценка («базовая») — это совсем другое. Из чисто философских соображений можно предположить (это тезис — не утверждение, а эвристика, и конкретно доказывать или опровергать его должна наука психология), что самооценка — это отражение в сознании члена общества ценности этого члена для общества (ее ещё называют популяционной ценностью). То есть, это — своего рода средство ускорения отбора, позволяющая отсеять членов общества, заведомо малопригодных для дальнейшего развития общества. Некий такой способ доведения до человека потребностей общества. А самому человеку как индивиду это, вообще-то, не нужно.
Отдельному человеку, осознающему себя индивидумом, на потребности общества, по большому счету плевать: он живет сам для себя. А потому с низкой самооценкой надо бороться. Что именно для этого делать — это, в общем-то, хлеб специалистов-психологов, но кое-что можно сказать и без них. Самое простое — научиться не связывать свою самооценку с какими-либо внешними обстоятельствами, своими возможностями и прочими обстоятельствами. Или, как писал Козьма Прутков по аналогичному поводу: «Если хочешь быть счастливым — будь им». Потому что каждый человек уже для самого себя представляет высшую ценность — вот из этого и надо исходить.
Понимаю, что звучит это как известный совет филина-стратега «мыши, станьте ежиками». Но этот совет показывает правильное направление. И иногда одного этого оказывается достаточно — потому что для следования ему не надо менять объективную реальность (выращивать колючки на теле), достаточно поменять содержимое своих мозгов.
Тех, кто занимается DevRel, нельзя называть деврелами.
Согласен. Предлагаю хорошее (мне нравится, как оно звучит) название: «деврельщики». ;-)
PS И да, когда я вижу слово «должны», мне сразу хочется поинтересоваться — «кому»? Что поделать, комсомольская юность в анамнезе — она в старости вот так сказывается ;-)
Вы мне тут про какой-то коммунизм рассказываете, который с сознательными производителями и потребителями, работающими ради общего блага.
Но мы-то живем в царстве бездушного чистогана, капитализмом именуемым (и на то есть серьезные причины). И в этом царстве сознательность в сколь-нибудь существенных для экономики масштабах не работает. Чисто потому, что в царстве бездушнуго чистогана каждый работает на свое собственное благо. И потому в масштабах экономики потребитель в среднем предпочтет взять себе чужой продукт за минимально доступную ему цену. То есть, потребители в нашем царстве бездушного чистогана оплачивают работу производителя в той степени, в какой они вынуждены это делать.
Реальные работающие механизмы оплаты — они разные на разных стадиях развития ПО, и не всегда это — плата непосредственно за копию ПО. Но про эти подробности я здесь говорить не хочу (как я писал, для этого нужна полноценная статья).
А вот про что хочу все же сказать — это то, что вы демонстрируете ложный, неработающий почти никогда механизм компенсации издержек на разработку ПО. А вот почему вы это делаете — добросовестно ли заблуждаясь или из корысти какой — мне это не ведомо и, в общем-то, не интересно.
И да, Эрик Реймонд в своей классической работе «Собор и базар» рассматривал совсем не тот механизм, который вы тут декларируете — он как-то ближе был к реальной жизни.
Теоретически, если исходить из значения слова — да. К сожалению, на практике, как это часто бывает со словом «свободный», название «свободное ПО» («free software») присвоили сторонники другого, не столь свободного подхода: запрета использования «свободного ПО» как основы для разработок с закрытыми исходными текстами: всяческие FSF (Free Software Foundation), GNU с ее GPL и прочие идеологические последователи Столлмена. Поэтому для обозначения ПО, исходные тексты которого можно использовать действительно для любых целей (типа выпущенных под лицензией BSD) приходится использовать другое слово. Не знаю, как там американцы с этим обходятся, но в русском языке издавна используется слово «открытое ПО» (если чо — я это слово в середине 90-х годов слышал и в печати компьютерной видел именно по отношению BSD-версиям Юникса и т.п.)
Так что в этом вопросе явно требется то, что кто-то из древних китайцев (Конфуций, вроде бы) называл «исправлением имён».
Впрочем, конкретно в случае импортозамещения в России сейчас этой разницей можно пренебречь: вряд ли американский FSF сможет засудить хоть какую-нибудь российскую фирму и наказать ее на деньги.
Поэтому при обсуждении данной конкретной статьи такими тонкостями можно не заморачиваться — что автор, в общем-то, и сделал, и был прав.
Производитель, разумеется, волен распоряжаться своим продуктом любым образом. Но когда в отношении "свободного ПО" используется слово "производитель", в этом есть некое лукавство: в идеологии "свободного ПО", в ее исходном виде (типа как у Реймонда в "Соборе и базаре"), вообще не просматривается такого субъекта, как производитель, а ПО полагается продуктом деятельности некоего достаточно аморфного сообщества сообщества. А такое сообщество, в силу своей аморфности, не в состоянии обладать исключительным правом, необходимым для выпуска продукта под другой лицензией.
Что до реальности, в которой производители таки есть, то можно было бы, конечно, поговорить за экономику процесса, как она в вашем преставлении такая удивительная получается, но здесь и сейчас я этот разговор заводить не хочу. Это — тема для очень большого и совсем другого разговора. По-хорошему тут нужна, как минимум, одна статья, как эта экономика выглядела на разных этапах развития. Этих этапов я вижу, как минимум, три. И тиражируемые программный продукты — были основой экономики второго этапа, а не нынешнего. Ибо на нынешнем этапе основные деньги делаются на предоставлении услуг (как правило — централизованном), а не ПО.
В этой же ветки комментариев моей целью яыляется исключительно "исправление имен". А именно, явно указать на то, что прилагательное "свободное" в отношении ПО по факту накладывает дополнительные ограничения на его использование по сравненю с использованием открытого ПО — т.е. доступного всем и для любых целей. То есть — является не на самом деле не тем, чем кажется, как и многое из того, что содержит в своем названии слова "свобода" или "свободный". Если у вас есть возражения именно поэтому пункту, то дискуссию имеет смысл продолжить, иначе ее стоит закончить.
Не, там должно быть быстрее. При укусах в голову, как пишут в литературе, бывает и 14. А обонятельные луковицы в носу — они ещё ближе к мозгу.
И движение за «свободное ПО» было как раз ответом на эту политику производителей тиражируемых программных продуктов.
PS Русская Википедия, кстати, в целом, согласна с моим использование терминологии, касающейся открытого и свободного ПО.
У вас по-моему бедноватая фантазия: бешенство, передающееся воздушно-капельным путем — это куда «интереснее», IMHO.
Нет, отнюдь. "Свободное ПО" это когда клиент получает доступ к исходникам, может менять и даже совершенствовать их, но не имеет право делать на их основе тиражируемый программный продукт, который можно продавать. Классическая лицензия "свободного ПО" — GPL.
А открытое ПО (классическая лицензия его — BSD) позволяет использовать полученный исходный код, как угодно, лишь бы было указано его авторство. В том числе — и для разработки комерческого тиражируемого программного продукта.
Переводы статей Хассена есть на сайте упомянутого ниже Евгения Волкова.
Но с Хассеном надо поосторожнее: его иногда заносит. Например, помню, как после 9/11/2001 он настойчиво продвигал версию, что осуществившие этот теракт люди были членами деструктивного культа (на самом деле таких данных нет).
Зачем статья?
Есть целая (и очень хорошая IMHO) книга про пропаганду: "Эпоха пропаганды" Пратканиса с Аронсоном (вот ее описание с сайта переводчика). Правда, она сделана, в основном, на материале Америки 90-х, но с тех пор в основах социальной психологии поменялось немного.
PS На переводчика — некогда широко известного в узких кругах Евгения Волкова, борца с тоталитарными сектами AKA destructive cults — тоже IMHO стоит обратить внимание, если такие вопросы интересуют. Например, у него есть большая подборка материалов по теме.
Ну и замечательную (IMHO) книгу Чалдини "Влияние" (в ранних изданиях — "Психология влияния") перевел тоже Евгений Волков.
Это — не единственный реально используемый способ удержания положения. Выявлять и топить конкурентов — способ IMHO куда более распространенный.
Так что, может, не надо заставлять руководителей тратить силы на удержание своего положения? А то ведь у вас никого, кроме специалистов по удержанию и не останется.
Как получают — важно, потому что если это — глобальный объект, который используют все, то предыдущий варинат не пройдет.
И если один объект реализует много разных методов, то и объект, созданный на на основе него как прототипа, будет реализовать те же самые методы, в принципе (детали возможны, да).
Хотя… Если прикладные программы всегда получают его через new Api, как у вас в примере, то можно совершенно прозрачно поменять функцию Api так, чтобы она возвращала новый объект, унаследованный от основного объекта Api, но со своим собственным AbortController.
А эти данные в таком неполном виде точно для пользователя какую-то ценность имеют? Если да, и если данные отображаются в нескольких частях (типа основной записи и детализации или наоборот, каких-то суммарных значение), то ваш варинт — обновление интерфейса несколько раз в процессе запроса — имеет смысл, и однократной проверкой номера версии тогда не обойтись. Но в примере — в коде, а не на диаграмме- обновление интерфейса было одно, и я на это обратил внимание.
Тем не менее, идея с версией обновления мне лично не кажется особо хорошей, шаблон скоординированной отмены мне нравится больше. Может, потому что привык — он в C# уже больше 10 лет существует.
Мое мнение — делать обновление таких частей методом(ами) одного объекта, который и будет контекстом для всей цепочки. Благо JS позволяет много чего лишнего, чего лишены разработчики на языках со статической типизацией ;-), в данном случае — заимствование методов из других объектов.
В контексте здешнего обсуждения контекст это исключительно про набор взаимосвязанных асинхронно выполняющихся запросов к серверу. Контекст приложения оставляем в стороне, как и само приложение, каково бы оно ни было (а они ведь разные бывают, не так ли?).
Дык, я в чужой монастырь со своим уставом лезть и не собираюсь. Нелюбовь к зависимостям — это мое личное предпочтение. А насчет библиотек — которые не от лидеров рынка, а от таких же разработчиков — я бы не был столь оптимистичен Хотя, возможно, у вас там на фронте с кодом приложений ещё хуже, не знаю.
Это — свой объект для каждой цепочки запросов? Тогда вот вам и готовый контекст, куда можно AbortController засунуть. Ну и, чтобы сделать такой, какой-то особый фреймворк не нужен — достаточно создать объект и прописать в нем нужные методы. Вы согласны?
Дык вопрос-то был, как это сделать без этого вашего $mol в принципе, а не как это сделать красиво. Кароче, вы мне тут напишите — код работать будет вообще, в принципе? Если да, то мне для иллюстрации достаточно.
PS Api — это DI-котейнер, или что? Если DI-котейнер, то Api не нужен потому что я написал PoC: нужные функции передаются напрямую, как параметры. Впихнуть DI-котейнер несложно, только вот он число сущностей умножит, а я старался упростить.
И да, getA и getB просто не читайте: они тут чисто для иллюстрации, кужа скоординированную отмену впихивать, дабы не гадал никто.
Что-то типа такого (основываюсь на вашем примере из второго листинга, а так как JS — не мой родной язык, то если что не так — подправьте)
В результате у вас непонятно, почему санкциям подвергся именно «Мегафон» (ответ: потому что это — дочернее предприятие холдинга USM Усманова).
Уважаемые фронтовики (или передовики, как правильно?)!
Как задовик, я понимаю ваши проблемы и даже немного сочувствую. Но — не разделяю.
Например, я в примере (точнее, на диаграмме) вижу нарушение принципа "дураку полработы не показывают": ну вот зачем после getA надо показывать промежуточные результаты пользователю (которого чисто для пользы дела следует считать дураком)? Лучше было бы дождаться getB, собрать всю полученную инфорацию в кучу и сразу обновить отображаемые данные. Ведь в коде примера, на самом деле, оно так и сделано, если я правильно понял смысл заклинания setState. Версионирование при таком подходе работает на ура — версию достаточно проверить один раз, перед обновлением отображаемых пользователю данных. В примере, насколько я понял это стоит сделать в setState. Благо, вы там на фронте можете себе позволить дождаться конца каждой цепочки, не экономя на запросах к серверу — задовики как-нибудь справятся, да ;-).
Во-вторых, я рад, что до фронта наконец-то добрался шаблон скоординированной отмены (который AbortController, в C# это — CancellationToken и все что вокруг него). Вот проблемы с прокидыванием его я как раз понимаю — у нас так же мучаться приходится. И решение примерно то же самое — контекст. И даже для прокидывания контекста ничего особо изобретать не нужно — для этого есть объекты и ключевое слово this в их методах. У вас на фронте тоже так же можно, только чуть побольше "бойлерплейта" надо — например, писать "function" вместо "=>" (ну, и список параметров переставить по месту). Как по-моему, то лишние 6 символов на функцию того стоят. Может, попробуете? В комменте nin-jin примерно показано, как это делается (подсказка: его любимый $mol для этого, в общем-то, не нужен).
А вот чего, по-моему, делать не стоит — так это использовать для хранения контекста глобальную переменую — даже которая на уровне модуля. Ибо это — костыль жуткий: что вы делать-то будете, когда вам потребуется параллельно выполнять две цепочки? Или это — чисто для примера? Так для примера я бы блок не поленился нарисовать — у вас же модуль и там всегда "use strict", так что всего два символа — и любой приверженец методологии разработки SO-Driven Development будет в безопасности (относительной) ;-)
А что по поводу Reatom, то я к лишней зависмости всегда отношусь с подозрением (я не люблю зависимости, хотя, допускаю, что я просто не умею их готовить). Потому пофантазирую: нельзя ли то же самое сделать через Proxy в чисто конкретных местах?
PS Надеюсь, то что я тут говорю тут про задачи (Task/promise) а не про async/await это никого не смущает? Если вдруг смущает — могу пояснить.
PPS Немного побуду Шишковым: "to track" переводится с английского (в данном контексте) как "отслеживать". Так что, можно вместо изобретения своих словоуродцев использовать его. Впрочем, лично для меня это не страшно — читать русские тексты по IT методом обратного перевода я привык со времен ЕС ЭВМ — но я за других беспокоюсь.
PPS Если чо не то сказал — извиняйте: ну, не фронтовик я (и не передовик).
А зачем добавлять — если дальше все равно пришлось разделить: то, что общепринято называть просто самооценкой, пришлось выделить и назвать «базовой самооценкой», а оценку возможностей — «ситуативной самооценкой». Потому что по своей сути это — совершенно разные оценки.
Оценка возможностей (точнее, оценки, потому они могут быть разными для разных областей деятельности) — это отражение в сознании простой и понятной вещи: объективных возможностей в этих разных областях. Отражение это, конечно, может быть и малоадекватным, но обычно столкновение с реальностью приводит эту группу оценок себя более-менее в соответствие с действительностью. Хотя бы потому, что человек заинтересован в правильности этого отражения.
А вот самооценка («базовая») — это совсем другое. Из чисто философских соображений можно предположить (это тезис — не утверждение, а эвристика, и конкретно доказывать или опровергать его должна наука психология), что самооценка — это отражение в сознании члена общества ценности этого члена для общества (ее ещё называют популяционной ценностью). То есть, это — своего рода средство ускорения отбора, позволяющая отсеять членов общества, заведомо малопригодных для дальнейшего развития общества. Некий такой способ доведения до человека потребностей общества. А самому человеку как индивиду это, вообще-то, не нужно.
Отдельному человеку, осознающему себя индивидумом, на потребности общества, по большому счету плевать: он живет сам для себя. А потому с низкой самооценкой надо бороться. Что именно для этого делать — это, в общем-то, хлеб специалистов-психологов, но кое-что можно сказать и без них. Самое простое — научиться не связывать свою самооценку с какими-либо внешними обстоятельствами, своими возможностями и прочими обстоятельствами. Или, как писал Козьма Прутков по аналогичному поводу: «Если хочешь быть счастливым — будь им». Потому что каждый человек уже для самого себя представляет высшую ценность — вот из этого и надо исходить.
Понимаю, что звучит это как известный совет филина-стратега «мыши, станьте ежиками». Но этот совет показывает правильное направление. И иногда одного этого оказывается достаточно — потому что для следования ему не надо менять объективную реальность (выращивать колючки на теле), достаточно поменять содержимое своих мозгов.
Согласен. Предлагаю хорошее (мне нравится, как оно звучит) название: «деврельщики». ;-)
PS И да, когда я вижу слово «должны», мне сразу хочется поинтересоваться — «кому»? Что поделать, комсомольская юность в анамнезе — она в старости вот так сказывается ;-)