Добро пожаловать! Рад видеть вас в последней части моей серии сводок по JSWorld Conference 2022, в которой я поделюсь с вами кратким изложением всех выступлений.

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

  • Первый разговор: Колинг рассказывает о состоянии Deno в 2022 году, сравнивает Deno с Node.js и дает нам представление о работе с Deno.
  • Второе выступление: Негар рассказывает о том, как браузеры отображают CSS, а затем знакомит нас с CSS Houdini — набором низкоуровневых API-интерфейсов, раскрывающих части движка CSS.
  • Третье выступление: Декстер рассказывает о своем «идеальном» стеке, используя graphQL, SvelteKit, Docker и Github.
  • Четвертое выступление: Gift начинается с того, как серверы управлялись в прошлом, продолжается тем, как со временем стало лучше с бессерверными решениями, и чего мы можем ожидать от сервисов Cloudflare Edge.
  • Пятое выступление: Стейси рассказывает о создании личного бренда (блога), использовании Angular, TypeScript и статических веб-приложений в Azure, а также о том, как съесть слона по кусочку за раз.
  • Шестое выступление: выступление Сендила посвящено производительности и ее важности. Он дает несколько отличных советов по улучшению производительности вашего приложения.
  • Седьмое выступление. Наталья рассказывает о новом интерфейсе командной строки Azure Developer CLI, предварительная версия которого станет общедоступной в конце июня.
  • Восьмой доклад: Макс делится уроками, которые он усвоил за 4 года работы с Micro-Frontend в DAZN.
  • Девятый доклад: Элефтерия рассказывает об UX и UI с точки зрения пользователей и разработчиков, а также о том, почему вам как разработчику это должно быть интересно.
  • Десятая лекция: Джемайма рассказывает о скромном начале JS и о том, как он превратился в химеру фреймворков и библиотек, которые мы имеем сегодня.

(Повторяющееся) Введение

Спустя два с половиной года JSWorld и Vue Amsterdam Conference снова проходили в театре Амстердама с 1 по 3 июня, и у меня была возможность впервые посетить эту конференцию. Я многому научился, встретил много замечательных людей, поговорил с отличными разработчиками и отлично провел время. В первый день прошла конференция JSWorld, а во второй и третий дни — Vue Amsterdam.

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

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

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

Очень важный момент

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

И последнее, но не менее важное: я не вникаю в каждую техническую деталь или живое кодирование в некоторых выступлениях. Но если вам интересно и нужна дополнительная информация, дайте мне знать, и я постараюсь написать более подробную статью отдельно. Кроме того, не забудьте проверить их Twitter/Linkedin.

Здесь вы можете ознакомиться с программой конференции:



Конференция JSWORLD
1–3 июня 2022 г. Конференция JSWORLD в театре Амстердама. Присоединяйтесь к нет. Первая конференция по JavaScript на планетеwww.jsworldconference.com



Итак, начнем с последней части первого дня.

Содержание

  • Встраивание сборника рассказов: Герт Хенгевельд — главный инженер-программист в Chromatic
  • Препятствия при выпуске и поддержке мобильного приложения: Вим Селлес — ведущий архитектор решений в Saucelabs
  • SDK, отношения, любовь и гром: Сэмюэл Снопко — руководитель отдела по связям с разработчиками в Storyblok

TL;DR

  • Одиннадцатый доклад: Герт рассказывает о грядущих сборниках рассказов 6.4, 6.5 и 7.0.
  • Двенадцатая беседа: проблемы или трудности, которые необходимо преодолеть, чтобы наше приложение могло свободно перемещаться на телефоны наших конечных пользователей и обеспечивать себя всем необходимым для поддержания работы этого приложения.
  • Последний разговор: Этот разговор в основном об опыте. Каков наилучший опыт разработчика? Есть ли ответы в SDK, Relations, Love или Thunder?

Встраивание сборника рассказов

Герт Хенгевельд — главный инженер-программист Chromatic.

В Storybook 6.4 в Storybook добавлено интерактивное тестирование, реализованное в CSF 3. В версии 6.5 мы делаем все возможное для тестирования специальных возможностей и позволяем авторам дополнений предоставлять дополнительные методы тестирования. В Storybook 7.0 истории и их компоненты становятся источником правды на протяжении всего жизненного цикла разработки пользовательского интерфейса.

Вы помните такую ​​работу?

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

Но сейчас современные пользовательские интерфейсы собираются из компонентов по следующим причинам:

  • Эффективность: повторное использование существующих компонентов.
  • Скорость. Параллельная разработка между людьми и командами.
  • Качество: убедитесь, что интерфейсы работают в разных сценариях.
  • Техническое обслуживание. Выявляйте ошибки на уровне компонентов.

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

сборник рассказов

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

Общая концепция Storybook — это история:

import Badge from './Badge'
// Metadata
export default {
	component: Badge,
	args: {
		label: 'Hello world'
	},
}
// First Story
export const Small = {
	args: {
		size: 'small',
	},
}
// Second Story
export const Large = {
	args: {
		size: 'large',
	},
}

Storybook не зависит от фреймворка, поэтому вы можете выбрать свой любимый фреймворк.

Варианты компонентов, также известные как «истории»
Что бы вы определили для истории?

Разные состояния:

  • Загрузка
  • Неполноценный
  • В ходе выполнения
  • Ошибка
  • Принято / отклонено
  • Развернуто/свернуто

Пограничные случаи:

  • Длинный или короткий текст
  • Большие или маленькие изображения
  • Экстремальные числа
  • Недостающие данные
  • Специальные символы

Контекст:

  • Вошёл/вышел
  • Язык / местоположение
  • Цветовые предпочтения
  • А/Б-тест
  • Не в сети

И это становится более сложным, потому что существует бесчисленное множество комбинаций этих ситуаций.

Разработка пользовательского интерфейса — это командная работа

Совместное использование важно в рабочем процессе, потому что:

  • 👩‍🎨 Дизайнеры хотят вносить исправления в нужное время
  • 🧐 QA должен быть частью цикла разработки, а не после его развертывания.
  • 🎯 Владельцы продукта хотят проверить результаты
  • 🚀 Все хотят быть в курсе новых функций

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

Опубликовать в Интернете
Storybook предоставляет команду npm run build-storybook, которая дает вам статически экспортированную версию вашей истории, и вы можете загрузить ее на страницы Github, netlify или на chromatic, а затем вы можете поделиться свяжите это, например, с вашими заинтересованными сторонами, чтобы они могли поиграть с ними и убедиться, что это то, что они имели в виду.

Chromatic — это сервис поверх Storybook. Вы можете загружать свои истории в chromatic, и это дает вам библиотеку ваших компонентов.

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

Встраивайте в любом месте с помощью oEmbed
Вы можете просто вставить URL-адрес сборника рассказов в Medium или Notion. Он автоматически преобразует их во встроенные iframe и динамически регулирует высоту этого iframe.

Создайте свой собственный сайт документации

Более удобно извлекать документы из Storybook и размещать их на веб-сайте пользовательской сборки, и это Storybook Docs 2.0 (альфа), который позволяет вам брать те страницы MDX, которые вы пишете в Storybook, и добавлять их на свой собственный веб-сайт.

Тестировать код пользовательского интерфейса очень сложно

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

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

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

Теперь вы можете моделировать поведение пользователя в браузере. Это Powered by Testing Library, и они не изобретали велосипед.

import { whithin, userEvent } from '@storybook/testing-library'
import { SearchForm } from './SearchForm'
export default { component: SearchForm }
export const Submitted = {
  // Play function
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement);
    // Simulated events	
    await userEvent.type(canvas.getByRole('searchbox'), 'query');
    await userEvent.click(canvas.getByRole('button', { name: 'Search' }));
  }
}

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

Тестирование взаимодействия
Это дает вам утверждения на основе Jest и дает вам отладчик в браузере. Они также создали средство запуска тестов Node.js, чтобы мы могли запускать все эти тесты за один раз в безголовом браузере. И когда что-то пошло не так, Storybook может дать вам URL-адрес, по которому вы можете щелкнуть, и он откроет ваш Storybook именно в этом состоянии, и тогда вы сможете проверить и выяснить, что было не так.

import { expect } from '@storybook/jest'
import { whithin, userEvent } from '@storybook/testing-library'
import { SearchForm } from './SearchForm'
export default { component: SearchForm }
export const Submitted = {
  // Play function
  play: async ({ canvasElement }) => {
    const canvas = within(canvasElement);

    // Simulated events	
    await userEvent.type(canvas.getByRole('searchbox'), 'query');
    await userEvent.click(canvas.getByRole('button', { name: 'Search' }));
    // Assertion | Automatic spy on actions
    await expect(args.onSubmit).toHaveBeenCalledWith('query');
  }
}

Все это возможно в Storybook 6.5.

Препятствия при выпуске и поддержке мобильного приложения

Вим Селлес — Ведущий архитектор решений в Suselabs.

В настоящее время создать мобильное приложение довольно просто. Если у вас есть навыки работы с JavaScript/HTML/CSS, вы можете использовать такие технологии, как Ionic, NativeScript или React Native, чтобы выпустить свое первое приложение в App Store. Создание вашего приложения может показаться простым, но выпуск и поддержка вашего приложения, когда оно находится в производстве, может быть трудным. Во время этого доклада Вим расскажет нам о большинстве препятствий, связанных с выпуском и поддержкой мобильного приложения в рабочей среде.

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

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

Тогда вам понадобятся некоторые навыки. Вы можете быть мастером в HTML, CSS и JavaScript/TypeScript, но для разработки приложения и публикации его в магазинах приложений вам необходимо иметь некоторые навыки работы с iOS (Swift) и Android (Java/Kotlin). Но, возможно, веб-разработчикам проще работать с такими инструментами, как React Native, NativeScript и Ionic.

Итак, теперь возьмите свой кофе и свой Mac — если вы хотите разработать что-то для iOS, вам нужен Mac — и откройте свою любимую IDE!

Основываясь на выбранных вами инструментах, таких как React Native или других упомянутых инструментах, начните читать Документы, и вы увидите, что вам нужны дополнительные инструменты. Например, вам нужен Xcode для iOS или Android Studio для Android.

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

Пару дней спустя, когда вы построили свои первые экраны, вы протестировали свое приложение вручную на эмуляторах, возможно, вы захотите протестировать его на своем реальном устройстве. На Android вам нужно сделать несколько подписей, и когда вы получите свой ключ, вы можете отправить приложение Android на свой телефон Android. Но когда вы начинаете с Apple, первое, что вам нужно сделать, это использовать свою кредитную карту! Вам нужно иметь членство, и есть два их типа. Есть бесплатная, но вы не можете отправить свое приложение в магазин. Существует вариант по умолчанию, который стоит вам 99 долларов, но затем у вас есть возможность отправить свое приложение на свой телефон, а также, в конце концов, в магазин приложений, чтобы вы заработали немного денег на своем приложении, но помните, они все равно возьмут 30%.

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

Создание вашего приложения — которое лучше, круче и быстрее с m1 macs — и его развертывание настолько медленны по сравнению с Интернетом.

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

Теперь, возможно, пришло время отправить ваше приложение в магазин приложений. Android был бы проще, но для этого нам также нужно использовать нашу кредитную карту и заплатить 25 долларов, чтобы иметь возможность протолкнуть наше приложение в магазин. Но когда вы затем заглянете в магазины приложений Apple или Android, вы увидите, что вам нужно дождаться проверки, которая займет от 1 до 7 дней. Другая проблема заключается в том, что через пару дней вы можете получить электронное письмо, в котором говорится: «Ваша заявка отклонена», возможно, потому, что вы забыли предоставить учетные данные или по другой причине. Даже после принятия может пройти до 1 дня, прежде чем приложение или ваше обновление появится в магазинах, и это будет одинаково для каждого выпуска!

Через некоторое время, после этих тяжелых дней и стольких ожиданий, вы получите свой первый отзыв от пользователя, отзыв с оценкой 1,0 звезды!

Почему эта история?

Это то, что может произойти, если вы сравните это с вашим веб-приложением.

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

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

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

И последнее, но не менее важное: фрагментированный рынок. Существует огромное разнообразие устройств Android и ios с различными аппаратными и программными конфигурациями, различными уровнями версий ОС и местными жителями. и это до того, как мы перейдем к самому мобильному устройству, которому нужен прием, Wi-Fi, батарея и многое другое.

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

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

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

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

SDK, Отношения, любовь и гром

Самуэль Снопко — руководитель отдела по связям с разработчиками в Storyblok

Время летит быстро. Мы провели больше, чем последние два года, в онлайн-пузыре. Наша работа и жизнь медленно сливались воедино. Мы не ездим на работу, и мы намного эффективнее! Но мы? Мы изменились? Давайте остановимся на секунду. Давайте объединим наши головы. Давайте подвергнуть сомнению нашу креативность и продуктивность. Каков наилучший опыт разработчика? Есть ли ответы в SDK, Relations, Love или Thunder?

SDK

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

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

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

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

(Разработчик) Отношения

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

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

Я могу проследить историю своих родственников и пойти в старшую школу. У меня был учитель математики, который привел меня к тому, что я начал программировать. Моя первая работа в качестве фронтенд-разработчика, где я познакомился с кем-то, и он открыл для меня слово CSS и HTML, и он показал мне несколько журналов, книг и конференций, где я черпал вдохновение. где затем я установил некоторые другие отношения с другими, которые показывают мне красоту HTML и CSS. Мне очень нравилось то, что я делал, и это также причина, по которой я направился на Vue, а затем на Nuxt. А затем, после следующего, я встретился с генеральным директором Storyblok, и именно поэтому я здесь в качестве главы по связям с разработчиками и выступаю прямо сейчас. Если подумать, только один человек и одно отношение, которое я строил, могло изменить направление, в котором я двигался.

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

Когда у нас разные взгляды на одну и ту же тему, мы можем вдохновлять друг друга.

Нам всем нужно практиковаться, и это требует времени.

Креативность

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

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

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

Любовь

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

Гром

Борьба это хорошо. У нас разные мнения, но суть в том, чтобы не принимать их на свой счет.

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

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

Конец четвертой части

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

Предыдущие части можно прочитать здесь:

В течение следующих нескольких дней я сделаю то же самое для Vue Amsterdam Conference, которая проходила 2 и 3 июня сразу после конференции JSWorld. Следите за обновлениями…