🪄Магия на github! Просто нажмите "." находясь в любом репозитории на github!

🔗 https://twitter.com/github/status/1425505817827151872

#github #shortcut #news #tip

Если забыли магию 🪄 и не помните, что нажимать на github - нажмите "?"

#github #tips #shortcut

- Вы продоёте рыбов?
- Нет просто показываю.
- Красивое...

Хотите показывать рыбов 🐟, держите генератор - fishdraw!

fishdraw - генерирует svg картинки с нарисоваными рыбами. Генератор написан на javascript без зависимостей. Длинный, как сеть рыбака, файл, который нарисует и назовет тысячи картинок рыбов.

🔗 https://github.com/LingDong-/fishdraw
🔗 https://fishdraw.glitch.me/

#javascript #svg #meme #repo #github

Здравствуйте, друзья!

Сегодня мы начинаем тематические недели на Math.random().

Хедлайнером и повелителем канала на этой неделе будет Костя Пальчик - замечательный разработчик с большим опытом, любитель реактивного программирования, адепт NoCode решений, автор фреймворка ReсksJS, автор проекта ThinkRx.

Задавайте вопросы и пишите комментарии, а в конце недели ждите полноценный стрим с Костей с ответами на вопросы!

#thematicweek #nocode #reactive #recksjs

Всем привет, меня зовут Костя! 🙂

Андрей предложил мне "форс пуш" права на канал на эту неделю, чтобы я рассказал о какой-то теме!
Когда-то я писал на Angular(js) и тревожился что не учу React. Потом я попробовал React и начал мучится что не знаю Vue. Попробовал Vue — а на рынке есть ещё Ember, CycleJS, Svelte, Solid, и т.д.
Поэтому я выбрал тему фреймворков. Только я хочу рассказать не про их отличия, а чем они схожи.
Надеюсь, это поможет чьему-то fear of missing out.

Мы поговорим о том как фреймворки подходят к change detection, описывают UI (темплейты/JSX), компилируются и имплементируют SSR/SSG.
Посты будут короткие, но с полезными ссылками. Рассчитаны на junior / middle JS разработчиков.
Пишите в комментариях своё мнение, нравится/нет, задавайте вопросы.

И первый пост прямо сейчас:

Change detection & Reactivity

Начнём с того как фреймворк узнаёт что данные в нашей компоненте изменились и её нужно перерисовать.
Допустим, у нас есть славный компонент Counter, вы все его уже когда-то видели: [-] count [+]. Пользователь нажал кнопку [+] и мы увеличиваем некий count на +1. Это просто. А фреймворк в этот момент должен понять что нужно перерисовать компоненту с новым count. Давайте рассмотрим на примерах как фреймворки понимают что произошло изменение данных:


Dirty check
Довольно простой метод: мы сохраняем снэпшот состояния компоненты, и при любом взаимодействии с UI (как клик по кнопке) вызываем все хэнлеры, а затем проходимся по всем ключам состояния и проверяем не изменился ли стэйт по сравнению со снэпшотом. Если изменился — перерисовываем компоненту. Для нас это обычно выглядит как простой this.count += 1.
Таким методом пользуется Angular по умолчанию (angular ещё будет в reactive streams ниже)

Reactive atoms / Invalidation API
Некоторые фреймворки предоставляют API для точечного изменения состояния. Когда мы используем этот API (изменяем стэйт) — фреймворк понимает что произошло изменение и планирует перерисовку компоненты. Т.к. Javascript — довольно гибкий язык, такой API может скрываться под разным видом: count(count() + 1) в Knockout, setCount(getCount() + 1) в React и SolidJS.

Отдельно нужно описать Svelte и Vue, которые этот API прячут от девелоперов:
Svelte компилирует count += 1 в вызов API (мы о компиляторах ещё потом поговорим)
а Vue с их this.count += 1 в версии 2.x использовал Object.defineProperty c get/set парой, а с 3-й версии они перешли на Proxy для вызова своего API "под капотом".

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

Reactive streams
Мы, разработчики, иногда хотим управлять не дискретными срезами состояний, а потоком изменений. Так, например, мы сможем узнать как часто пользователь кликает [-] и создать особый обработчик для жёстких минусаторов. Для этого хорошо подходят реактивные потоки. Они предоставляют API нам для добавления логики и фреймворку для "слежения" за изменениями.

clicks$.next(1);
count$ = clicks$.scan((acc, curr) => acc + curr, 0);

Такой метод используют Аngular (в OnPush стратегии) и circlejs (ну, и мой экпериментальный recksjs, там вообще везде потоки).
Реактивные потоки относительно легко приделать к реактивным атомам / invalidation API, так что они часто встречаются в код базах с другими фреймворками.

.

Как видно, реализации немного разные, но цель одна и та же: пнуть фреймворк чтобы он перерисовал компоненту.
В следующий раз мы поговорим о том как в разных фреймворках мы задаём этот самый UI, который нужно перерисовывать.
Оставляйте свои комментарии и подключайтесь к math.random коммьюнити — мы любим говорить о технологиях.
До завтра!

___

Если у вас мало вкладок в браузере:
A Hands-on Introduction to Fine-Grained Reactivity — https://dev.to/ryansolid/a-hands-on-introduction-to-fine-grained-reactivity-3ndf
Reactivity in Depth — https://v3.vuejs.org/guide/reactivity.htm
Angular Change Detection - How Does It Really Work? — https://blog.angular-university.io/how-does-angular-2-change-detection-really-work/

#thematicweek #frameworksweek

Templates & JSX

Продолжаем снимать фрустрацию по поводу разнообразия фреймворков и сегодня коротко обсудим как мы описываем UI часть компонент.
Есть два доминирующих подхода, темплейты и JSX. Рассмотрим их по отдельности:

Темплейты
Темплейты — это DSL языки, созданные с учётом специфики и фич фреймворка, с прицелом на оптимизацию рендеринга и обновления DOM. JS в таких языках появляется вкраплениями, отдельными островками. Синтаксис темплейтов обычно похож на чистый HTML (но не обязательно), добавляя к нему специальные "глаголы" для вставки данных (например, {{ count }} для текстовых данных), для отображения списков (`v-for / ng-for / # each`), для создания условий (`ng-if / v-if / # if`) и прочие. Темплейты могут описываться строкой, специальной секцией (как во .vue файлах) или даже отдельным файлом (`.component.html` как в Angular).

<template>
  <p>Hello, {{ name }}</p>
</template>

<script>
let name = 'world';
</script>

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

Темплейты используются в Angular, Svelte, Vue


JSX
JSX же — это наоборот JavaScript с вкраплениями HTML-like языка. Это даёт нам максимальную гибкость в описании темплейтов за счёт JS манипуляций, но такая гибкость имеет свои минусы: её сложнее анализировать и оптимизировать. JSX хорошо стандартизирован.

function () {
  let name = 'world';
  return <p>Hello, { name }</p>
}

Для JSX нужен транспайлер, который превратит return <p>42</p> во что-то вроде return createElement('p', { children: 42 }). Функция createElement(…) создаст так называемый virtualDOM элемент — JS объект, описывающий реальный DOM элемент, что-то вроде { type: 'p', children: 42 }. При обновлении состояния компоненты она создаёт новый vDOM, фреймворк сравнит текущий vDOM с новым и сделает обновления реального DOM'а там, где состояние изменилось.

JSX используется в React, Solid, Vue

.

Вот я описал какие они разные, но на практике эти два подхода довольно таки схожи и граница между ними чуть размыта. Вы заметили что я упомянул Vue дважды, и в темплейтах и в JSX? Vue разрешает девелоперам использовать оба синтаксиса: под капотом Vue использует vDOM, но предлагает пользователям писать компоненты в основном с помощью темплейтов, так как компилятор может их хорошо оптимизировать. А компилятор Solid распарсит и оптимизирует JSX почти как темплейты. А Astro использует JSX-like синтаксис, но это на самом деле темплейты.

Да и в целом, на каждый [].map есть свой *-for, а <p>{{ name }}</p> не сильно то отличается от return <p>{ name }</p>.

Оставляйте свои комментарии и подключайтесь к math.random коммьюнити — мы любим говорить о технологиях.
Надеюсь, сегодня я вас больше успокоил чем запутал 🙂
До завтра, завтра поговорим о компиляторах!

#thematicweek #frameworksweek

Всем привет!

Хочу пригласить вас на наш с Андреем Кучеренко math.random стрим!
Поговорим о фреймворках, nocode и не только 🙂
Стрим будет уже завтра, в 18:00 по Киеву, приходите!

Ссылка без регистрации и смс: https://www.youtube.com/watch?v=v7qVVtjzR1Y

🙌

Компиляторы — это не совсем Developer eXperience о котором мы говорили в прошлых выпусках. Но они напрямую влияют на DX и входят в набор инструментов, обязательных для современного фреймворка. Так что давайте сегодня обсудим зачем они нужны и что они делают:

Компиляторы компилируют (👨‍✈️). Фреймворк — это уже не просто JS файл с рантайм движком, это ещё и набор инструментов для разработки и сборки проекта. Всем фреймворкам с DSL темплейтами понадобится их в какой-то момент распарсить, а для некоторых компиляция — это вообще основной шаг создания рантайма.

Angular был одним из первых, получивших Ahead of Time компилятор (на практике "заблаговременно" значит что мы компилируем тогда, когда нужно: при сборке проекта). С Angular и начнём:

Angular при компиляции распарсит темплейт и создаст для него JS код, который отрендерит начальное состояние и будет следить за обновлениями. Помните мы говорили про Change detection и reactivity? Так вот AoT компилятор выделит для dirty checking'а только те свойства состояния, которые используются в темплейте и не будет тратить время на неиспользуемые свойства.
Angular Ivy (с примерами аутпута компиляции темплейта): https://blog.ninja-squad.com/2019/05/07/what-is-angular-ivy/

Vue соберёт свои .vue файлы и переведёт темплейты в vDOM. А ещё и оптимизирует обновление vDOM с помощью специальных инструкций, чтобы при изменении состояния сравнивать не весь vDOM, а только подветви дерева.
Vue template Repl: https://v3.vuejs.org/guide/render-function.html#template-compilation

Svelte вообще не сможет без компилятора: все () => { a = b + c; } при сборке превратятся во что-то вроде () => { invalidate('a', b + c) } чтобы сигнализировать об изменении состояния. Svelte даже добавляет специальный синтаксис $: a = b + c; для computed значений. Так что код, который Вы пишете, — это не тот код, который будет работать в браузере.
Svelte Repl: https://svelte.dev/repl/hello-world?version=3.42.1

SolidJS распарсит JSX и превратит его в инструкции, которые напрямую манипулируют DOM. Solid может напрямую привязывать состояние к DOM, т.к. использует reactive atoms и, как и Svelte, парсит и модифицирует наш JS код.
Solid Repl: https://playground.solidjs.com/

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

.

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

Вот, это что касается обязательной части компиляторов. Для краткости я опустил сборку JS и CSS — там более-менее одинаковые подходы у всех фреймворков.

Похоже, за компиляторами ближайшее будущее, что думаете?
Оставляйте свои комментарии и подключайтесь к math.random коммьюнити — мы любим говорить о технологиях.
Завтра поговорим об SSG и SSR. До завтра!

#thematicweek #frameworksweek

#humor #haha

Итак, мы написали наше супер-пупер-приложение, скомпилировали и хотим показать миру. А как?
Классический Single Page App (SPA), который генерирует наш фреймворк, — это один index.html с .css и .js .
Т.е. когда пользователь откроет адрес …/about-us — мы ему отдадим наш index.html, который загрузит .js, который уже отрендерит about-us страничку. Ещё хуже обстоят дела когда нам нужно отрисовать, например, список постов, которые нужно взять на сервере: index.html → main.js → xhr:/api/posts → Render . Это особенно нехорошо, если нам нужно чтобы сайт попадал в google. А юзер, посмотря секунду на наш fancy loading indicator, может устать и уйти на другой сайт.

Как решить эти проблемы? Конечно сделать фреймворки фреймворков (ну, или "компиляторы компиляторов")!
В зависимости от типа приложения, есть два основных подхода: SSR и SSG. Рассмотрим их по отдельности:

SSR (server side rendering) — означает что в ответ на запрос определённой страницы, мы на сервере отрисуем и отдадим полностью готовый .html, который браузер сразу же готов отрисовать. Обычно, после того как у клиента отрисовалась страница, мы подгружаем наше .js, оживляем отрисованный html (hydration) и переводим сайт в режим CSR'а (client side rendering) — так для навигации по страницам сайта клиенту уже не нужно будет ждать ответ сервера. SSR предполагает наличие рантайм движка на сервере (вроде nodejs) и может генерировать страницы с контекстом пользователя (например, ваш wish list на e-commerce сайте). Некоторые фреймворки (по крайней мере, Next и Nuxt) разрешают написать функцию, которая получит данные для нашей компоненты, но будет выполнена только на сервере и вообще не будет загружаться на клиента. Например, получит список товаров из нашего внутреннего API — клиент эту функцию загружать не будет, а просто получит список товаров.

SSG (server side generation) — похоже на SSR, только мы заранее генерируем .html файлы на сервере и просто отдаём их как статику. Для этого мы должны заранее знать какие страницы пользователь может запросить. Например, мы можем сгенерировать все страницы со статьями для нашего блога. SSG для работы должен знать список URL, которые ему нужно отрендерить. Некоторые фреймворки предоставляют краулер, который запустит наш сайт и сам соберёт все доступные URL, для которых нужно сгенерировать .html. SSG хорошо работает с CDN, которые могут сильно сократить время начальной загрузки.

Такие фреймворки размывают границу между front-end и back-end, расширяют границы где наши приложения могут и должны запускаться.
В целом, SSR и SSG — это набор инструментов и API над нашими "клиентскими" JS фреймворками.
Оставляйте свои комментарии и подключайтесь к math.random коммьюнити — мы любим говорить о технологиях.

———
Для почитать: jamstack.org
Для поковыряться:
React: Next, Gatsby, Blitz, React Server Components
Vue: Nuxt, Gridsome
Svelte: SvelteKit
Angular: Scully
Ещё: Astro — он для всех.

#thematicweek #frameworksweek

Здравствуйте, друзья! Через неделю состоится конференция OdessaJS!

Специально для наших подписчиков предоставляется возможность выиграть 50% скидки на входной билет, для этого нужно оставить комментарий под этим постом с названием доклада, который вы хотели-бы послушать. Список докладов на сайте - https://odessajs.org/

Победитель будет объявлен в понедельник!

#odessajs #conference #discount

Привет, math.random!

Сегодня заканчивается #frameworksweek и я передаю управление обратно Андрею Кучеренко 🖐
Надеюсь было интересно! Пишите что вы думаете об этой неделе и о чём вы бы хотели узнать в других #thematicweek в комментариях!

Напоследок скажу: не переживайте что ещё не попробовали какой-то фреймворк, если у вас есть опыт с одним — вам будет легко разобраться в другом. А если у вас выпало пару минут свободного времени — для большинства фреймворков есть онлайн плейграунды (даже для SSR), с ними можно быстро ознакомиться.

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

Всем хороших выходных!

🙌

В субботу на VinnytsiaJS поговорили про обрасти применения JavaScript.

Обратите внимание на закрепленный пост, есть шанс попасть на OdessaJS

Презентация по ссылке:

🔗 https://slides.com/andreykucherenko/deck-39f096

#slides #conference #vinnytsajs

30 seconds of code – сборник код-снипетов
#list #code_pattern

В начале лета я делился ссылкой на 1loc.dev. В комментариях была ссылка на аналогичный ресурс – 30 seconds of code. Примеры кода чуть длинней, но суть та же самая. Есть раздел отдельно по #nodejs сниппетам.