LEV19

В чём собственно сложность?
В таблице делаешь ссылку на события в реакт компоненте на добавления вещи в localstorage (ls), заодно и показывания модального окна. Содержимое окна берётся из ls и красиво парсится в html. Разумееется идёт работа через state и render.
При нажатии "оформить заказ", активируется другое событие, которое тоже показывает уже красиво сделанное окно с готовым заказом.
Работа с ls и отображение содержимого можно глянуть в простеньком компоненте : https://github.com/DarkScorpion/React-OpenWeather-...
Так 3 ветки: просто strict mode, ES6, Webpack. Выбирай любую которую проще понять.
UPD: Добавил ветку Redux. Он как раз предназначен для взаимодействие между компонентами на одной странице. Он является по сути центральным хранилищем состояний. Эта ветка больше подходит для решения вашей задачи. Redux это реализация архитектуры flux, её желательно почитать, чтоб лучше разобраться в примере.

1. Для чего замыкание существуют?

Для инкапсуляции данных.
В ООП есть модификаторы доступа (private, protected), которые закрывают доступ к данным извне класса, но позволяют обращаться к ним из методов.
В ФП для этой задачи используют замыкания, закрывая данные внутри функции. Из вне данные недоступны, но вложенные функции имеют к ним доступ.

2. В каких условиях они создаются?

Когда вложенная функция обращается к переменным внешней функции.

Хоть и просили без примеров, но на примере показать проще:

// makeCounter - внешняя функция
function makeCounter(initialValue) {
  var value = +initialValue || 0;
  // counter - внутренняя функция
  // она использует переменную value из внешней функции
  // что-бы это было возможным, для counter создается замыкание,
  // в котором хранится переменная value
  // переменная initialValue функции counter не нужна, поэтому ее можно "забыть"
  return function counter() {
    return value++;
  };
}

// у нас 3 экземпляра функции counter
var counter1 = makeCounter();
var counter2 = makeCounter();
var counter3 = makeCounter(100);
// и для каждой есть своя переменная value
console.log(counter1()); // 0
console.log(counter1()); // 1
console.log(counter2()); // 0
console.log(counter1()); // 2
console.log(counter3()); // 100

// а вот получить как-то напрямую переменную value мы не можем
// инкапсуляция нам не дает поломать данные

Web технологии более универсальны. Хорошо изучив JavaScript можно писать и фронтэнд и бэкенд как для сайтов, так и для мобильных приложений. С таким багажом вы точно не пропадёте, и всегда найдёте работу хоть здесь, хоть за рубежом. Но там мода меняется постоянно, регулярно появляются и исчезают всё новые и новые фреймворки, и успевать за всеми тенденциями будет крайне тяжело.
Если сосредоточиться только на мобильной разработке, скажем на Swift, под iOS, то там минимальная планка по зарплате выше, и войти в этот рынок будет легче (правда нужен Мак).
А вообще сейчас эти 2 сферы всё больше переплетаются. Бэкенд и для сайтов и для мобильных приложений пишется примерно одинаково.
Так что зная только JS и пачку современных фреймворков, вы точно не пропадёте, а что окажется ближе можете решить по ходу обучения.

Для начала будущему джуну не плохо бы сходить на сайт реакта, и прочитать там большими буквами, что Реакт - ни разу не фреймворк, а очень даже "A JavaScript library for building user interfaces".

Во вторых будущему джуну надо осознать, что если он так неаккуратен в терминологии, то в разработке ему будет трындец как сложно. Компьютер, в отличии от человека, воспринимает все буквально и делает ровно то, что сказано. И если сказано неточно, то результата не будет.

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

Исходя из личного моего опыта, утверждаю что первый пункт описывает эталон джуниора, на практике не у многих мидлов существуют теор и практ знания по всем перечисленным пунктам. Антон Спирин Пожалуйста, поясните с вашей точки зрения необходимость 7 пункта , в 3 пункте что вы вкладываете в умение работать с dom моделью? Императивный стиль с деревом ,нодами пропертями htmlelementов? Зачем знание xmlhttprequestов, если в любом сторонней библе эта функциональность скрыта за слоем абстракции написанной вендором. Дмитрий Есин, вы допускаете тот факт что писать промышленный реюзабельный код в серверсайдрендер проекте в императивном стиле на каком-нибудь жкери, где отсутствуют строгие конвеншны к построению архитектуры клиента, сложнее, чем в ясном и продуманном окружении реакта?

Доброго времени суток. Все вопросы указанные в посте, сами по себе невозможно ответить прямо в абсолюте.

Сама по себе профессия и специалист строится от отношения к работе и отношению к самому себе.
Поэтому отвечу из своего опыта.

Вы говорите о том, что такая работа может приносить удовольствие. Все зависит от точки зрения, кому и что нравится, но не стоит забывать о мире. Как минимум в профессии есть пару очень неприятных трудностей.
1 - неправильное тз - таким образом не понятно, что от тебя вообще хотят.
2 - всезнающие заказчики - типичные мозгоеды, которые непонятно чего хотят и не понимают даже принципов вашей работы
3 - ДЕДЛАЙН`s - по большей части время исполнения ограничено сроками и всем плевать на сложности во время разработки(обычно редко что-то проходит гладко(из разряда: пропустил запятую и 3 часа искал где))
4 - отношение к профессии - многие относятся к программистам принебрежительно ибо "мы просто нажимаем кнопки", а творческо-технический уклад жизни никого не интересует т к иногда приходится придумывать то, чего до этого вообще не было.

Что касается заработной платы:
Согласен, мнение разнится.
Все зависит от многих факторов(как думают):
- Навыки
- Знания
- Опыт
- Коммуникабельность
Дело в том, что от первых трех не зависит заработная плата программиста(от слова вообще) т к никто из нанимателей не сможет оценить твои знания лучше чем иной программист(ито не факт(если подходы отличаются)), поэтому важно умение договариваться. От того главная проблема: "будь ты хоть нинзя кода, то веселого дурочка ты не обойдешь".
-- в моем случае, последнее намертво отсуствует, поэтому, для меня, важно портфолио.

По поводу конкуренции:
Вся конкуренция разнится от типа специалиста и языка/технологии. Одни более важны, другие менее востребованы, но все это мода, не более.
Например: проекты, которые написаны с нуля стоят того ибо они более продуманы и целостны, но в текущее время нужны "кубики", которые быстро собираются, быстро приносят прибыль.. и быстро разваливаются.
НО конкуренция в россии, на самом деле высокая. Мода на информационные техноогии сделала свое дело, поэтому сейчас множество "болтливых бездарей" окупировали рынок и это плохо. Общее мнение упало, цены упали, уровень среднего программиста упал ниже табуретки.

Частое обучение:
На самом деле нет особой необходимости постоянно учиться. Отточенная техника и навыки более высоко ценятся т к почти все задачи возможно сделать и с устаревшими технологиями и в разы лучше, главное самостоятельно решать данные вопросы, а "не бегать в интернеты"(от этого и появляются "новые технологии").
Однако, как уже говорил, для ценности на рынке необходимо идти по моде, поэтому иногда необходимо осваивать ту или иную технологию.

Время и здоровье:
Все зависит от самого человека.
Если взять меня, то над прошлыми проектами работал, буквально, сутками, создавая новую архитектуру для программной машины и составляя алгоритмы. Как и сейчас.. собственно. Меня мое занятие увлекает полностью и забирает все силы, ибо создаю новое и не ляпаю по университетским, шаблонным и общепринятым схемам, ибо взгляды другие и задачи другие.
Если это просто работа и работаешь по шаблонным схемам, то много времени это не займет, но если ты создаешь, то это поглатит тебя полностью.
Думаю множество программистов со мной согласятся. Даже если программист не пишет код, то он все-равно работает т к нужно придумать алгоритм, разобрать технологии(нужно или нет в текущем случае) и, наконец, построить архитектуру для дальнейшей разработки. Эт не та работа, от которой можно отключиться, придя домой.

-- Весь ответ это сугубо мое мнение.

В яндексе можно верстать, разрабатывать алгоритмы для поисковых роботов, обучать Сири материться на болгарском, а можно оператором степлера или администратором уборной работать.
Для начала определись кем ты хочешь работать, а не где. А то ты 5 лет отучишься, а яндекс к тому времени закроется. Вся жизнь коту под хвост, хоть в петлю лезь.

Сначала нужно выучить русский, потом английский, потом HTML, CSS, затем JavaScript, а дальше как пойдёт.

То есть нужно, прежде всего, закончить школу с хорошими отметками в аттестате. А веб-технологии планомерно учатся по соответствующим учебникам + практика.

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

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

Я очень долго писал бухсофт, при этом не имея толком знаний по бухгалтерии. Я всегда работал в плотной связке с опытными профильными специалистами, по сути, являясь скорее переводчиком с человеческого на машинный. Причем профильные специалисты хорошо выполняли своё дело, но молча, буквально как пленные партизане. Поэтому моей первейшей задачей всегда было разговорить бухгалтера, помочь осмыслить и сформулировать в мельчайших деталях процессы, которые они на автомате делают ежедневно в течении многих лет. Разумеется никаких ТЗ я никогда в жизни в глаза не видел. Вернее так, ТЗ я формировал себе сам из того, что удалось выведать у бухгалтеров и их руководства.

Один из вариантов разговорить - это прийти и рассказать своё видение. Люди любят поправлять, вносить коррективы, добавлять деталей. :) Это называется посплетничать. :)

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

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

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

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

Из раза в раз ты начинаешь производить одни и те же действия, а что делает программист, когда процесс повторяется хотя бы трижды? Правильно, автоматизирует. Только тут ты уже автоматизируешь свой труд, и именно так рождаются всевозможные библиотеки, фреймворки, компиляторы и прочие крутые инструменты разработчика. Но сначала нужно собрать обширный ворох всевозможных граблей и налепить десяток горбатых...

Внезапно выясняется, что во всех этих процессах софтскиллы рулят и решают.

В общем мой совет - качай всё, особенно софтскиллы и отставить кукситься.

ПыСы: Большинство сотрудников в компаниях, где ты будешь обитать, будут считать тебя то ли кудесником, то ли магом, то ли телепатом, то ли всё вместе. Каждый будет искренне убежден, что ты знаешь все то же самое, что знает он и плюс еще кучу всего, чего они не знают, поэтому будут грузить всем чем угодно. Так же будут искренне верить, что ты обладаешь доступом в пятое измерение, что у тебя времени вагон (т.е. примерно 48 часов в сутках, а может и 72, кто тебя знает то...) и ты многозадачный. В общем будут проявлять все мыслимые и немыслимые формы неадеквата. Это нормально. Через это нужно пройти, научиться во всем это плавать, как рыба в воде. Это здорово прокачивает тебя как личность, если ты настроен на подобный прогресс.

Если же хочешь просто сидеть в сторонке и кодить, то тебе нужно искать компании/команды, где все айтишные процессы уже выстроены и формализованы, где всю эту работу за тебя уже сделали аналитики, манагеры, лиды. Где ты придешь на готовую архитектуру, с детальным описанием кодстайла. Где тебе будут скидывать посильные таски, продуманные и детально прописанные. Да, такие компании тоже существуют, но их нужно искать, т.к. они пока в меньшинстве...

Можно еще так, тогда будет происходить плавный переход:

a {
  position: relative;
}

a img:last-child {
  position: absolute;
  top: 0;
  left: 0;
}
a:hover img:first-child,
a img:last-child {
    opacity: 0;
    visibility: hidden;
    transition: visibility 150ms ease, opacity 150ms ease;
}
a:hover img:last-child {
    opacity: 1;
    visibility: visible; 
}

Хреновое у тебя настроение, 33 для програмиста не возраст, мне 42 и я несколько раз проходил путь от джуна до синьора, просто для встряски мозгов, последний раз менял специализацию в 39. Делай упор на английский, с хорошим английским работы море, при чем на удаленке платят больше чем на аутстаффе, правда и риски больше, кстати чтобы устроится на мидла, не запись в трудовой нужна "работал джуном год", а фактическое количество собранных граблей на технологии, на которые ты второй раз не наступишь, на собеседованиях просто спрашивают по матрице, поэтому необходимые навыки ты легко можешь узнать, просто регулярно проходя собеседования и подчитывая и реализуя то, на чем завалился. Завалив собеседование ты не ЧСВ должен понижать, а просто понимать, что ты узнал, что нужно доучить и идти на следующее собеседование.

Не вижу ничего плохого в подключении jQuery через cdn (Яндекса или Гугла) - для пользователя остается незамеченным ибо кешируется, т.к. используется чуть менее чем на всех сайтах. А т.к. веб проекты как правило имеют свойство меняться - придется что-то доделать - а у вас только ваши функции.

Ну вы можете пройти тест на том же https://learn.javascript.ru/quiz
Но надо еще понимать, что каждый проводит тестовое задание по своему. Кто-то будет требовать от вас отличные знания прототипов, а кто-то классов. Кто-то будет спрашивать про промисы, новые штуки, а кто-то классические штуки. Слишком относительное понятие - базовые знания.
Мне кажется, базовые знания JS сейчас - это поверхностное знание всех штук языка, но пока что не умение их применять в нужных задачах. Сможете пройти все тесты на https://learn.javascript.ru/ в конце глав, думаю можете идти на собеседование. Но лучше еще поделать проектов своих, чтобы увереннее себя чувствовать в этих знаниях, и уметь обосновать их надобность.