Хороший обзор погружения в solid - борьба со сборщиком и реактивностью. У меня всплывают воспоминания об использовании Vue когда еще весь тулинг необходимо было настраивать руками 🙃

Я уже написал на solid.js аж целых два маленьких приложения.
Поделюсь опытом в сравнении с реактом, раз уж они под реакт мимикрируют.

День первый.
Я полистал документацию, посмотрел ролики, впечатлился качеством материалов.
Нашел необходимый плагин для vite, шаблон конфгиа по ts, запилил hello world, все круто!
Надо было сразу выбросить реакт и взять солид, чего ждал - не понятно. Счас хуяк хуяк и в продакшен супер быстрый апп, с маленьким бандлом, бешеным перфом, гранулярными апдейтами, ууухххх

День второй.
Плагин оказался со странностями. Почему он перетирает часть конфига моего vite, и принудительно заменет happydom на jsdom???

pnpm орет на меня что у меня vite 4, а плагин только до 3 ей версии. К тому же после изменений в стилях у меня появляется копия всего приложения на странице. Одна по другой. +1 копия приложения после каждого обновления.
Потратил время на изучение проблемы
- нашел ишьюс в котором проблемы с happydom известна пол года. И даже вроде мр есть. Но всем плеват. Решается откатом на старую версию. Наконец замерижили фикс.
- по поводу дублирования приложения - оказывается надо плагину hrm комментариями подсказать что index.tsx где я маунчу апп в дом дерево перевызывать не надо /* @refresh skip */
в целом очень странно видеть что фреймворк так сильно завязаный на сбороку - так слабо поддерживает единственный официальнаый плагин для vite который счас мейнстрим сборщик.

День третий.
Два часа пытался понять почему у меня не ренедериться вьюшка.
Если на реакте заработает почти любой говнокод, ужасно, с кучей лишних перерендоров - но заработает, то в solid - малейшая оплошность приводит к тому что рендера не будет.
Без ошибок в рантайме или иде. Я просто смотрю в дэбагере как мой ресурс скачался, обновитлся сигнал, но ничего не происходит - в вьюшке все так же висит ...loading
дэбагер не помогает - надо слишком много знать о внутрянке солида чтоб в этом был толк.
В итоге оказалось что дело в тернарке.
Тернарки в jsx использовать можно, но только один раз. Как с ядовитыми грибами, ага.
Только специальный компонент <Show>, запомните.
про Optional chaining тоже лучше забыть. Один раз ваше выражение foo?.bar() вернет undefined вместо сигнала и больше вы ререндеров не увидите здесь.

День четвертый.
ClassList как будто бы должен был заменить clsx но на самом деле это пятая нога. Не заменяет, а только лишная апи мешается и создает избыточность.
Typescript, и так бывает больно писать, а с solid это будет еще веселее.
Подводных камней столько что есть отдельный раздел документации который я почему-то не замeтил когда знакомился с солидом первый раз

Вобщем итого -
если ваше приложение на солиде работает - оно будет работать быстро. Это в реакте можно открыть код и сказать "божеш ты, как это го-но работает то, кто это, какой return первой строкой, кто правила хуков будет соблюдать - и тп"
реакт приложение как то накоряканое будет работать хоть и плохо.
В солиде готовтесь превозмогать, без ошибок и подсказок, девтулзов и т.п. выезжать на опыте, внимательном прочтении доки, знать где тонко и писать jsx с минимум логики.
Я вам вобще не рекомендую по началу в солидовском jsx писать выражения js как бы абсурдно это не звучало.
Но, если вам нужен перф, у вас все обновляется например по сокетам и мигает как новгодняя елка каждая панелкьа отдельно - да, это для солида.
Касательно похожести на реакт - ваш код смогут читать (но не писать) реактеры, на этом все

Как появились веб-пуши Apple в Тинькофф

Возможность использовать пуши в браузерах появилась довольно давно, но в safari с этим были сложности, что останавливало внедрение этой технологии. Но, начиная с ios 16.4 safari поддерживает веб-пуши. Статья рассказывает, как в компании Тинькофф начали применять веб-пуши, с какими проблемами столкнулись и как их решали. Также вкратце рассказывается про особенности работы пушей: необходимость шлюза, 2 варианта использования, проблемы с отписками и переподписками и доставляемостью.

Хорошая ознакомительная статья про возможность веб-платформы и её практическое применение большой компанией.

https://habr.com/ru/companies/tinkoff/articles/776658/

#development #javascript #habr #webPush #pwa

Дайджест за 2023-12-11 - 2023-12-15

Web Components Eliminate JavaScript Framework Lock-in
Очередная статья про то, что веб-компоненты позволят нам создавать сайты, используя разные технологии. Сами же веб-компоненты могут использоваться как клей между этими технологиями.

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

Track Frontend JavaScript exceptions with Playwright fixtures
Достаточно интересная статья про использование API playwright для расширения функционала тестов на примере слежения за неперехваченными глобальными ошибками.

В чем проблема: браузерные автотесты весьма полезны т.к. позволяют быть уверенными, что система работает end-to-end или близка к этому. Но тесты проверяют только конкретный функционал. А бывает так, что конкретный функционал работает, но что-то другое падает и в консоли видна ошибка. При ручном тестировании это заметно, но автотесты это не отлавливают. Но автотесты можно научить проверять глобальные ошибки. Именно этим автор и занимается в статье с помощью Playwright

console ninja: console log output right next to your code
Интересный тулинг по типу wallaby и quokka, который связывает код в IDE и консоль в приложении. Т.е. например, вы поставили console.log(myVariable) и вывод консоли отобразится у вас прямо в IDE. Кроме этого инструмент умеет связывать ошибки с кодом, создавать лог-поинты (это как брекпоинты, только вместо остановки мы просим вывести значение переменной в лог) и еще всякое.

Есть платная и бесплатная версии. Посмотрите, возможно вам понравится.

⭐Keep that cursor still!
Веб-разработчики делятся на 2 типа - познавшие боль от работы с курсором в input'ах и тех, кому это только предстоит.

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

Как появились веб-пуши Apple в Тинькофф
Возможность использовать пуши в браузерах появилась довольно давно, но в safari с этим были сложности, что останавливало внедрение этой технологии. Но, начиная с ios 16.4 safari поддерживает веб-пуши. Статья рассказывает, как в компании Тинькофф начали применять веб-пуши, с какими проблемами столкнулись и как их решали. Также вкратце рассказывается про особенности работы пушей: необходимость шлюза, 2 варианта использования, проблемы с отписками и переподписками и доставляемостью.

Хорошая ознакомительная статья про возможность веб-платформы и её практическое применение большой компанией.

——————————————

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

Доклады секции Frontend на Codefest13

В открытом доступе появились записи доклады с секции Frontend на Codefest13. Лично я посмотрел не все доклады с этой секции прошедшего Codefest, но горячо рекомендую, конечно же, свой доклад про использование ChatGPT и доклад Никиты Сидорова про прогрессивный рендеринг (или что-то в этом роде) в Яндекс.Маркете.


https://www.youtube.com/playlist?list=PL8761XQAJnrZtx3JvX50duslRe_mU7_Zl

#development #youtube #codefest

UX Core - Cognitive biases in product management and HR

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

Рекомендую к изучению или хотя бы к беглому просмотру

https://keepsimple.io/uxcore

#managment #cognitiveBiases #product #recommended

Oxlint General Availability | The JavaScript Oxidation Compiler

Публичный релиз нового линтера - oxlint. Если коротко, он в разы быстрее, чем eslint. И в разы же менее функциональный.

Основные поинты:
- в 10-100 раз быстрее eslint. В посте приведен пример shopify, которые запускали eslint в 40 воркеров в CI и это занимало 75 минут (я так понял суммарно). Теперь же проверка занимает 10 секунд, а ошибки намного понятнее. Кейс максимально странный, как будто в shopify просто решили забить на инженерные практики - сначала завалили проблему железом, а потом перешли на более быстрый, но менее функциональный, новый тул. Повезло, что линтер - это не критичный инструмент и миграция не может сломать прод
- Вывод ошибок намного лучше
- Системы плагинов нет, но команда переносит лучшие правила в oxlint
- По-умолчанию включены только важные правила, которые влияют на корректность работы кода. Всякое про стиль, производительность, субъективность - отключено по-умолчанию

https://oxc-project.github.io/blog/2023-12-12-announcing-oxlint.html

#development #javascript #linter #oxlint

The await event horizon in JavaScript

Небольшая статья про родовую травму JS - неотменяемые Promise'ы. Автор сравнивает ожидание промиса через await someCall() с горизонтом событий черной дыры. Это очень интригующее, и немного странное, сравнение. Все что попадает за горизонт событий черной дыры - это граница, за которой ничего не видно т.к. даже свет не может вырваться оттуда. Мы можем только ждать, вырвется что-то оттуда или нет. Также и с await - однажды поставив его в коде, мы не можем быть уверены, что управление когда-нибудь вернется.

Автор объясняет, что это давняя проблема (ей около 10 лет) и комитет стандартизации решил её не решать. Эта проблема может приводить к утечкам памяти. Как возможное решение автор описывает использование abortController (или других аналогичных способов) во всех асинхронных функциях. Но это не общепринятый паттерн и мы не можем быть уверены, что весь код приложения (в том числе код node_modules) будет использовать этот паттерн.

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

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

https://frontside.com/blog/2023-12-11-await-event-horizon/

#development #javascript #async/await #Promise #generators

Web Performance Calendar » Benchmarking, Profiling, and Optimizing JavaScript libraries

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

Автор замерил скорость работы своей либы и в профайлере нашел самую медленную часть - plural (функция которая склоняет слова - 1 книга, 2 книги, 5 книг). Замена реализации на Intl.PluralRules дала ускорение в 3 раза

Дальше автор столкнулся с проблемой замеров скорости работы функции. Оказывается, профайлер в node.js - сэмплирующий. Т.е. каждые несколько милисекунд профайлер собирает информацию, какие функции сейчас работают. Если функция работала в sample1 и в sample2 - то считается, что она работала все время между sample1 и sample2. Как следствие, если функция выполнилась между sample1 и sample2, то её вообще не будет в профайлере. Автор просто не видел некоторых функций в профайлере.

Интересно, что профайлер в Google Chrome может собрать более детальную информацию. Но новой информации о том, что стоит ускорять это не дало.

Однако, автор знал о паттерне "плоское AST". Казалось бы, причем тут AST и локализация текста? Я просто не приводил пример использования кода приложения. Вот он:

const message = `You have {numBooks, number} {numBooks, plural, one {book} other {books}}.`;

Чтобы разобрать такую конструкцию, необходимо построить AST. А если мы строим AST - то оно иерархическое. Но есть концепция плоского AST, которая позволяет вместо рекурсивных вызовов обходить его в цикле.

Автор делает правку работу парсера и компилятора и ускоряется еще на 20% (если я правильно понял).

Статья немного странная, но достаточно интересная.

https://calendar.perfplanet.com/2023/benchmarking-profiling-and-optimizing-javascript-libraries/

#development #javascript #performance

Дайджест за 2023-12-18 - 2023-12-22

Доклады секции Frontend на Codefest13
В открытом доступе появились записи доклады с секции Frontend на Codefest13. Лично я посмотрел не все доклады с этой секции прошедшего Codefest, но горячо рекомендую, конечно же, свой доклад про использование ChatGPT и доклад Никиты Сидорова про прогрессивный рендеринг (или что-то в этом роде) в Яндекс.Маркете.



⭐UX Core - Cognitive biases in product management and HR
Каталог из 210 когнитивных искажений, которые сгруппированы по типам и имеют хорошее описания действия этих искажений в разработке продукта и HR-вопросах, а также как с ними работать. Доступно на русском и английском языке.

Рекомендую к изучению или хотя бы к беглому просмотру

Oxlint General Availability | The JavaScript Oxidation Compiler
Публичный релиз нового линтера - oxlint. Если коротко, он в разы быстрее, чем eslint. И в разы же менее функциональный.


The await event horizon in JavaScript
Небольшая статья про родовую травму JS - неотменяемые Promise'ы. Автор сравнивает ожидание промиса через await someCall() с горизонтом событий черной дыры. Это очень интригующее, и немного странное, сравнение. Все что попадает за горизонт событий черной дыры - это граница, за которой ничего не видно т.к. даже свет не может вырваться оттуда. Мы можем только ждать, вырвется что-то оттуда или нет. Также и с await - однажды поставив его в коде, мы не можем быть уверены, что управление когда-нибудь вернется.

Автор объясняет, что это давняя проблема (ей около 10 лет) и комитет стандартизации решил её не решать. Эта проблема может приводить к утечкам памяти. Как возможное решение автор описывает использование abortController (или других аналогичных способов) во всех асинхронных функциях. Но это не общепринятый паттерн и мы не можем быть уверены, что весь код приложения (в том числе код node_modules) будет использовать этот паттерн.

Web Performance Calendar » Benchmarking, Profiling, and Optimizing JavaScript libraries
Статья про оптимизацию перформанса библиотек. Автор разрабатывает приложение, в котором необходимо локализовывать контент на много разных языков. Но используемая библиотека была слишком громоздкой, поэтому он решил сделать свою (на основе существующего кода, как я понял) и заодно сделать её очень быстрой

Автор замерил скорость работы своей либы и в профайлере нашел самую медленную часть - plural (функция которая склоняет слова - 1 книга, 2 книги, 5 книг). Замена реализации на Intl.PluralRules дала ускорение в 3 раза

——————————————

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

You don't need JavaScript for that

Небольшая статья про вещи, которые в UI можно реализовать вообще без JS. Автор показывает по шагам, по-немногу усложняя примеры, как с помощью базовых HTML и CSS можно создавать достаточно удобные базовые элементы

Автор разбирает реализацию следующих элементов:
- Кастомизируемый чекбокс
- Инпут с автосаджестом
- Color picker
- Accordion
- Модалка


https://www.htmhell.dev/adventcalendar/2023/2/

#development #javascript #html #css #nativeDom

Storybook for React Server Components

Storybook добавили экспериментальную поддержку React Server Components в Storybook 8.0 alpha. Так как серверные компоненты могут полагаться на то, что доступен весь API node.js, то у команды Storybook было 2 стула:
- поменять архитектуру Storybook, чтобы там появилась серверная часть
- Сделать все на стороне клиента, но придумать как обойти ограничения

Естественно, выбрали сесть на второй. Реализация сделана на основе Next.js версии React. И если с рендером все более менее понятно, то непонятно что делать с зависимостями. Например, компонент ходит в БД. Для этого Storybook предлагает выделять такие операции в отдельные модули, которые затем в истории можно замокировать черезstorybook-addom-module-mock или через другие решения

export const Success {
  args: { id: 1 },
  parameters: {
    moduleMock: {
      mock: () => {
        const mock = createMock(db, 'findById');
        mock.mockReturnValue(Promise.resolve({
          name: 'Beyonce',
          img: 'https://blackhistorywall.files.wordpress.com/2010/02/picture-device-independent-bitmap-119.jpg',
          tel: '+123 456 789',
          email: '[email protected]'
        }))
        return [mock];
      },
    },
  },
}

https://storybook.js.org/blog/storybook-react-server-components/

#development #javascript #storybook #reactServerComponents

React Tricks: Fast, Fit and Fun

Транскрипция доклада с React-митапа в Копенгагене про уроки и хаки, полученные во время разработки Wouter - библиотека микро-роутер

Автор рассказывает про всякие интересные особенности React, которые позволяют делать компоненты с меньшим количеством ререндеров и меньшим размером при сборке (автор типа частично гонится за оптимизацией размера в gzip). Это все приправлено наглядными демками.

Если коротко, то список уроков и хаков такой:
- cloneElement позволяет добавлять пропсы children-компонентам без добавления лишних оберток. Это также может быть крайне полезно для навешивания ref
- Инициализатор состояния в useState выполняется перед любыми другими хуками и выполняется гарантированно 1 раз. Это также может быть полезно для заворачивания тяжелых вычислений
- Стабильные ссылки на функции с помощью useEvent. useEvent пока еще обсуждается в React, но можно взять реализацию из npm
- useSyncExternalStore, в отличии от комбинации useEffect и useState, позволяет легко и удобно подписываться на состояние и при этом избежать проблемы с неодновременным обновлением UI.

https://molefrog.com/notes/react-tricks

#development #javascript #react #performance

Неплохой канал, где тоже постят ссылки на всякое полезное, но не с таким подробным описанием как у меня (хотя и у меня далеко не всегда подробное описание)

https://www.tg-me.com/coderoll

Канал уходит на новогодние каникулы. Новых ссылок не будет до 9 января.

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

Всех с наступающим новым годом🌲🎅!

Bun, Javascript, and TCO

Статья про tail call optimization - хвостовую оптимизацию вызовов. Когда мы вызываем функцию Б из функции А, то движок формирует call stack - стек вызовов. Это позволяет движку или процессору при выходе из функции Б в функцию А быстро восстанавливать состояние окружения. Но этот стек не бесконечен и, вроде, зависит от окружения (я знаю про ограничение в 65 536 в каких-то движках). Достаточно сложно упереться в лимит в обычном коде, но это реально сделать при реализации рекурсивных функций. Tail Call Optimization позволяет избежать этой проблемы, если движок видит, что функция вызывает саму себя.

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

Мы можем реализовать эту функцию через цикл, и она будет прекрасно работать

function count(amount) {  
  let nums = [];  
  for (let i = 1; i <= amount; i++) 
   nums.push(i);  
  return nums; 
}

Но также мы можем реализовать её через рекурсивный вызов

"use strict"
function count(amount, cur = []) {
  return cur.length >= amount ? cur : count(amount, [...cur, cur.length + 1]);
}

В этом случае, если в движке не реализован Tail Call Optimization, то есть шанс переполнить стек вызовов. Собственно именно это произойдет в Google Chrome, если выполнить count с более менее большим аргументом. В safari же код корректно отработает т.к. в движке safari оптимизация реализована.

А т.к. bun работает на движке JavascriptCore, который в safari, то и в нем есть Tail Call Optimization.

Однако, если мы сравним скорость работы реализации через цикл и рекурсию, то мы увидим огромную разницу (в посте говорится о 0.1 секунды против 7 секунд). Дело в том, что при работе с рекурсией нужно также задумываться и о работе с памятью. В данном случае, рекурсивная функция каждую итерацию собирает новый массив данных. Если изменить алгоритм функции на мутирующий, то она будет выполнятся также быстро как и вариант с циклом

"use strict"
function count(amount, cur = []) {  
  if (cur.length >= amount) 
    return cur;
  cur.push(cur.length + 1);
  return count(amount, cur); 
}

https://www.onsclom.net/posts/javascript-tco

#development #javascript #bun #tailCallOptimization #recursion #optimization #performance

How Single Sign-on Works And Why You Should Care

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

SSO - single sign on. Это такой тип авторизации, когда есть несколько сервисов одной или нескольких компаний и пользователь может залогиниться единожды в один из них, а в остальные сервисы авторизация расшарится автоматически  

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



https://fusionauth.io/articles/authentication/how-sso-works

#development #sso #authentication #authorization #saml #oidc

Making Sense Of “Senseless” JavaScript Features

Статья рассказывает про смысл казалось бы бессмысленных фичей Javascript. 

Первой под разбор попала классическая проблема , когда 0.1 + 0.2 = 0.300000001. Часто в интернете жалуются, что JS такой нелогичный язык, что нельзя надеятся на корректное сложение двух чисел. Однако это проблема общая для всех языков, которые поддерживают стандарт работы с числами с плавающей точкой.  В статье  подробно и в картинах разбирается, что это за стандарт и как он работает. Как минимум стоит прочитать этот разбор, если вы не знаете про этот механизм

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

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

Например, этот код отработает не так, как мы ожидаем, при взгляде на него

const a = 1
(1).toString()

const b = 1
[1, 2, 3].forEach(console.log)

Движок его приведет к виду

const a = 1(1).toString();

const b = (1)[(1, 2, 3)].forEach(console.log);

Поэтому проще всегда ставить ; в коде, чем помнить о том, как их вставляет движок

Следующая проблема: очень много значений, обозначающих "ничего" - null, undefined, NaN (в каком-то роде). И все они работают по разному. При этом разница между null и undefined не совсем понятная. Поэтому сообщество разработчиков часто спорит о том, нужен ли null вообще, ведь undefined выполняет всё те же функции, но ещё и не прикидывается object'ом.

Последний поинт в статье: операторы инкременты и декремента: i++ и ++i. Это явное наследие языка C. Хотя в большинстве случаев понятно как работает оператор, разработчики иногда допускают ошибки (сам лично допустил ошибку сегодня, пока делал заметки про Tail Call Optimization и сделал бесконечную рекурсию).

https://www.smashingmagazine.com/2023/12/making-sense-of-senseless-javascript-features/

#development #javascript

Дайджест за 2024-01-10 - 2024-01-12

Bun, Javascript, and TCO
Статья про tail call optimization - хвостовую оптимизацию вызовов. Когда мы вызываем функцию Б из функции А, то движок формирует call stack - стек вызовов. Это позволяет движку или процессору при выходе из функции Б в функцию А быстро восстанавливать состояние окружения. Но этот стек не бесконечен и, вроде, зависит от окружения (я знаю про ограничение в 65 536 в каких-то движках). Достаточно сложно упереться в лимит в обычном коде, но это реально сделать при реализации рекурсивных функций. Tail Call Optimization позволяет избежать этой проблемы, если движок видит, что функция вызывает саму себя.

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

How Single Sign-on Works And Why You Should Care
В статье разбирается базовый флоу работы ссо авторизации в двух имплемениациях: oidc и saml. Они немного отличаются, но в целом работают похоже. SAML чуть сложнее,  но более распространённая техника.


Making Sense Of “Senseless” JavaScript Features
Статья рассказывает про смысл казалось бы бессмысленных фичей Javascript. 

Первой под разбор попала классическая проблема , когда 0.1 + 0.2 = 0.300000001. Часто в интернете жалуются, что JS такой нелогичный язык, что нельзя надеятся на корректное сложение двух чисел. Однако это проблема общая для всех языков, которые поддерживают стандарт работы с числами с плавающей точкой.  В статье  подробно и в картинах разбирается, что это за стандарт и как он работает. Как минимум стоит прочитать этот разбор, если вы не знаете про этот механизм

——————————————

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

Legacy Seam

Небольшая заметка в блоге Мартина Фаулера про работу с легаси кодом. Данная заметка посвящена созданию швов в коде, которые позволили бы управлять поведением системы, не изменяя сам код системы. В статье на достаточном простом примере на JS показывается, как это можно реализовать и зачем это нужно.

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

async function someLegacyFunction() {
   /* страшный код на jquery */
   const result = await someLegacySystemCall()
   /* страшный код на jquery */
}

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

async function someLegacyFunction(deps = { systemCall: someLegacySystemCall }) {
   /* страшный код на jquery */
   const result = await deps.systemCall()
   /* страшный код на jquery */
}

Теперь мы можем конфигурировать вызываемую систему без изменения кода. Это и есть шов. Кроме DI есть и другие способы. В частности в статье Мартина Фаулера применяется Service Locator и возможности модульной системы JS.

https://martinfowler.com/bliki/LegacySeam.html

#development #javascript #martinFowler #legacy #refactoring