«Плохие программисты думают о коде. Хорошие программисты думают о структурах данных и их взаимосвязях», — Линус Торвальдс, создатель Linux.

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

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

Привет, Хабр! Решил затронуть тему наименования сущностей в Javascript. По работе довольно много взаимодействую со стажёрами и насмотрелся всякого. Вот и подумал, что было бы неплохо собрать в одной небольшой заметке принятые на сегодняшний день правила наименования сущностей в JavaScript сообществе. Возможно собрал не все, поэтому буду признателен если дополните меня в комментариях.

Именование сущностей

Именование очень важно в разработке ПО. Как мы знаем, код пишется в первую очередь для людей, которые будут его читать(для программистов). Неудачное именование может существенно повысить трудозатраты на разработку или поддержку проекта из-за того, что будет тратится лишнее время на чтение кода, т.к. при плохом нейминге затруднён процесс интерпретации «что есть что в коде».

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

• Верблюжья нотация (CamelCase): MyClass
• Змеиная нотация (snake_case): my_const
• Шашлычная нотация (kebab-case): my-data

При выборе кейса важно учитывать принятый на текущий момент стандарт. В js на сегодняшний день snake_case и kebab-case не приняты, но их можно встретить например на Python или Ruby.

Привет, Хабр!

Сегодня мы продолжим наши изыскания на тему функционального программирования в разрезе EcmaScript, на спецификации которого основан JavaScript. В предыдущих статьях цикла были рассмотрены следующие темы:

1. Чистые функции, лямбды, имутабельность
2. Композиция, каррирование, частичное применение

Привет, Хабр!

Сегодня мы продолжим наши изыскания на тему функционального программирования в разрезе EcmaScript, на спецификации которого основан JavaScript. В предыдущей статье мы разобрали основные понятия: чистые функции, лямбды, концепцию имутабельности. Сегодня поговорим о чуть более сложных техниках ФП: композиции, каррировании и чистых функциях. Статья написана в стиле «псевдо кодревью», т.е. мы будем решать практическую задачу, одновременно изучая концепции ФП и рефакторя код для приближения последнего к идеалам ФП.

Итак, начнём!

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

ПАЛИНДРО́М
Мужской родСПЕЦИАЛЬНОЕ
Слово или фраза, которые одинаково читаются слева направо и справа налево.
«П. «Я иду с мечем судия»»

Одна из возможных реализаций данной задачи могла бы выглядеть так:

function getPalindrom (str) {
  const regexp = /[\.,\/#!$%\^&\*;:{}=\-_`~()?\s]/g;
  str = str.replace(regexp, '').toLowerCase().split('').reverse().join('');
  //далее какой-то аякс запрос в словарь или к логике, которая генерирует фразы по переданным буквам

  return str;
}

function isPalindrom (str) {
  const regexp = /[\.,\/#!$%\^&\*;:{}=\-_`~()?\s]/g;
  str = str.replace(regexp, '').toLowerCase();
  return str === str.split('').reverse().join('');
}

Привет, Хабр!

Сегодня мы начнём говорить на очень важную тему — функциональное программирование. Значение ФП в современной веб-разработке трудно переоценить. Архитектура любого крупного современного проекта включает в себя пользовательские библиотеки функций и на собеседовании любого уровня в обязательном порядке будут вопросы по ФП.

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

Функциональное программирование(ФП) — способ организации кода через написание набора функций.

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

Отсюда следуют следующие определения:

Функциональный агрумент(Functional argument, фунарг) — аргумент, значением которого является функция.

Функция высшего порядка(ФВП, higher-order-funtion, hof) — функция, которая принимает функции в качестве аргументов.

Функции с функциональным значением(Function valued functions) — функция, которая возвращает функцию.

Все эти типы функций условно объединяют в функции первого класса, и, как следует из определения выше, в ES все функции являются объектами первого класса.

Привет, Хабр!

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

Сегодня мы продолжим разбирать ключевые концепции EcmaScript, поговорим о Лексическом окружении и Замыкании. Понимание концепции Лексического окружения очень важно для понимания замыкания, а замыкание это основа очень многих хороших техник и технологий в мире JS (который основан на спецификации EcmaScript).

Итак, начнём.

Лексическое окружение (LexicalEnvironment, ЛО, LE)

Официальная спецификация ES6 определяет этот термин как:

Lexical Environment — это тип спецификации, используемый для разрешения имён идентификаторов при поиске конкретных переменных и функций на основе лексической структуры вложенности кода ECMAScript. Лексическая окружение (Lexical Environment) состоит из записи среды и, возможно, нулевой ссылки на внешнюю Лексическую среду.

Разберёмся подробнее.

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

Технически ЛО представляет собой объект с двумя свойствами:

• запись окружения (именно тут хранятся все объявления)
• ссылка на ЛО порождающего контекста.

Привет, Хабр! Довольно известный преподаватель JavaScript Bill Sourour в своё время написал несколько статей по современным паттернам в JS. В рамках этой статьи мы постараемся обозреть идеи, которыми он поделился. Не то чтобы это были какие-то уникальные паттеры, но надеюсь статья найдёт своего читателя. Данная статья не «перевод» с точки зрения политики Хабра т.к. я описываю свои мысли, на которые меня навели статьи Била.

RORO

Абревиатура обозначает Receive an object, return an object — получить объект, вернуть объект. Привожу ссылку на оригинал статьи: ссылка

Билл писал, что пришёл к способу написанию функций при котором большинство из них принимают только один параметр — объект с аргументами функций. Возвращают они также объект результатов. На эту идею Билла вдохновила деструктуризация(одна из фич ES6).

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

Привет, Хабр!

В предыдущей статье мы рассматривали общую теории ООП в применении к EcmaScript и популярное заблуждение начинающих разработчиков относительно отличия ООП в JS и классических языках.

Сегодня мы поговорим о двух других не менее важных концепциях EcmaScript, а именно связи сущности с контекстом исполнения (this и есть эта самая связь) и связи сущности с порождающим контекстом(ScopeChain).

Итак, начнём!

this

На собеседованиях в ответ на вопрос: «Расскажите подробнее про this.». Начинающие разработчики, как правило, дают очень туманные ответы: "this – это объект «перед точкой», который использовался для вызова метода", "this — контекст, в котором был вызвана функция" и т.д.…

На самом деле, ситуация с этим центральным для EcmaScript языков понятием обстоит несколько сложнее. Разберёмся по порядку.

Допустим, у нас есть программа на языке JavaScript, в которой есть переменные объявленные глобально; глобальные функции; локальные функции(объявленные внутри других функций), функции, возвращаемые из функций.

Привет, Хабр!

До сего дня я занимался лишь переводами интересных, на мой взгляд, статей англоязычных авторов. И вот настала пора самому что-то написать. Для первой статьи я выбрал тему, которая, я уверен, будет полезна junior-разработчикам, стремящимся дорасти до «мидлов», т.к. в ней будет разобрана схожесть/отличие JavaScript от классических языков программирования (С++, С#, Java) в плане ООП. Итак, начнём!

Общие положения парадигмы

Если мы посмотрим определение JavaScript по Википедии, то увидим следующее понятие:

JavaScript (/ˈdʒɑːvɑːˌskrɪpt/; аббр. JS /ˈdʒeɪ.ɛs./) — мультипарадигменный язык программирования. Поддерживает объектно-ориентированный, императивный и функциональный стили. Является реализацией языка ECMAScript (стандарт ECMA-262).

Как следует из этого определения, JavaScript существует не сам по себе, а является реализацией некоей спецификации EcmaScript. Помимо него, эту спецификацию реализуют и другие языки.

Привет, Хабр! На днях наткнулся на одну очень интересную статью на португальском. К счастью, удалось найти её английскую версию. Предлагаю вашему вниманию перевод на русский. Другие мои переводы вы можете найти на мой странице на хабре.

Ссылка на оригинал: португальский, английский

Для тех кто не в теме. Styled-Components это библиотека очень популярная в среде React & Ract-native разработчиков. Она позволяет писать пользовательский CSS прямо в JS.

Во Vue мы знаем сколь удобно работать с однофайловыми компонентами(SFC), ведь всё необходимое компоненту собрано в одном месте. Паттерн SFC существенно повысил популярность Vue.

Крайние несколько месяцев мне довелось принять участие в разработке крупного проекта на React. В нём мы использовали Styled-Components, и это был очень интересный опыт.

Однако, в большинстве своих проектов я использую Vue, поэтому естественно, что мне захотелось объединить новый опыт со Styled-Components и преимущества Vue.js экосистемы. Именно тогда я обнаружил, что такое решение уже есть и оно поддерживается теми же создателями, что и аналогичная библиотека под React: vue-styled-components.

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

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

Напоминаю, что я стремлюсь к дословному переводу, а стараюсь передать суть. Поехали!

v-show на теге template

Директива v-show меняет свойство display у целевого элемента, но тег template не создаёт элемента в DOM, поэтому директиве не к чему прицепится. Используйте v-if вместо v-show на теге template или замените его на div.

От переводчика: если мне нужно использовать v-show, например, из соображений производительности, то я обычно вешаю его на БЭМ сущность Блок внутри тега template. Мне кажется это удобным.

Почему элемент в ref не определен?

Эта ситуация может возникнуть, если вы обращаетесь через ref к элементу, который ещё не отрендерен Vue. Например, на его предке висит директива v-if = false.

Эту ситуацию можно исправить, заменив v-if на v-show или дождаться пока элемент будет отрендерен(установив watcher на содержимое v-if).

Здравствуй, Хабр! Начать свою деятельность решил с перевода на русский статей, который мне самому принесли большую пользу. Надеюсь, вам пригодятся. Отмечу, что я старался переводить литературно, а не дословно.


Первым вашему вниманию представляю перевод статьи «Vue.js render functions and transitions» автора Hajime Yamasaki Vukelic.