WbICHA

Не использовать encodeURIComponent ?

Из SSM параметры могут не прогрузиться только в том случае если нет доступов или нет ключа. Если деплой производится через CloudFormation то в этих случаях он должен упасть с ошибкой.

Было две идеи продвижения:

1. Плата некоторой суммы, человеку который продвигает
   

Вопрос знающим людям, как выгодней будет для меня ,как заказчика, и до какого момента?

По первому варианту из опыта могу сказать что будет ни так:

• в зависимости от ниши (холодная/горячая), региона (МСК/Таганрог) и цели (ТОП-10/ТОП-3) будет определенная стоимость продвижения и к ней плюсуем сумму оплаты Подрядчику за его труды (разбег неизвестен).
  

В результате, сумма может получиться, например, от 10.000 до 100.000 руб. Допустим, вы договоритесь на 30.000.

Что будет при этом с обоих сторон (основано на реальных событиях):

• Заказчик думает: я получу всё по максимуму, ТОП-3 за 3 месяца по СЧ/ВЧ
  
• Подрядчик (в основном фрилансер, чем студии) думает: за полученные деньги прикуплю накрутку ПФ, подниму НЧ и буду отчитываться по трафику с поисковых систем, может заказы еще пойдут и можно минимум по 30-ке 6 мес получать.
  

Итог: через 6 мес, а то и раньше, сайт под бан, "SEOшник" получает пня под ср..ку, Заказчик ненавидит себя и SEOшников (незаслуженно, ведь толковые специалисты здесь ни при чем), на горизонте мелькает покупка нового домена и работы по продвижению сайта "с нуля".

Это один из вариантов исхода. Почему именно такой? Потому что сценарий набил оскомину. 80% моих клиентов, это жертвы таких сценариев. Меняется только сюжет, результат остается прежний.

Другие сюжеты:

• Продвижение по 10-и запросам за указанную сумму. Мало? Но это результат прагматичного расчета. Часто встречается у веб-студий, они ведь тоже бизнесмены и считать умеют
  
• Выполнение некоторых пунктов из базовой оптимизации. Потому что этой суммы только на них и хватило. Встречается у веб-студий, потому что надо взять кого-то пока нет более выгодного клиента.
  
• и т.п.
  

Что сделать, чтобы избежать указанных выше сценариев?

Придется немного вникнуть в ситуацию и задачи. К сожалению, времена, когда можно было отдать деньги и не задумываться ни о чем, безвозвратно прошли. Конечно, утверждение основано только на моем субьективном опыте.

Поэтому рекомендую следующее:

• определиться с планом работ по проекту (общий список: внутренняя, внешняя оптимизация);
  
• разбить план на этапы;
  
• кропотливо подбирать подрядчиков для выполнения поставленных задач.
  

Какие есть минусы:

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

Какие есть плюсы (они превалируют над минусами, на мой взгляд):

1. работа по SEO становится для вас прозрачна и понятна настолько, что вы думаете что-то типа "блин, да тут оказывается, никакого колдунства, всё понятно и просто". Согласен, кроме нюанса, мало знать ЧТО надо сделать, важно КАК это сделать. Все делают по-разному и получают разный результат (см. где описывал сюжет за 30 тыс);
   
2. задачи по продвижению превращаются в четкий план и вы понимаете, на каком этапе сейчас находитесь и что должны получить. Получаете отчет по отработке запланированных/оговоренных и оцененных/оплаченных задач, а так же данные по динамике трафика и позиций и у вас появляется спокойная уверенность, что всё под контролем. Никакого "черного" ящика;
   
3. Разбив задачи по частям у вас есть возможность разбить оплату на продвижение по частям. Это могут быть не равнозначные по сумме платежи, но они будут не одной суммой и это удобно.
   
4. Вы можете отдать часть задач на реализацию разным подрядчикам, если найдете несколько толковых специалистов, а не одного (а вдруг повезет!). И чтобы они не мешали друг другу, один может заниматься внутренней оптимизацией, второй внешней. Таких вариантов, правда не встречал, но мало ли, ситуации бывают разные.
   

Сколько занимает продвижение в топ города/региона/страны?

Зависит от объема и характера работ, а они зависят от тематики и конкуренции в ней + регион.

Тематики: холодная или горячая.

1. Пример горячей: заказать такси химки
   
2. Пример холодной: купить свадебное платье без рукавов
   

В первом случае, нужен ТОП-1, минимум ТОП-3 при космически высокой конкуренции
Во втором случае, органика будет состоять из Яндекс коллекций больше, чем из посадочных страниц сайта.

В первом случае, стоимость будет за 100.000 в мес (примерно, конечно), во втором можно обойтись 15.000 руб (тоже примерно).

Сколько в среднем на это тратиться, если отрасль «Сантехника»?

Для оценки надо понимать, в каком регионе, какие позиции вы хотите и в каком состоянии ваш сайт (т.е. с чего он будет стартовать, с "нуля" или у него уже есть базовая оптимизация (техническая и поисковая).
По стоимости вам уже ответил пользователь Пума Тайланд, правда без цифр, но причины этого я указал выше.

Было две идеи продвижения:

• Плата процента от прибыли в зависимости от сложности продвижения(город, регион, страна и тд.).
  

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

Не знаю, какие мысли у вас по данному пункту, но что касается расходов. Из своей практики распишу, за что вы будете платить помимо "процента от прибыли":

• работы программиста
  
• текста у копирайтера
  
• работа Админа
  
• закупка ссылок (краунд-ссылки и "вечные")
  

Для понимания, вы в любом случае будете за это платить, и в первом пункте (за фиксированную сумму) и во втором (за процент). Разница лишь в том, что в первом пункте эти расходы могут быть включены в фиксированную сумму, а могут и идти отдельно - как договоритесь.

Плюсы этого способа очевидны - специалист заинтересован в том, чтобы вы получали больше заказов, НО минусы тоже очевидны:

1. он не может влиять на ваш бизнес;
   
2. получения результатов труда растянуты во времени и много рисков не получить их, начиная от того, что бизнес схлопнется от пандемии до недобросовестности Заказчика.
   

Для п.1. Из моего опыта (достал уже с ним, наверное, но что поделать..) SEO специалист добивается трафика, делает его максимальным И.. менегер сливает лиды один за другим (звонки, письма с форм обратной связи и чатов и проч). Сигнал Заказчику, раз-два-три, без результата. SEOшник сливается. Точка.

Мы все думаем, что с нами этого не случится. Но, как показывает практика (хорошо, моя практика:)). И что мы все время о Заказчике? Я тоже не уверен, что завтра продвигаемый мною сайт не попадет под бан, потому что сегодня делаем одно и оно отлично работает, завтра прошел АП и обновленный алгоритм херит всю работу.. А что говорить про спрос на товар/услугу бизнеса в период пандемии или офисных работников, которым все-равно, либо они сегодня не в настроении закрывать сделки?

Чё-то как-то негативненько получилось, да?:)
Наверное, потому что Заказчики чаще мыслят позитивно и это здорово! Моя задача сейчас подготовить к тому, что может пойти ни так в каждом из указанных вами вариантов. И я постарался с этим справиться.

Со стороны Подрядчика, на мой взгляд, привлекательным выглядит вариант №1 (оплата стоимости работ по проекту), т.е оговаривается пул задач, оценивается стоимость, примерный результат и сроки реализации (подробно свое видение расписал выше).

Со стороны Заказчика более привлекателен вариант №2, но со временем большой риск, что даже толковый и ответственный Подрядчик сольется.

проблем с удалением событий не было

Разве?
В обоих вариантах обработчики не будут удаляться.
В removeEventListener нужно передавать тот же самый listener, что и был передан в addEventListener.
Обратите внимание, что именно не такой же, а тот же самый.
ТО есть вот так удалится:

const listener = event => console.log(event);
element.addEventListener('click', listener);
element.removeEventListener('click', listener);

А так уже нет:

element.addEventListener('click', event => console.log(event));
element.removeEventListener('click', event => console.log(event));

ибо это 2 разные функции, не смотря на то, что делают одно и то же, и одинаковы до каждого символа.

P.S.

когда программировал в функциональном стиле

то что в обоих Ваших примерах - это процедурный стиль. От того что Вы завернули код в класс - он не становится ООП, как и то что написали набор функции - не ФП.

Сборщики мусора (далее GC) бывают разные, в том же v8 используется сразу 3 типа GC в зависимости от поколения объектов (упрощенно молодое, старое и сложные случаи), но в большинстве своем принцип работы сводится к просчету достижимости из некоторого корня в дереве объектов (например глобального объекта, но не только его). v8 не является исключением, и его GC содержит C++ api для создания таких корней. Из JS мы данным api можем воспользоваться лишь косвенно, через сущности языка предоставляемые либо самим v8 либо платформой (браузером, node.js, deno и т.д.)
Чтоб было понятно давайте рассмотрим простой пример:

const h = 'Hello world!';
const n = 'nothing';
setTimeout(() => {
  console.log(h);
}, 1000);

У нас есть строковые переменные h и n. Переменная n нигде больше не используется и ее память очистится при ближайшей работе GC. А вот переменная h оказалась в замыкании созданном стрелочной функцией. И хотя в JS мы не можем достучаться до h имея ссылку на эту функцию, сама функция все таки имеет ссылку на h, а значит h не может быть уничтожена пока не будет уничтожена сама функция. В терминах GC ссылка на h будет серой, то есть сама ссылка на h недоступна из корня напрямую, но сейчас мы проверяем объекты, которые на нее ссылаются и истина будет зависеть от них (подробнее можете погуглить "mark black white and gray memory in gc").
Давайте посмотрим на саму стрелочную функцию, которая держит h в замыкании. Из кода видно, что мы ее передаем в функцию setTimeout, о которой известно, что это api предоставленное платформой (а значит вероятно какая-то часть написана на C++), а так же, что она асинхронная. Платформе реализующей setTimeout наша функция понадобится после асинхронного ожидания и никто платформе не сможет гарантировать, что во время этого ожидания не будет работы GC, поэтому ей ничего не остается, кроме как запросить у v8 создание нового корневого дерева объектов, в которое и будет положена ссылка на данную функцию.
После же выполнения таймаута платформе больше не нужна наша функция, поэтому ссылка на нее будет удалена из дерева объектов. А так как других ссылок на функцию нет, и она больше не доступна ни из одного корня - GC удалит из памяти и функцию и строку связанную h, которая так же стала недоступна из корня.

Посмотрим на пример из вопроса. У нас есть стрелочная функция, которая удерживает на себе инстанс компонента через this ссылку (так как стрелочные функции замыкают this). Саму функцию в памяти удерживает промис порожденный вызовом loader('url'), так как мы отдали её в метод then. Других ссылок на данную функцию нет, а значит и сама функция и ее замыкание (инстанс компонента) будут "жить" не менее "жизни" промиса.

Скажем был отправлен запрос на сервер, но потом компонент в котором был объявлен промис и колбек был удален.
И после удаления приходит ответ от сервера, и он выполнит колбек. Это значит что колбек остался в памяти со всеми переменными контекста

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

Теперь стоит разобраться с самим промисом. У него может быть 3 состояния - pending, resolved или rejected. После перехода в состояния resolved или rejected промис может выполнить сохраненные колбэки в ближайшем микротаске, а после он удалит на них ссылки из себя, в следствии чего, память удерживаемая замыканием колбэка может быть очищена (при отсутствии на нее других ссылок, достижимых из какого-либо корня).
В состоянии pending промис может потенциально находится бесконечно долго, при этом ссылаясь на все колбэки переданные ему в методы then, catch или finally, а значит так же косвенно ссылаясь на их замыкания. И тут все зависит от того, кто ссылается на данный промис, и достижим ли он из корня. И да, промис вполне может быть удален из памяти так и не дождавшись своего завершения.


В комментах к вопросу есть еще один интересный пример:

function getSomething(){
  return new Promise((resolve, reject)=>{
    if(sys_condition){
       resolve();
    } 
  })
}

function testPromise(){
  let config = {....}
  getSomething().then(()=>{
     #use config
     goOn(...config)
  })
}

testPromise();

У нас есть вызванная 1 раз функция testPromise, которая получает из функции getSomething промис, в который с помощью метода then сохраняет колбэк, удерживающий в замыкании переменную config. Сам промис она нигде не сохраняет, что здесь очень важно.
В функции getSomething мы просто возвращаем промис созданный через его конструктор, который как мы уже знаем нигде больше не сохраняется. И на этом могло бы все и закончится, без вызова колбэка независимо ни от чего. Но конструктор промиса выполняет свой колбэк синхронно, а кроме того он передает в него 2 функции - resolve и reject, которые в своем замыкании ссылаются на только что созданный промис (а это уже 2 ссылки на него, хотя мы то его никуда не сохраняли). Переменная reject никак не используется, а значит спокойно может быть удалена после завершения колбэка. Переменная resolve просто вызывается как функция внутри условия, но более тоже никак не используется и никуда не сохраняется, а значит так же может быть удалена.

В этом примере. если sys_condition = false и resolve не вызовется, это значит что создается утечка памяти

Нет, утечки памяти не будет. Колбэк созданный в testPromise будет удален вместе с замыканием, так и не вызвавшись ни разу.