Веб-разработка *

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

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

Ноутбук мне подарили ещё в 10 классе за хорошую учёбу. Я закончила школу, два университета, а он всё это время был со мной. Многое вытерпел: бесконечные загрузки всяких файлов из интернета, установки программ и расширений, сутки работы над документами, многочасовые просмотры фильмов и сериалов. Конечно, иногда его чистили, проверяли на вирусы, удаляли лишнее, но время берёт своё. И вот потихоньку он начал притормаживать. То включается долго, то ничего не грузится. Но в сложных (или, скорее, нестандартных) программах я не работала, поэтому в целом меня всё устраивало. Пока я не начала изучать вёрстку.

Мне дали ссылку на макет и инструкции. Но почти сразу что-то пошло не так.

Популярная библиотека для работы с состоянием веб-приложений на react-js это redux.  Однако у нее есть ряд недостатков такие как многословность(даже в связке с redux-toolkit), необходимость выбирать дополнительный слой(redux-thunk, redux-saga, redux-observable). Возникает ощущение, что как-то это все слишком сложно и уже давно появились хуки и в частности хук useContext.. Так что я попробовал другое решение.

Аудит CSS — задача не из легких

Основные источники

• DOM Living Standart
• HTML Living Standart
• Document Object Model (DOM) Level 3 Core Specification
• DOM Parsing and Serialization

Введение

JavaScript предоставляет множество методов для работы с Document Object Model или сокращенно DOM (объектной моделью документа): одни из них являются более полезными, чем другие; одни используются часто, другие почти никогда; одни являются относительно новыми, другие признаны устаревшими.

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

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

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

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

Один из способов классификации языков программирования – то, на сколько они сильно или слабо типизированы. В данном случае под «типизированный» подразумевается, известны ли переменные в момент компиляции. Хорошим примером будет сценарий, когда целочисленная 1 складывается со строкой, содержащей «1».

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

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

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

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

Кажется это хороший повод посмотреть как это было, может быть и вы заметите какие-то параллели со своим опытом.

Незаметно от всех 12 мая 2021 вышла новая версия известного микрофреймворка Flask.

Этот материал поможет настроить path aliases для вашего cretae-react-app.

Уже послезавтра, 14 мая, стартует новый поток курса Python для веб-разработки, поэтому мы решили поделиться переводом о не совсем очевидной, но интересной области разработки сайтов — анимации анимации. Автор не просто даёт готовый рецепт, но шаг за шагом показывает, как сделать анимацию прокрутки плавной и приятной. Эта статья больше о концепции, которая поможет вам по-другому взглянуть на вашу анимацию. Так случилось, что этот конкретный пример демонстрирует бесконечную прокрутку, в частности, «идеальную» бесконечную прокрутку колоды карт без дублирования какой-то из них.

После взлёта тайпскрипта (извини, flow) нетипизированные области фронтенда стали мозолить глаза гораздо сильнее. Логика уже давно на TS, вёрстка, при необходимости, на TSX, а вот у CSS ситуация посложнее.

Можешь использовать CSS файлы (с диалектами и модулями по вкусу) и указывать классы в вёрстке руками - но типизация здесь на уровне "препроцессор может сгенерировать тайпинги со списком классов прямо в рабочем дереве", да и в общем интеграция с рантаймом никакая. При этом гибкость диалекта достигается с помощью плагинов - которые, в общем случае, друг с другом (и, тем более, с IDE) могут и не дружить.

Либо бери любое из CSS-in-JS решений, предоставляющих полную типизацию и интеграцию с остальным кодом, но готовься платить ощутимое пенальти в рантайме - всё же парсинг объектов/строк со стилями занимает ощутимое время. Гибкость при этом, разумеется, максимальная.

Где-то в промежутке между ними находятся проекты вроде linaria или astroturf, которые предполагают парсинг CSS-in-JS на этапе компиляции (примерно как с graphql-tag). Типизация на уровне, производительность в рантайме - тоже, однако это всё ещё препроцессоры строк, пусть и более умные, так что расширяемость оставляет желать лучшего.

Вот тут-то в дело и вступает vanilla-extract. Пару месяцев назад Mark Dalgleish (один из создателей CSS модулей, кстати) решил узнать что получится, если использовать для препроцессинга стилей... сам тайпскрипт!

Спойлер: получилось очень хорошо. Впрочем, обо всём по порядку.

В рунете я почти не встречал материалов о том, как писать расширения для MediaWIki. Основной стартовой точкой был и остается официальный сайт платформы, но там процесс расписан не очень дружелюбно по отношению к новичкам. Попробуем же это исправить!

В этой статье я покажу, как написать простейшее расширение для Медиавики, включающее в себя новый метод API, расширение парсера и немного js/css для фронтенда. А чтобы не было скучно, приплетем сюда работу с Google Knowledge Graph.