Привет! Призываю всех провести небольшую перекличку!

Напишите в комментариях ваш опыт в JS и ваш фреймворк

——
Upd.: если еще только учите - то напишите как долго)

Дизайн тоже важная вещь :)

Вы просили рассказать про актуальные проблемы в разработке, вот ловите

А зачем разговаривать?

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

- Как работает этот старый код который ты написал?
- Ну тут все просто ты же сам видишь, вот executeSomeShit() запускает это, а там колбек, а сейчас у меня обед, ссори

Кому-то это покажется диким или притянутым, но с таким бывает тоже приходится сталкиваться, главное тут уметь себя поставить на место того с кем вы общаетесь

К счастью в нашем коллективе таких ситуаций не встречается, хотя в жизни с таким я сталкивался. А у вас?

👆если вы прочитали пост выше и вам показалось что это незначительно или неважно, то:

1) это уже микропризнак того что над эти стоит работать
2) на собесах на это очень смотрят и это влияет на добрые 50% решения о том взять вас или нет (это не значит что надо быть человеком-цветочком, но если в вам бушуют порывы, то их лучше уметь гасить)

Я знаю что здесь много ребят только начинает. А что значит для вас «разработка»?

Используйте alias-ы!

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

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

👆alias-ы могут быть не только до файла, но и до какого-то конкретного каталога, поэтому напимер если у вас море импортов типо таких

import a from ‘../../../../long/way/utils/a’

можно получить такой результат

import a from ‘@utils/a’

или

import { a } from ‘@utils’

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

#для_самых_начинающих

Приветствую, сегодня мы поговорим о таком базовом, но не менее важном концепте в JS как - Области видимости.

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

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

Всего существует 3 области видимости: Глобальная, Блочная и Функциональная.

Глобальная область видимости — это самая внешняя коробка из всех.

const a = 42;
console.log(a); // 42

Блочная область видимости ограничена программным блоком, обозначенным при помощи { и }.


const a = 42;
console.log(a); // 42

if (true) {
const b = 43
console.log(a)
// 42
console.log(b)
// 43
}

console.log(b)
// ReferenceError: Can't find variable: b

Функциональная область видимости — это область видимости в пределах тела функции. Можно сказать, что она ограничена { и } функции.

const a = 42;
console.log(a); // 42

function scoped() {
const b = 43
}

console.log(a)
// 42
console.log(b)
// Reference error

Более подробно ознакомится с областью видимости Вы сможете по ссылке https://habr.com/ru/post/517338/

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

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

function outer() {
let a = 42

function inner() {
console.log(a)
}

inner()
}

outer()
// 42

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

Заметим, что у функции inner никаких локальных переменных нет — она работает только с локальной переменной функции outer.

Такой особенный доступ к локальным переменным родительской функции часто называют лексической областью видимости.

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

Но что, если мы вернём из функции outer функцию inner?

function outer() {
let a = 42

function inner() {
console.log(a)
}

return inner
}

Теперь мы можем не просто вызывать функцию outer, но и присвоить результат вызова какой-то переменной:

const accessToInner = outer()

accessToInner()
// 42

Теперь в переменной accessToInner находится функция inner, у которой всё ещё есть доступ к локальной переменной a функции outer!

То есть мы смогли «обойти» область видимости? Не совсем.

Мы действительно получили доступ к переменной a через функцию inner, но только в том виде и с такими ограничениями, которые описаны при создании функции inner.

У нас всё ещё нет прямого доступа к переменной a. Мы, например, не можем её поменять — только вывести в консоль.

Грубо говоря, мы создали функцию, которая даёт нам читать переменные, но не изменять их. Это полезно, если мы хотим дать ограниченный доступ к внутренностям модуля.

Более подробную статью о замыканиях, Вы можете прочитать по ссылке

Если у вас появились вопросы, ждем их в комментариях!

Как вы станете высокооплачиваемым разработчиком с хреновым английским?

Что такое dependency inversion, shard allocation, wysiwyg, kiss principle? А весь топовый контент сейчас онли ин инглиш.

Срочно подпишись на РуинглишDev если не знаешь этих базовых терминов. Автор - Senior Sofrware Developer даст вам информацию без воды.

Начать understand инглиш за 5 минут в день: @RuEnglish_Devs

React Reconciliation (Согласование) - насколько хорошо вы знаете как оно работает ?

Во время работы со списками в приложениях, написанных на React Js, вы сталкивались с тем, как консоль браузера настойчиво рекомендует вам присвоить каждому элементу списка уникальный проп key, мотивируя это улучшением производительности?

В сегодняшнем видео, которое я предлагаю вашему вниманию, подробно раскрывается тема работы алгоритма согласования и каким образом достигается эта самая производительность

Поверхностное и глубокое клонирование объектов в JS

Если у нас стоит задача скопировать простой объект и массив, то проблем не возникает, например:

 simpleObj = {
  fieldOne: 1,
  fieldTwo: 2,
  fieldThree: 3,
};

console.log(simpleObj);
// простой объект  - {fieldOne: 1, fieldTwo: 2, fieldThree: 3,}

const simpleObjectCopy = {... simpleObj}; // используем spread для копирования простого объекта

console.log(simpleObjectCopy);
//клонированный простой объект -  {fieldOne: 1, fieldTwo: 2, fieldThree: 3,}

simpleObjectCopy.fieldOne = 2; //изменим значение первого поля в копированном объекте, чтоб убедится что эти два объекта не связаны

console.log(simpleObj); // {fieldOne: 1, fieldTwo: 2, fieldThree: 3,}
console.log(simpleObjectCopy); // {fieldOne: 2, fieldTwo: 2, fieldThree: 3,}

Но что если у нас более сложный объект или массив (объект внутри которого другой объект или массив с объектами как в примере)

const foodInCart = [
{ product: 'Агава', quantity: 3},
{ product: 'Апельсин', quantity: 1 },
{ product: 'Дыня', quantity: 1 },
]

const clonedCart = [...foodInCart]

console.log(clonedCart);
// [
// { product: 'Агава', quantity: 3 },
// { product: 'Апельсин', quantity: 1 },
// { product: 'Дыня', quantity: 1 },
// ]



 = 5 // изменяем поле "количество" в объекте под индексом 1 

console.log(clonedCart)
// [
//    { product: 'Агава', quantity: 3 },
//    { product: 'Апельсин', quantity: 5 },
//    { product: 'Дыня', quantity: 1 },
// ]

console.log(foodInCart)
// [
//    { product: 'Агава', quantity: 3 },
//    { product: 'Апельсин', quantity: 5 },
//    { product: 'Дыня', quantity: 1 },
// ]

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

Таким образом, "разные" массивы ссылаются на одни и те же объекты в памяти:

 === clonedCart[1]); //true

JavaScript не имеет отдельных функций для глубокого копирования массивов или объектов. Существуют различные способы сделать глубокое копирование.

Можно написать функцию глубокого копирования вручную. Скорее всего ваша функция будет рекурсивной, и она будет работать только для конкретных данных — написать универсальную функцию не так-то просто.

Так же можно сериализировать копируемый объект в JSON и распарсить его :

const deepClone = JSON.parse(JSON.stringify(foodInCart))

console.log(foodInCart[1] === deepClone[1]) // false

Но данный метод не идеальный, потому что копируемые данные должны быть сериализуемыми. Если у объекта существуют методы или массив содержит функции, то копирование не сработает.

Еще один способ это воспользоваться популярной библиотекой утилит lodash

👆а вообще за копирование объектов через сериализацию в JSON и обратно могут хорошо бить по-жопе осудить более опытные коллеги