Немного теории

useEffect

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

useEffect - хук эффекта, который аналогичен комбинации componentDidMount, componentDidUpdate и componentWillUnmount. Он принимает в себя два параметра - callback и массив зависимостей. Массив зависимостей представляет из себя набор переменных, на изменение которых подписывается наш хук, и, соответственно, при их изменении вызвается переданный нами callback. Посмотрим за работой хука на примере:

import React, { useState, useEffect } from "react";

export const Effect: React.FC = () => {  
  const [counter, setCounter] = useState(0);
  
  useEffect(() => {
    console.log(counter);  
  }, [counter]);
  
  const incrementCounter = () => setCounter(counter + 1);
  
  return (    
    <div>      
      <button onClick={incrementCounter}>INC</button>    
    </div>  
  );
};

В данном примере у нас есть счётчик (переменная counter), функция увеличения счётчика и эффект, который реагирует на это изменение. Что же у нас будет в консоли ?
Для начала - наш эффект сработает как componentDidMount и после первого рендера выведет в консоль начальное значение перменной counter, а именно - ноль. Каждое нажатие кнопки будет изменять нашу переменную стейта и эффект будет работать по принципу componentDidUpdate. Важно запомнить, что useEffect работает в асинхронном режиме и вызывается после того, как в DOM были внесены изменения.
С первыми двумя методами мы определились. Но как же вызвать componentWillUnmount ?
Для этого, callback который мы передаём в useEffect должен иметь return. Немного изменим наш код:

import React, { useState, useEffect } from "react";

export const Effect: React.FC = () => {  
  const [counter, setCounter] = useState(0);
  
  useEffect(() => {
    console.log("componentDidMount/Update", counter);
    
    return () => console.log("componentWillUnmount", counter);  
  }, [counter]);
  
  const incrementCounter = () => setCounter(counter + 1);
  
  return (    
    <div>      
      <button onClick={incrementCounter}>INC</button>    
    </div>  
  );
};

Что же произойдет, если мы запустим этот компонент и нажмём кнопку ?
Сначала - произойдет рендер компонента, после чего, useEffect сработает как componentDidMount и выведет в консоль "componentDidMount/Update 0".
После нажатия на кнопку, произойдет размонтирование компонента и выполнится callback, который мы описали в return, то есть, наш эффект сработает как componentWillUnmount и выведет в консоль "componentWillUnmount 0". Почему именно ноль ? Потому внесение изменений в состояние компонента происходит после его размонтирования.
Ну и наконец, после обновления нашего компонента мы в консоли увидим запись - "componentDidMount/Update 1"

useLayoutEffect

С работой useEffect разобрались, теперь перейдём к useLayoutEffect.
У него есть всего два отличия от useEffect:

1) Синхронное выполнение
2) Выполнение хука происходит ДО рендера

В принципе, это всё, что нам нужно знать про useLayoutEffect из теории, рассказывать про него больше нечего. Однако, самое интересное будет на практике.

Когда и что использовать?

Итак, теперь посмотрим наглядно, когда лучше использовать useEffect, а когда - useLayoutEffect.
Самый главный, на мой вгляд профит, можно получить от useLayoutEffect в том случае, когда нам необходимо вычислить и установить какие-нибудь стартовые параметры для компонентов, которые мы хотим отрендерить. Посмотрим на пример:

export const Effect: React.FC = () => {  
  const [bgColor, setBgColor] = useState("red");
  
  useEffect(() => {    
    setBgColor("blue");  
  }, []);
  
  return (    
    <div style={{ width: "200px", height: "200px", background: bgColor }}>
    </div>  
  );
};

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

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

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

Заключение

Мы выяснили, что useLayoutEffect - неплохое средство оптимизации компонента. С помощью него можно предотвратить лишний update компонента, предварительно произвести вычисления или засетить нужные значения в state.

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

Стек

Стек - коллекция элементов, работающая по принципу LIFO (Last-In First-Out). Самой простым примером стека, который позволит тебе понять логику его работы является... корзина для белья! Да, та самая, в которую ты каждый вечер кидаешь свою одежду.

Принцип стека достаточно прост - мы имеем прямой доступ только к последнему добавленному элементу (Майка 6). Продолжая говорить метафорами - дотянуться до самой нижней майки ты можешь только тогда, когда достанешь все остальные.
Соответственно, для реализации стека нам необходимо только два метода - push (кинуть майку наверх корзины) и pop (достать верхнюю майку). Вот пример реализации класса Stack на Typescript:

export class Stack<T> { 
  private items: Array<T>

  getCount() { 
    return this.items.length 
  }
  
  push(elem: T) { 
    this.items.push(elem) 
  }

  pop() { 
    if (this.items.length) { 
      return this.items.pop() 
    } else { 
      throw new Error('Empty stack!') 
    } 
  }

  constructor() { 
    this.items = [] 
  } 
}

Да, многие скажут, что это не стек в чистом виде. В некотором плане, мы ограничены возможностями Javascript при разработке таких структур. В других языках, в которых есть возможность работать с памятью напрямую - мы бы не использовали массивы для имитации стека. К примеру, в C++ каждый элемент представлял бы собой объект, имеющий два поля: value - непосредственно, данные, и next - ссылка на следующий в стеке элемент. Это позволяло бы классу Stack не хранить данные внутри экземпляра, достаточно было бы хранить ссылку на верхний элемент стэка. Для сильно придирчивых - в конце статьи оставлю ссылку на реализации стэка, очереди и других структур в чистом (насколько это мне позволит JS) виде.

Очередь

Теперь поговорим об очередях. Общая суть - тот же стек, только принцип FIFO (First-In First-Out). То есть, мы теперь имеем доступ не к верхнему элементу, а к нижнему. Пример - очередь в магазине. Ты подошел на кассу первый - из магазина выйдешь тоже первый. Элемент имеет такую же структуру, что и в стеке, но оглавление указывает на начало списка. Упрощенную реализацию с помощью массивов приведу здесь, для истинных программистов - ссылка будет в конце статьи.

export class Queue<T> { 
  private items: Array<T>

  getCount() { 
    return this.items.length 
  }
  
  push(elem: T) { 
    this.items.push(elem) 
  }

  pop() { 
    if (this.items.length) { 
      this.items.reverse()
      const popElem = this.items.pop() 
      this.items.reverse()
      
      return popElem
    } else { 
      throw new Error('Empty queue!') 
    } 
  }

  constructor() { 
    this.items = [] 
  } 
}

В упрощенной реализации единственная разница со стеком будет в строчках с reverse(). Она обусловленна тем, что доставать элемент нам нужно с низа, а не с верха, как в стеке. Реализация для гуру будет отличаться более существенно и есть поле для дебатов.
Подходов к реализации достаточно много. Самым простым путём является хранение двух указтелей - на начало и конец очереди. Это облегчит реализации push и pop методов. Однако, она идёт в разрез с определением очереди - доступ должен быть только к первому элементу.

Есть варианты с рекурсивными добавлением и извлечением элементов, однако, сложность функций будет заметно хромать.

На практике

Теперь поговорим немного о практическом применении во Frontend.

Возможно, писать руками тебе эти структуры и не придется, однако, знать о них очень и очень важно, поскольку, весь JS работает на стеках и очередях (вспомни Event Loop). Очередь микрозадач, стек вызовов - реально представляют из себя ОЧЕРЕДЬ и СТЕК соответственно, а не просто названы так для красоты. В реальных же кейсах, это может пригодиться, если ты будешь писать собственный wrapper для API вызовов, и тебе придется самостоятельно организовывать кастомную асинхронную структуру вызовов методов API. Случай достаточно нетривиальный, однако, имеет место быть. В рядовых задачах, связанных с интерфейсами и шаблонной логикой работы с API ты, скорее всего, не столкнёшься с такими кейсами.

Заключение

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

Для трушных кодеров - ссылка на песочницу с примерами реализации.

Ставь реакцию, подписывайся на канал, зови друзей - дальше будет еще интереснее!

1. Попросить обратную связь

Почему то, очень многие рзаработчики вообще не интересуются мнением интервьюера о себе с технической стороны:

• Я же получил оффер, зачем мне знать, где я накосячил
• Я же не получил оффер, мне всё равно, что он обо мне думает

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

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

Из личного опыта - я стараюсь раз в 2-3 месяца ходить на собеседование в более или менее солидную компанию, не с целью найти местечко потеплее, а именно для того, чтобы попросить обратную связь и подтягивать образовавшиеся пробелы. Это дейтсвительно очень крутой опыт, ведь программирование - это не только про код, теорию никто не отменял!

Ну и естественно, грамотно составляй свою просьбу. Не надо говорить что-то такое: "Ну чё, как я тебе ? Хорош ? Техлидом берете на 600к в месяц с блэкджеком и коллегами-девушками квартальной премией ?". Старайся просить об этом ненавязчиво, однако, дай понять, что тебе это важно. Хорошим вариантом будет: "Хотел бы уточнить, могу ли я, независимо от результатов нашего общения получить от тебя фидбэк? Было бы очень круто узнать твоё мнение о моих скиллах!", или так: "Могу ли я рассчитывать на обратную связь при любом твоем решении по моей кандидатуре? Я всегда стараюсь работать над собой, и мне было бы очень полезно твое мнение!"

2. Узнай подробнее об условиях работы

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

Странная ситуация?
Абсолютно нет!

Очень часто, разработчиков нанимают на конкретный проект. Их не берут в штат, а устраивают на определнный срок (обычно - предполагаемая длительность проекта + 1 месяц на форс-мажоры), после чего, договор не расторгается, а просто истекает. Поэтому, перед тем как устраиваться на работу очень важно уточнить, на каких условиях ты устраиваешься. Разумеется, лучше всего это сделать ещё ДО технического собеседования, т.к. HR обычно знает, на какую позицию ищут кандидата, но если вдруг ты этого не сделал - не стесняйся спросить это после интервью.

3. Уточни про методологии разработки

Если ты уже достаточно крепкий разработчик и хочешь устраиваться в биг-тех (или что то около лежащее), то обязательно спроси у интервьюера о процессах в команде. Скорее всего, тебя будет собеседовать опытный разработчик, с достаточным стажем в компании, поэтому он сможет развернуто тебе ответить. Заранее скажу, абсолютно нет смысла спрашивать это у HR, потому что они, в данном случае, либо не ответят, либо отбрехаются заученными словами, по типу: "Всё по Scrum'у, двухнедельные спринты, демо, митинги, ретро, интро, аутро, приквел, сиквел" и т.д.

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

4. Уточни, как относятся к нововведениям

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

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

5. Спроси про целевую отрасль компании

Возможно, не совсем правильно сформулировал заголовок, просто прочитай и ты всё поймешь.

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

Я устраивался в, как мне казалось, крутую компанию: корпоративный сайт, неплохая зарплата, хорошо составленная вакансия (к слову, Middle React разработчик, з/п 80.000 рублей на 2019 г.). Собеседование я прошел весьма успешно, и, буквально через 3-4 дня я уже вышел на работу. Тут же мне подкинули весьма интересный проект на React, однако, почти не дали в него погрузиться и сразу же начали спамить рельными задачами. И не такими, чтобы узнать проект, а-ля "перекрась кнопку", "подвинь блок", "уменьши padding" и т.д. А реальными сложными тасками, связанными с логикой работы Redux-хранилища. Плюсом, поставили за мной ментора, который оказался достаточно токсичным человеком и не особо любил погружать новичков в проект.

Буквально через пару недель, данный персонаж пошел к начальству и сказал, что я очень сильно туплю и не могу втянуться в проект. После чего моя работа стала адом. Весь прикол был в том, что компания по своей сути являлась Digital-агентством, которое живёт за счёт огромного количества мелких заказов. После того, как меня с позором выгнали с проекта на React (напомню, вакансия была - Middle React разработчик), мне каждый день начали подсовывать мелкие задачи на мелких проектах на Bitrix, WordPress и т.д. Изменить меню, подвинуть кнопку, перекрасить блок - все эти задачки приходилось делать каждый день по нескольку штук на нескольких разных проектах. За неделю проектов могло быть больше 10 (!!!). Надолго я в этой компании не задержался.

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

Итог

Не стесняйся задавать вопросы своему интервьюеру или будущему работодателю. Проявляя интерес, ты показываешь, что тебе не безралична данная вакансия и действительно нацелен стать частью команды. Однако, не старайся спрашивать, когда вопросы закончились. Мысли по типу "Блин, я так мало спросил, спрошу ещё что-нибудь" обычно порождают всяких бред. Старайся не задать вопрос для галочки, а получить действительно полезную информацию. Твоя цель - понять, насколько тебе подходит данное место для начала или продолжения твоей карьеры.

Если понравилась статья - ставь лайк, подписывайся, зови друзей, для меня это очень важно! Дальше будут еще более интересные статьи!

Семантика

Итак, семантика. Что же это ?
Семантика - смысловая нагрузка отдельной языковой единицы. Ранее, это понятие было актуально исключительно для лингвистики, но теперь - применимо и в сфере Frontend-разработки. Самое интересное, что в HTML семантика имеет тот же смысл, только в качестве языковой единицы выступает отдельно взятый тэг. Как и всегда, рассмотрим на примере:

<html> 
  <head>   
    <title>
      My first page
    </title>
  </head>
  <body> 
    <div> 
      <div class="text">Hello, world!</div>
              
      <div class="button">SignIn</div> 
    </div> 
  </body>
</head>

Казалось бы, а что здесь не так ? У нас есть текст и кнопка, всё же замечательно!
Но нет. Дело в том, что данный фрагмент кода не является семантически правильным.

Скорее всего, если ты достаточно любопытный, ты уже посмотрел, какие вообще бывают HTML-тэги и сколько их всего. Даже если не смотрел - отвечу: их больше сотни. Сто разных HTML-тэгов !!!
А раз нам предоставили такое разнообразие - то, наверное, для этого есть причина... И она кроется, опять же, в семантике. Забегая вперёд скажу - многие из этих тэгов ты вообще не будешь использовать, или будешь, но крайне редко. Однако, необходимо понимать, что у каждого из них есть своя специфическая роль и нельзя всю веб-страницу собирать из одного единственного тэга.

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

Возникает логичный вопрос: а как же тогда правильно ?

Пишем семантический код

Давай вернемся к нашему примеру и посмотрим, что же у нас должно быть на нашей страничке:

И именно здесь заключается наша ошибка. Текст и кнопка должны быть обернуты в соответствующие тэги:

• <p> - параграф (абзац), служит для отображения одного абзаца текста.
• <button> - кликабельная кнопка, необходима, как ни странно, для добавления кнопки на веб-страничку.
• <div> - блочный элемент, элемент-контейнер для контента в вёрстке.

То есть, наш код после всех исправлений будет выглядеть примерно вот так:

<html> 
  <head>   
    <title>
      My first page
    </title>
  </head>
  <body> 
    <div> 
      <p class="text">Hello, world!</p>
              
      <button class="button">SignIn</button> 
    </div> 
  </body>
</head>

Зачем это нужно ?

Справедливый вопрос.
В программировании есть такой важный принцип, который применим в любой области - принцип KISS (Keep It Simple, Stupid), что в переводе означает "делай это проще, идиот". Данный принцип говорит нам о том, что для любой задачи необходимо выбирать самое простое и лаконичное решение.

Тогда зачем нам 100 с лишним HTML-тэгов ?
Ответ прост - потому что это самое простое решение проблемы. А проблема в следующем - браузер должен по разному отображать и обрабатывать содержимое каждого тэга. Даже если это не видно, даже если это не оказывает влияния на вёрстку - каждый тэг нужен для конкретной задачи и для каждого тэга у браузера свой алгоритм обработки содержимого.

К примеру, к уже знакомому нам тэгу <p> браузер автоматически добавляет отступы сверху и снизу (margin-top и margin-bottom) высотой в 1em, только если ты не укажешь ему этого не делать.

К тэгу <button> браузер автоматически добавит целую кучу стилей и сам отобразит содержимое, как кнопку:

<button>Кликни меня!</button>

И это без всяких CSS-стилей!

Так же, существуют менее заметные, но не менее важные функциональные аспекты семантических тэгов:

1. Корректная обработка сайта роботами.
   Поисковые роботы автоматически понимают, что в тэге <nav> у нас располагается навигация сайта, и, поэтому, могут корректно и красиво это обрабатывать в виде меню прямо на странице поиска.
2. Адаптивность сайта для людей с ограниченными возможностями.
   Человек, к примеру, с плохим зрением часто при веб-серфинге пользуется голосовыми помощниками, которые так же "смотрят" на семантику и определяют, что находится у человека под курсором в данный момент.
3. Организация кода.
   Ну и конечно же, чистый код - наше всё. Код, в котором каждый тэг отвечает за определённый контент легче читать и поддерживать, поэтому настоящие трушные разработчики всегда уделяют этому внимание.

Итог

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

Надеюсь, статья была тебе полезна, подписывайся на канал, ставь лайки - это ускоряет выход следующей статьи и мотивирует меня!

1. Что такое стэйт и пропс в React ?

Стэйт (state) - это объект, который хранит информацию о текущем состоянии компонента. В нём может быть заключена любая информация, которую разработчик хочет использовать для корректной работы компонента. Любое изменение стэйта влечет за собой ререндер компонента.

Пропс (props) - по своей сущности, это любой параметр, с которым может быть вызван компонент. Существуют зарезервированные пропсы (children) и пользовательские пропсы - любое значение, которое разработчик передает в компонент.

Я считаю, что данный вопрос актуален ТОЛЬКО для собеседования разработчиков уровня Junior. Любой разработчик у которого есть хотя бы месяц опыта работы на коммерции с React.js легко объяснит эти два термина, поэтому, нет смысла спрашивать такие примитивные вещи у более опытных кандидатов.

2. Зачем использовать callback в setState() ?

Использование callback в setState() позволяет обращаться к актуальному состоянию стэйта при его обновлении. Данный код не сработает так, как нужно, пока мы не будем использовать callback:

// Прибавить число 6 к переменной стэйта

const add = () => {
  setState(counter + 1)
  setState(counter + 2)
  setState(counter + 3)
}  // не сработает, всегда будет прибавляться 3 ввиду асинхронности setState

const add = () => {
  setState(counter => counter + 1)
  setState(counter => counter + 2)
  setState(counter => counter + 3)
} // будет работать корректно

Конечно, пример в реальных кейсах не встречается, однако, он прекрасно демонстрирует использование коллбэк-функций в setState.

На моей практике, не так много разработчиков уделяют должное внимание данному подходу. Лично встречал ребят, которые оценивали себя как Middle/Middle+ разработчики и не знали о данном подходе. Хороший вопрос, однако, лучше всего его задавать на примере задачи (к примеру, код выше можно преобразовать в задачку и попросить кандидата исправить его).

3. Что такое VDOM ?

VDOM (Virtual Document Object Model) - основная сущность, с которой работает React. VDOM является полной копией DOM-дерева и необходим для того, чтобы проверять необходимость изменения реального DOM. Так как рендер - самая затратная операция для браузера, концепция React с использованием VDOM для регистрации изменения существенно ускоряет работу веб-приложения.

Данный вопрос очень и очень актуален, т.к. существует огромное количество разработчиков-практиков - ребят, которые неплохо пишут код, но абсолютно не знают, как он работает "под капотом". В общих чертах, любой джун должен уметь объяснить, что такое VDOM и для чего он нужен. Более глубокие познания в данном вопросе можно начинать требовать с кандидатов уровня Middle/Middle+.

4. Что такое HOC (High-Order Components) ?

HOC - это компонент высшего порядка, целью которого является использование специального пропа children и манипуляция с ним. Данный тип компонента в основном используется для добавления какой-нибудь кастомной логики к дочерним компонентам. Любой Provider из популярных библиотек (redux, react-context, styled-components и др.) является HOC.

Соглашусь, что данный вопрос имеет место быть в собеседовании, однако, требовать полного и академичного ответа на него не стоит. Я бы лично перефразировал данный вопрос в нечто такое: "Приведи пример любого High Order Components". Если кандидат способен без долгих раздумий ответить, значит он точно знает и использует данный подход для организации своих компонентов.

5. Почему React использует className, а не class?

Так как JSX является расширением Javascript, а в Javascript есть ключевое слово class, разработчики данного синтаксиса решили использовать className.

Не вижу особого смысла в данном вопросе. Максимум, что он сможет показать, так это уровень саморазвития и/или любопытства разработчика. Если он знает про такие мелочи, значит человек действительно или любознателен от природы, или горит своим делом настолько, что хочет знать всё и обо всём.

6. Что такое key в React ?

key - специальный проп, добавляемый к компоненту, который служит его уникальным идентификатором в процессе пересчёта (Reconciliation). Основные требования к key: уникальность и стабильность, иначе говоря, key не должен меняться в зависимости от перерендера компонента.

Важный вопрос. В зависимости от уровня кандидата этот кейс можно расширить дополнительными вопросами:

• можно ли использовать Index в качестве key ?
• как React проставляет key по дефолту ?
• существует ли случай, когда key нужен ВНЕ циклического рендера ?

Данный вопрос раскроет уровень понимания кандидатом общего механизма работы React и является одним из основных, которые задаю на собеседованиях я сам.

7. Что может вызвать rerender компонента ?

Для ререндера компонента в React существует всего 4 причины:

1. Изменение стэйта
2. Изменение пропсов
3. Ререндер родителя
4. forceUpdate

К данному вопросу моё отношение 50/50. С одной стороны - важно понимать, что кандидат знает, почему компонент может перерендериться. С другой стороны - формулировка достаточно простая и актуальна только для кандидатов уровня Junior/Junior+, для более опытных ребят это будет слишком просто.

8. Как использовать <label> в React ?

Синтаксис label в JSXотличается от аналогичного синтаксиса в HTML ввиду того, что "for" является ключевым словом в Javascript, поэтому необходимо использовать htmlFor.

Данный вопрос - лучший аналог вопроса №5. Если кандидат знает про такие нюансы использования тэгов в JSX, значит он как минимум сталкивался с такими кейсами и понимает, почему "for" не работает для <label> в JSX. Вопрос не является основным, но задать его после определения термина JSX будет неплохой добивкой для блока.

9. Что такое renderProp в React ?

renderProp - механизм делегирования логики рендера родительскому компоненту. Данный подход позволяет не описывать логику работы тупых компонентов в отдельном файле, а вынести её в компонент-родитель.

<DataProvider render={(data) => <h1>{`Hello ${data.target}`}</h1>} />

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

10. Почему нельзя изменять пропсы из дочернего компонента?

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

Вопрос нацелен так же на понимание философии React. Одним из основных принципов является Top-Down - пропсы регулируют поведение дочернего компонента, а не дочерний компонент диктует поведение пропсов. Вопрос может быть задан кандидатам любого уровня, а развернутость ответа укажет на уровень кандидата.

Заключение

Я разобрал для тебя вопросы, которые мне показались наиболее интересными из списка. В следующей статье на эту тему мы продолжит разбирать вопросы с собесов и пообщаемся на тему дополнительных библиотек в React, таких как React Router, Redux и др.
Подписывайся на канал, ставь лайки - так статьи будут выходить ещё чаще!

Ссылочные типы

Немного освежим в памяти основное отличие ссылочных типов от примитивных - при создание переменной ссылочного типа невозможно заранее знать, какой объем памяти ей потребуется для хранения данных. В связи с этим, ссылочные типы данных имеют некоторые особенности при работе с ними. В частности - когда мы будем говорить о сравнении объектов (которые являются ни чем иным, как ссылочным типом данных), об их присваивании другим переменным и изменении значений нам нужно иметь ввиду, что на самом деле, в переменной находятся не сами данные, а ссылка на ячейку памяти с данными. Проще всего посмотреть это на примере:

const object1 = { name: 'Alex' }

То есть, когда мы обращаемся к переменной, мы получаем адрес ячейки памяти с данными и идём непосредственно к этой ячейке, после чего получаем возможность работать с ее содержимым.

Интересные вещи начинаются, когда мы пытаемся каким-либо образом манипулировать нашей переменной. К примеру, нам понадобился второй объект, который является копией первого. Вроде бы все достаточно просто:

const object1 = { name: 'Alex' }
const object2 = object1

Всё, круто, получилось... хотел бы я сказать, но нет.

Следует понимать, что в коде выше, в переменную object2 мы скопировали не сам объект, а ссылку на ячейку памяти. Следовательно - ситуация теперь такая:

"Ну и пофиг, данные то одинаковые" - первая мысль... Но не все так просто. Самое интересное будет, если мы попытаемся изменить object2. Я думаю, ты уже догадался, что произойдет:

const object1 = { name: 'Alex' }
const object2 = object1

object2.name = 'John' // вроде бы ок
console.log(object1.name) // будет выведено 'John'

Да, когда мы поменяем поле name в первом объекте - оно изменится и во втором. Произойдет это из-за того, что обе переменные хранят в себе ссылку на один и тот же объект.

Несмотря на, казалось бы, сложное поведение, такой подход к организации механизма хранения ссылочных типов может быть очень полезным. В частности, он позволяет реализовывать прототипное наследование - паттерн, на котором держится весь Javascript. Мы обязательно поговорим об этом подробнее в следующих уроках, скорее всего, будет отдельная статья на эту тему. Сейчас скажу простым языком - наследование ссылочных типов данных производится путем добавления к ним специально поля 'Prototype', которое, по своей сути, является ссылкой на объект-родитель и позволяет использовать его поля и методы.

Кстати о полях и методах, думаю об этом мы поговорим сейчас.

Поля (свойства)

Любой ссылочный тип данных может иметь собственные поля и методы. В коде выше мы уже объявляли поле 'name' у наших объектов. Из этих примеров можно вывести достаточно простое определение: поля (свойства) объекта - это пара "ключ-значение", которая может хранить в себе некий набор данных. Поля в свою очередь так же могут быть как объектами, так и примитивами. К примеру, давай создадим объект, который может охарактеризовать человека:

const people = {
  name: 'Alex',
  age: 23,
  city: {
    name: 'Moscow',
    postalCode: '101000',
  }
}

Что мы здесь видим ?

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

Методы

Помимо полей, объекты также могут иметь методы. Пока что, мы не будем писать кастомные методы, поговорим об уже существующих.

Обратимся к структуре выше:

const people = {
  name: 'Alex',
  age: 23,
  city: {
    name: 'Moscow',
    postalCode: '101000',
  }
}

Предположим, что такие данные нам приходят с сервера, то есть мы самостоятельно не заполняем объект, его заполняет какой-то умный дядя-бэкендер и отправляет нам. Как мы можем убедиться, что поле 'city' существует у объекта? Для этого есть дефолтный метод hasOwnProperty. Методы вызываются от самих объектов через точку как обычная функция:

people.hasOwnProperty('name') // true

Что мы сделали ?
Простым языком - спросили у нашего объекта, имеет ли он свойство 'name', на что функция нам ответила true.

Примеры ссылочных типов

Помимо объектов, о которых мы уже достаточно поговорили, Javascript предоставляет огромное множество других ссылочных типов (которые, кстати, в любом случае наследуются от объекта).
Немного посмотрим на самые распространённые из них.

Array

Массивы - основа языка Javascript. Они позволяют хранить перечисляемые однотипные элементы. Например:

const myArr = ['zero', 'one', 'two', 'three']

Каждый элемент массива имеет свой индекс, нумерация которых начинается, естественно с нуля. Например, чтобы получить доступ к элементу 'one', мы будем использовать следующую конструкцию:

myArr[1] // 'one'

Индекс выбранного элемента указывается в квадратных скобках сразу после имени переменной.

Интересный факт: к полю обычного объекта так же можно обращаться через квадратные скобки. Для примера с Алексом из Москвы справедлива такая запись:

people['name'] == people.name // двойное равно используется для сравнения 

Date

Ещё один ссылочный тип данных - дата. Для создания даты мы будем использовать следующий вариант записи:

const currentDate = new Date()
console.log(currentDate) // Date Wed May 03 2023 02:16:17 GMT+0500 

Да, всё верно, на момент написания этой статьи у меня уже 2 часа ночи. Думаю, это заслуживает лайка и реакции на статью) Не забудь поделиться с друзьями, если тебе понравился материал.

Так же, помимо указанных выше типов существуют еще такие штуки как Map, Set, File, ArrayBuffer, Promise и другие ссылочные типы. Их очень много, каждый используется для конкретной задачи. Мы обязательно встретим их и обсудим более подробно.

Заключение

В этой статье ты научился работать с ссылочными типами данных, понял, как они хранятся в памяти и как передаются значения. Хорошим опытом для закрепления материала будет попытка поиграться с различными объектами - создавай их, изменяй, пробуй использовать различные методы, описывай в них всё, что видишь вокруг себя:

• компьютер - марка, модель, цена
• стол - материал, форма, количество ножек
• погода - температура, скорость ветра, направление, осадки

Это очень круто поможет тебе закрепить материал данной статьи.

Подписывайся, ставь лайки и реакции, рекомендуй канал своим друзьям - это все очень мотивирует меня писать как можно больше, чаще и интереснее!
До скорых встреч, успехов!

Подготовка

Я не буду начинать с рассказа про React, как, зачем и где его применять - это всё можно найти в первых двух ссылках в выдаче Google. Мы будем действовать максимально прямолинейно - создадим приложение, разберёмся, что к чему, и будем писать много-много кода.

Сама статья предполагает, что ты уже знаком с Javascript, умеешь верстать с помощью HTML/CSS и готов погружаться в мир серьезной веб-разработки.

Что нам нужно для начала:

• Установленный Node.js (среда выполнения JavaScript-кода, можно скачать тут)
• Редактор кода (рекомендую Visual Studio Code - клик)
• Эта статья и час свободного времени

Если всё это есть на твоём компьютере - мы можем начинать!

Создание приложения

Для начала, убедимся, что у тебя всё готово для работы. Откроем VS Code, внутри, в терминале введем команду

node -v

Если нет никакой ошибки, а в консоли ты видишь номер версии Node.js - то проверяем так же и npm (менеджер пакетов):

npm -v

Аналогично - если видем циферки, значит всё круто, можем создавать наше приложение.

Для создания приложения воспользуемся известным бойлерплейтом (стартовым шаблоном) create-react-app. Этот шаблон позволяет быстро и без лишних настроек перейти непосредственно к написанию приложения. Итак, находясь в нашей папке (которую ты предварительно создал для своего первого проекта), в терминале мы пишем следующую команду:

npx create-react-app first-app

Вкратце о команде:

• npx - утилита для запуска npm-пакетов
• create-react-app - пакет, реализующий стартовый шаблон React.js
• first-app - имя твоего приложения (можешь выбрать любое)

После установки приложения, у тебя появится папка с твоим проектом, примерно следующей структуры:

Чуть ниже по статье мы рассмотрим все файлы и папки, уберем все ненужное и напишем самостоятельно первое приложение, а пока что, давай наконец запустим наш сервер разработки и посмотрим, что получится. Открываем в консоли папку с нашим приложением и пишем:

npm start

Данная команда запускает Node.js сервер, на котором будет разворачиваться твоё приложение. После запуска - заходим на http://localhost:3000 и видим стартовую страницу create-react-app:

Окей, с этим разобрались. Теперь, давай посмотрим, что у нас есть в папке проекта.

Структура папок

node_modules

Самая первая и самая большая папка - это node_modules. На ней мы пока что не будем заострять внимание, скажу лишь, что это системная папка, в которой хранятся все используемые пакеты и модули для работы React-приложения.

public

Далее - папка public. В этой папке у нас лежат ресурсы нашего приложения.

• favicon.ico - фавиконка для веб-странички
• index.html - непосредственно, веб-страница, в которую React.js будет рендерить наше приложение.
• manifest.json - общая конфигурация твоего сайта. Там можно хранить разную информацию об авторе, версии, теме, ресурсах и т.д. Подробнее про манифесты можно прочитать тут, мы не будем сильно заострять на этом внимание (пока что).
• robots.txt - так же, системный файл, необходимый для корректной индексации твоего сайта роботами.

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

src

Это - самая главная и интересная папка. В ней находится точка входа в React-приложение и все его компоненты. Именно в этой папке ты будешь работать большую часть времени. Давай для начала приведём ее в надлежащий вид:

На данном этапе, нам не нужны тесты, веб-воркеры и отдельные CSS-модули. Оставляем только index.js - точка входа в приложение, App.js - главный компонент твоего приложения и index.css - глобальный файл стилей. Так же добавляем две новые папки: components - для хранения наших компонентов, pages - для хранения страниц. К этим папкам мы обязательно вернемся в следующих уроках, на данном этапе они нам не понадобятся.

Hello, World!

Теперь, для того чтобы наше приложение не падало с ошибкой - уберем все лишнее.

index.js:

import React from "react";
import ReactDOM from "react-dom/client";
import App from "./App";

import "./index.css";

const root = ReactDOM.createRoot(document.getElementById("root"));

root.render(  
  <React.StrictMode>    
    <App />  
  </React.StrictMode>
);

App.js:

const App = () => {  
  return <div className="App"></div>;
}

export default App;

index.css пока можно оставить пустым.

Сейчас, если ты откроешь браузер - ты увидишь пустой белый экран. Давай это исправим, и, по классике, напишем "Hello, World!" посередине нашей страницы.

Для этого, в файле App.js нам надо добавить контейнер для нашей фразы и вписать её внутрь:

App.js

const App = () => {  
  return (
    <div className="App">
       <div className="container">Hello, World!</div>
    </div>  
  );
};

export default App;

Обрати внимание, в синтаксисе JSX (расширение синтаксиса JavaScript для работы со стеком HTML/CSS/JavaScript в одном файле) имена классов для элементов обозначаются словом "className".

Так же, в наш пустой index.css добавим стили для контейнера:

* {  
  margin: 0;  
  padding: 0;
}

.container {  
  width: 100vw;  
  height: 100vh;
  
  background: black;
  
  color: #efab2b;  
  font-size: 5rem;
  
  display: flex;  
  align-items: center;  
  justify-content: center;
}

Результат на экране:

Итог

В этой статье мы с тобой развернули сервер разработки и написали наше первое приложение на React.js. Неплохой результат для небольшой статьи.

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

Подписывайся на канал, чтобы не пропускать выход новый статей, ставь лайки, зови друзей - давай создавать комьюнити вместе!

isolation

Для того, чтобы ты понял необходимость использования данного свойства, для начала, я коротко расскажу про такую штуку в CSS, как контекст наложения (stacking context). Не путать с "this" в Javascript, это разные вещи!
Итак, в CSS существует определённый набор свойств, который создаёт для элемента собственную вычислительную обёртку - контекст. Простым языком - для всех дочерних элементов данное свойство будет иметь не глобальное значение, а вложенное.
Допустим, у нас есть элемент с "z-index: 1". Добавим ему ребенка с большим индексом:

.block1 { 
  width: 200px; 
  height: 200px;
  background: red;
  position: relative;
  z-index: 1;
}
.child1 { 
  width: 100px; 
  height: 100px;
  background: blue;
  position: relative;
  z-index: 9999;
}

В данном случае, истинный "z-index" у дочернего элемента будет равен 1.9999
То есть вычисление будет производиться относительно родителя с данным свойством. Иначе говоря - block1 создал свой собственный stacking context.

Кроме "z-index" собственный контекст создают свойства "position", "opacity", "animation", "transform" и др.

А что если, нам позарез надо создать у элемента контекст наложения, но для свойства, которое его по дефолту не создаёт ? Тут нам на помощь и приходит свойство "isolation".

Используя данное свойство, можно указать элементу принудительно создать stacking context. Это может очень помочь в том случае, когда ты уже настолько запутался в огромных значениях "z-index" у своих элементов, что хочется их организовать более рационально. Порядок действий будет следующим:

1) Найти родительский элемент, для которого структура будет слишком запутанная

2) Создать wrapper для него, с недвусмысленным названием "stacking-context-1"

3) Применить isolation: isolate.

4) Получить готовый контейнер с отдельным контекстом

will-change

Как часто у тебя бывал такой кейс:

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

На самом деле, браузер пытается вычислить все свойства твоей анимации "на лету". То есть, любая промежуточная точка в анимации вычисляется только в тот момент, когда она действительно необходима. В том случае, если вычислений много или они достаточно массивные - ты можешь ловить freeze или даже полное зависание страницы.
Для оптимизации данного кейса и придумали свойство "will-change".

Это свойство как бы говорит браузеру, чтобы он вычислил все нужные значения заранее, а при срабатывании условия - просто воспроизвел их.

Однако, использовать данное свойство нужно с осторожностью, так как если на странице будет переизбыток "will-change" - тогда ты можешь ждать очень-очень долго самого первого рендера. В большинстве случаев, рациональным подходом будет являться обычная оптимизация кодовой базы анимаций.

accent-color

Посмотри на эту картинку:

Обычный стандартный чекбокс. Как известно, элементы взаимодействия с пользователем (input, select, option, textarea) очень привередливые к стилям.
Предположим, тебе нужно изменить цвет галочки с синей на золотистую. Неопытный разработчик сразу начнёт это делать через псевдоэлементы, "display: none" и прочие радости верстальщика. Но ты же читаешь этот канал. Ты умнее. Ты просто воспользуешься свойством accent-color и решишь проблему за секунду:

input[type="checkbox"] { 
  accent-color: #fcc050;
}

Если ты думаешь, что про это свойство знают все - ты заблуждаешься. Вот как на простой вопрос отвечают на StackOverflow:

... а ниже строк 56 великолепного кода на CSS.

Читать эту статью или писать кучу CSS ? Решай сам.

shape

Закончим эту статью очень интересной группой свойств.

Ты думаешь, я руками проставлял margin для каждого из этих параграфов?
Нет!
Для создания геометрических фигур в CSS достаточно использовать CSS Shapes.

Данное свойство накладывает небольшие ограничения на целевой элемент - он обязательно должен быть с фиксированными размерами, а так же - быть обтекаемым (float). Не слишком высокая цена, не правда ли ?
С помощью shapes можно создавать различные геометрические фигуры без объемной кодовой базы и изображений. Однако, для того чтобы закрасить созданную нами фигуру - нам необходимо использовать shape в комбинации с clip-path. Пример - закрашенный градиентом треугольник:

.circle { 
  float: left; 
  height: 200px; 
  width: 200px; 
  shape-outside: polygon(0 0, 0 300px, 200px 300px);  
  clip-path: polygon(0 0, 0 300px, 200px 300px);   
  background: linear-gradient(to top right, #86F7CC, #67D7F5); 
}

На этом от меня - всё. Ставь лайк на эту статью, это очень мотивирует меня!
Буду стараться писать качественный материал как можно чаще
Подписывайся на канал и следи за самой актуальной и интересной информацией в мире Frontend

:required

Псевдокласс :required позволяет найти любые input на странице, которые имеют атрибут "required". Это может быть полезно, когда поле, которое перед отправкой формы должно быть заполнено, нам необходимо стилизовать. Как всегда - посмотрим на примере:

// style.css
input:required { 
  border-color: red; 
  line-height: 30px;
}

// index.html
<input value="text1" id="text1" /> 
<input value="text2" id="text2" required/> 
<input value="text3" id="text3" /> 
<input value="text4" id="text4" required/> 
<input value="text5" id="text5" />

:optional

Псевдокласс с обратным действием для :required - позволяет стилизовать необязательные к заполнению поля. В дополнение к предыдущему примеру в файле style.css допишем следующее:

input:optional { 
  border-color: blue; 
  border-radius: 5px; 
  line-height: 50px;
}

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

:only-of-type

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

// index.html
<div class="container"> 
  <p>Я - текст №1</p> 
  <p>Я - текст №2</p>
  <b>Я - единственный жирный текст</b>
  <p>Я - текст №3</p>
  <p>Я - текст №4</p>
</div>

// style.css
p { 
  color: blue;
}
.container:only-of-type { 
  color: red;
}

В данном случае, тэг <b> является единственным потомком данного типа у .container, поэтому к нему применяется правило. Стоит заметить, что если внутри контейнера мы добавим, к примеру, один единственный тэг <span> - то его к нему так же применится данное правило.

:target

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

// style.css

.container:target {
 animation: 1s ease changeColor;
}
@keyframes changeColor {
 from {
   background: blue; 
 } 
 to { 
   background: red; 
 }
}

// index.html

<div class="container"> 
  <a href="#targetElem">
    <button> Кликни на меня </button> 
  </a> 
</div> 
<div class="container"></div> 
<div class="container"></div> 
<div class="container" id="targetElem"> 
  Посмотри, как я меняю цвет, когда ты нажал на кнопку 
</div> 
<div class="container"></div>

В данном кейсе, селектор ":target" срабатывает, когда в URL появляется хэш-якорь "#targetElem". Как только это происходит - запускается анимация смены цвета фона. Ты можешь поиграть со стилями, добавить более приятные цвета, плавный скролл и - вуаля - получается крутой визуальный эффект!
Так же, помимо визуальных эффектов, можно использовать свойство "display", для того, чтобы показывать элемент только тогда, когда пользователь явно к нему перешел, к примеру, в популярном на лендингах блоке "Вопрос-Ответ".

:is()

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

Применяется, в основном, для оптимизации.

К примеру, данный код:

.container0 p:hover {
  color: white;
}
.container1 p:hover {
  color: white;
}
.container2 p:hover {
  color: white;
}

эквивалентен следующему:

:is(.container0, .container1, .container2) p:hover { 
  color: white;
}

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

Надеюсь, ты возьмешь на вооружение данные возможности, подпишешься и будешь с интересом читать новые статьи от меня!

HTML-программистам

Для тех, кто думает, что выучив HTML вы станете крутым программистом - к сожалению, это не так. HTML - не язык программирования, однако, он играет ключевую роль во всей WEB-разработке.

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

Тэги

Единственная сущность HTML - это тэг. Тэг - отдельное правило, которое диктует браузеру как отобразить его содержимое. Тэг всегда описывается внутри треугольных скобок (< >) и большинство тегов необходимо закрывать (</>). Начнем сразу с примеров:

1) Для отображения текста, используется параграф - тэг <p>:

<p>
  Здесь будет текст
</p>

Данная конструкция как будто говорит браузеру: "Внутри меня находится обычный текст, отобрази его".

2) Для создания блока используется блочный тэг - <div>:

<div> 
  <p>
    Здесь текст
  </p>
</div>

Блоки служат для разделения сущностей на странице. Для разработчика блок - это строительный кирпичик, из которого он будет создавать всю страницу. Он может придумать абсолютно любой подход к организации этих блоков - этот процесс называется "вёрстка". Для наглядности, разделим сайт "teletype.in" на блоки:

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

3) Для отрисовки изображений используется тэг <img>:

<img src="/image.jpg">

И этот тэг немного отличается от тех, которые мы встречали ранее.
Во-первых - его не обязательно закрывать. Таких тэгов немного, но они есть, среди них - <img>, <p>, <br>, <link> и др. Во-вторых, у тэга появился атрибут "src", в который мы передаем путь к файлу изображения.

Список всех HTML-тэгов очень длинный, да и многие из них используются крайне редко. На практике, применяется, скорее всего, процентов 20 от всего многообразия тэгов, поэтому важно запомнить их, а по поводу остальных - достаточно будет просто знать про их существование.

Атрибуты

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

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

Пишем первую страничку

Итак, приведённой выше информации нам более чем достаточно, чтобы написать нашу первую HTML-страничку.

Создавай файл с названием "index.html", открывай свой любимый текстовый редактор (могу порекомендовать Visual Studio Code или Sublime, но хватит даже обычного "Блокнот"), мы начинаем )

Для начала, мы должны дать браузеру понять, что будем работать с HTML, поэтому, пишем следующих код:

<html>
  <head>
  
  </head>
  <body>

  </body>
</head>

Давай разберём, что же тут написано:
1) <html></html> - основной контейнер всей веб-страницы.
2) <head></head> - контейнер для тэгов, содержащих системную информацию. Она почти никогда не отображается напрямую на странице и служит для подключения различных вспомогательных модулей, таких как таблицы стилей или JS-скрипты.
3) <body></body> - контейнер для содержимого нашей страницы.

Теперь, нам надо как-нибудь назвать нашу страничку и добавить на неё блок с текстом. Для этого нам нужно сделать две вещи:

1) Внутри тэга <head></head>, пишем следующее:

<title>My first page</title>

2) Внутри тэга <body></body> пишем:

<div>
  <p>
  Hello, world!
  </p>
</div>

Код целиком:

<html>
  <head>
  <title>My first page</title>
  </head>
  <body>
  <div>
    <p>
      Hello, world!
    </p>
  </div>
  </body>
</head>

Вот и всё!
Теперь, если ты откроешь наш index.html с помощью браузера, ты увидишь, что страничка называется "My first page" и внутри, на белом фоне с тобой здоровается новый Frontend-разработчик !!!

Я надеюсь, эта статья была интересной, в следующих частях мы более подробно поговорим о подходах к вёрстке, о семантике тэгов и ещё о многих интересных мелочах.

Подписывайся и следи за выходом статей!