Больше пары строк кода в посте или на скриншоте ведут в ад.
Для программирования на HTML https://codesandbox.io
Для Node.js с консолькой https://repl.it/languages/nodejs
Если рассчитываешь получить дельный ответ, сформулируй правильно вопрос: «что я хочу получить, что я для этого делаю, что я вместо этого получаю». Если когда самостоятельно найдёшь решение — поделись в треде, мы за тебя переживаем.
Документация - https://developer.mozilla.org
Руководство для вката - https://github.com/acilsd/wrk-fet#javascript
Старая паста, частично устарела - https://pastebin.com/9yRADC0s
Как создавать синглтоны? Так:
const singleton = {
поле: значение,
метод: function() {}
}
Или так:
class Singleton {
поле = значение;
метод() {}
}
const singleton = new Singleton();
Как правильнее?
>>1950972
А, перечитал Вики, короче синглтон должен запрещать создание новых экземпляров, возвращая самого себя в случае попытки пересоздания. Ну, это всё мне не важно, меня интересовал только синтаксис.
>>1950940
Мне синтаксис тут не нравится, через class удобнее. Тем более что можно использовать наследование (extends) и есть конструктор...
В зависимости от ситуации. Если у тебя есть набор логически связанных действий и данных, служащих одной конкретной цели, то удобнее и красивее будет объявить хорошо названный класс с продуманным интерфейсом, чем дрочиться с обычным объектом-хэшмапой. Если же ты просто хочешь запихать что-то в одно место, мержить это что-то с другим чем-то, убирать оттуда куски и т.д, то удобнее будет просто сделать объект, чем дрочиться с конструкторами и this.
>дрочиться с this
Эээ... я уже обдрочился этим this, есть способ обращаться к полям/методам класса без обязательного указания this? В других ЯП я никогда не встречал такого частого обращения к this/self (пытаясь убрать this, консоль срёт сообщениями "ололо не найдено").
Ладно.
А локально сокращать код как-нибудь можно?
Вот у меня часто бывает что-то вроде такого:
>for (let i in this.parent.items)
>if (this.parent.items[ i ] !== this)
>this.parent.items[ i ].close();
В некоторых языках есть оператор with, можно ли сделать так:
>with (this.parent)
>for (let i in items)
>if (items[ i ] !== this)
>items[ i ].close();
? А то конструкции уж больно монструозные получаются.
Предполагаю, можно сделать так:
>const p = this.parent;
>for (let i in p.items)
>if (p.items[ i ] !== this)
>p.items[ i ].close();
Т.к. parent - объект, то в p копируется только ссылка.
Но не сильно ли такой способ "сокращения" загружает JS-машину?
Я знаю только что интерпретаторы медленные и сайты с обилием JS на моём компе/телефонах часто тормозят, NoScript их ускоряет. Не хочу идти по чужим граблям и нагружать интерпретатор мусором.
>если есть forEach, map, reduce
Слышал о таком, никогда не использовал, надо погуглить.
>>1951015
Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес. А это делается только для удобства программиста или filter() и forEach() будут быстрее одного for с if'ми? Просто как по мне, for и if читабельнее, ближе к тому, как я представляю решение задачи. Я читаю это примерно так: "для каждого i в items, если items не этот объект, то закрыть его". А твоя запись хоть и понятна, но не читается, что-то вроде "фильтровать items, убрав этот объект, затем каждый закрыть"? Мастера Йоды получается код)
>>1951021
Это вообще непонятно, это ФП или что-то новое? Как гуглить?
>>1951025
Согласен.
>Не хочу идти по чужим граблям и нагружать интерпретатор мусором.
Это как говорить что не хочу портить океан и ссать в него. Нужно нагрузить очень много джаваскрипта в память, чтобы вызвать тормоза хоть на пару миллисекунд на уровне языка. 99% тормозов в веб-приложениях из-за DOM, то есть обновления самой страницы и ререндеринга, а не из-за вычислений переменных в JS'е. В примере выше
>this.parents.items
>.filter(item => item !== this)
>.forEach(item => item.close());
Мы делаем 2 цикла, вместо одного, как в императивном подходе, но это не имеет никакого значения пока у тебя в массивах меньше 10к элементов.
>>1951037
>Я привык всё вручную делать, императивно. ФП вообще боюсь, тёмный лес.
Ну тогда тебе будет тяжело найти работу, т.к. на фронте сейчас ФП подходы более приветствуются, т.к. читаемость и расширяемость кода это одна из главных характеристик хорошего кода, а не пикосекунды исполнения. Вызывание функций намного более читабельнее и реюзабельней, чем портянки из if и for. Конечно, в твоем примере разницы никакой нет, но добавь туда еще 1-2 проверки и еще одно действие которое надо будет выполнить над items (а это зачастую и нужно сделать в реальных проектах рано или поздно) и ты уже получаешь лапшу:
>for (let i in this.parent.items)
>if (this.parent.items[ i ] !== this && this.parent.items.isOpened)
>this.parent.items[ i ].close();
>if (this.parent.items.hasSomething)
>this.parent.items.doSomething();
Это нечитабельный и очень императивный код в своей основе. Конечно, он кажется читаемым потому что ты написал его 5 минут назад и ТЫ написал его. Но для других программистов нужно прикладывать когнитивные усилия, чтобы осмыслить цикла, доступа к объекту, проверке !== и вызове метода. В подобном коде легко сделать ошибку.
В функциональном подходе из-за того что код разделен на мелкие, но хорошо делающие свои работу функции, код очень легко расширять, менять и читать. Циклы, проверки и другие частые операции уже вынесены в функции и тебе не нужно переживать что кто-то где-то скипнул часть цикла или поменял элемент внутри массива по ошибке.
Но, безусловно, есть некий порог входа и в самом начале изучения ФП код кажется более СЛОЖНО читаемым. Но через некоторое время практики ты будешь удивляться, как теперь весь код для тебя это процесс вычислений значений и будет сложно писать в императивном стиле (потому что на него нужно тратить больше усилий).
В любом случае, не обязательно нырять в функциональный подход на 100, более того зачастую это невозможно, потому что код над которым ты работаешь это легаси от прошлых разрабов или команда в которой ты работаешь слабая по скиллу и может только хреначить портянки на jQuery сам начинал с подобного.
В твоем случае forEach и filter предпочитаемы итеративному обходу и проверке, просто небольшой совет.
Мде, писал тут пасту про STMы, а модер взял и потёр тред, где я всё это писал, ну ладно.
Окей, переформулирую.
Хорошо, представь себе список, где каждый шаг описан в декларативном стиле. Вот это то, что позволяет тебе саги.
>>1951202
Я сравнил разные стейт-менеджеры и не нашёл ничего такого, что побудило бы меня начать юзать другой STM.
redux-saga - до сих пор лучшее, что есть для асинк флоу логики.
>переформулирую
Это не отвечает на вопрос о естественности.
С чего ты решил, что декларативно естестевннее императивного?
Сравни.
1. Обуйся.
2. Надень шапку.
И
1. Ты обут.
2. Шапка надета.
С тобой в детстве мама в каком формате разговаривала, что для тебя второй более естественнен?
То что ты выше перечислил выглядит естественным.
Неестественным это становится, когда ты смотришь на какой-то код и не понимаешь, что он означает, потому что он написан таким образом, что зависит от многих других частей.
Задача программиста - выразить сложный флоу естественным образом, чтобы он читался как рецепт, а не мешанина хуй знает чего.
Скажем, императивность имеет разную степень абстрагирования.
Задача программиста - выразить сложный флоу таким образом, чтобы это всё было в читабельном для человека виде, а не только для машины.
const makeUsername = word |> stripSpace |> rejectNonalphabetic |> validateLength
Так. У меня другая проблема. Я повесил эвент листенер. И он нормально передает значение в компоненты при ресайзе. Но вот в чем дело, мне нужно как-то считать initial размер окна еще до любого ресайза. Я бы мог просто присвоить начальное значение из текущего размера окна winWidth = windows.innerWidth. Но вот очевидно что ssr такое не понравится. И я не знаю как обратно к серверу передать значение из клиента. Чтобы на сервере тоже размер окна брался сразу с клиента, потому что если использовать всякие юзэффекты, то стили будут прыгать, потому что изначально значение будет браться из стора. В какую сторону гуглить?
Один раз об такое уже споткнулся. Оказалось, что крайне неудобно бегать с репозитория туда-сюда, когда фактическая зависимость между кодом в разных репах осталась высокая. Многие изменения требовали вносить правки сразу в несколько репов, что оказалось просто болью.
Это, впрочем, не проблема разделения на отдельные репозитории, а проблема, что огромный монолит распилить красиво, что бы потом все было удобно и без зависимости друг от друга, действительно сложно. В итоге тот проект вернулся в один реп, но был поделен на несколько кусков которые могли собираться независимо друг от друга.
>>1951285
Бля, парни, я про репо в контексте паттерна ( https://developer.android.com/jetpack/guide#connect-viewmodel-repository ), а не структуры проекта.
>из-за DOM, то есть обновления самой страницы и ререндеринга
Кстати, как это правильно делать, если нужно вывести (div.append()) сразу много элементов?
>это не имеет никакого значения пока у тебя в массивах меньше 10к элементов
Я обычно программирую как привык. И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест. Зачем писать неоптимально, если более быстрый вариант пишется нетрудно? Я же не ассемблерные вставки пишу. А то здесь два цикла, там два цикла, так и накопится снежный ком лишних действий, а потом поди разберись в нём.
>найти работу
Так а я и не ищу) Для работы нужно иметь кучу других качеств и навыков, кроме программирования на уровне любителя. Я пишу программы для своих задач и удовольствия, остальное меня не интересует.
>читаемость и расширяемость
Знаю и понимаю. Но функции - это не уникальная черта ФП. Портянку из for и if я дроблю на субфункции, когда становится непонятно, что происходит. И эти субфункции я могу назвать в соответствии с контекстом, не полагаясь на стандартное название из какой-то библиотеки.
>получаешь лапшу
Лапша - это когда в коде много связей между случайными участками, т.е. из многих мест идут обращения во многие места, из-за чего становится трудно понять, что на что влияет и как оно вообще работает. А длинный код не обязательно "лапша", его обычно можно разделить на отдельные функции, передавая результат от одной к другой.
Твой пример можно переписать читабельнее, но, во-первых, данными управлять должен сам элемент. Если данные нужно сохранить перед закрытием, то проверка и сохранение данных происходят в методе item.close(), а не в item.closeSiblings(), следовательно код упрощается.
Во-вторых, проверка открытости элемента производится опять же самим элементом в методе item.close(), потому что наше дело предложить ему закрыться, а ему решать, может ли он закрыться.
Тогда будет только:
>for (let i in this.parent.items) if (this.parent.items[ i ] !== this) this.parent.items[ i ].close();
А вот уже в close() будет что-то вроде:
>if (this.opened) { this.saveData(); this.toogle(); }
В saveData():
>if (this.needToSave) { ... }
...ну, ладно, один .forEach тут бы не повредил, типа
>this.parent.items.forEach(item => { if (item !== this) item.close() });
Но смысла в .filter() здесь не вижу. Фильтр был бы полезен, если бы мы потом с этим списком что-то сложное делали, т.е. сохраняли отдельно и редактировали...
А вообще я не пойму, в чём тут ФП? Это же императивные команды "сделай это", даже порядок соблюдается слева направо, а не наоборот. Против такого кода ничего не имею, пока названия функций имеют смысл (forEach = для каждого, в данном контексте нормально). Но большая часть виденного мной функционального кода читаемых имён не содержит (зато куча спецсимволов).
>код поделён на мелкие функции
Так и мой код тоже поделён на мелкие (по возможности) функции. Только у моих функций название есть и соответствует контексту/области видимости, а в функциональщине названий либо нет, либо они из спецсимволов и скобок.
Тот же цикл forEach, по-хорошему, часть императивного кода:
>for item in items do if item <> self then item.close();
Вот это максимально читаемый код, читается как русский язык:
>для каждого итема в итемс проверяем что это не мы и закрываем соседей
А если оборачивать в скобки и спецсимволы, получается нечитабельная фигня.
Вообще я фанат алгол-подобных языков, хочу обмазываться длинными словами из букв и не хочу контактировать со спецсимволами. Увы, в вебе есть только JS, но я уже не против, тут не так много спецсимволов, как во всяких сях.
Декларативные языки вообще несравнимы с императивными и имеют свою нишу, в которой императивные просто не нужны (пример - html).
Твой императивный пример:
- выйти на улицу:
- - одеться:
- - - снять домашнюю одежду
- - - надеть нижнее бельё
- - - надеть верхнюю одежду
- - обуться:
- - - надеть ботинки
- - - зашнуровать ботинки
- - надеть шапку
Он чётко описывает, что нужно сделать и как, задаёт последовательность. Машина просто считывает команды друг за другом и выполняет их как они есть, если они выполнимы данной машиной.
Декларативный:
- нужно выйти на улицу
- для выхода на улицу нужно быть одетым в уличную одежду, обутым и в шапке
- чтобы быть одетым, нужно надеть одежду
- чтобы надеть одежду, нужно снять одежду
- сейчас я в домашней одежде
- домашняя одежда это одежда
- уличная одежда это одежда
- чтобы быть в шапке, нужно надеть шапку
- чтобы быть обутым, нужно обуться
- чтобы обуться, нужна обувь
- ботинки это обувь
- после обувания в ботинки шнурки должны быть завязаны
и т.д. Я точно не знаю, набросал как сам понимаю.
Суть декларативного подхода в том, что ты просто сбрасываешь в одну кучу описания разных объектов и действий, а затем говоришь: "я хочу объект с такими-то характеристиками". И машина, используя описания объектов и действий, по каким-то своим алгоритмам находит способ создать требуемый объект, затем создаёт его и возвращает пользователю. Тебе не важно, как работает машина и какие решения она принимает для создания желаемого тобой объекта, тебе нужен только объект с какими-то характеристиками.
Вот более реальный пример:
><div style="border: solid 1px black; width: 100px; height: 50px; background: white"></div>
Это декларативный подход. Мы говорим машине: мне нужна коробка размером 100 на 50 пикселей, с чёрным контуром в один пиксель толщиной и белой заливкой. Как и что она будет делать нас не волнует, нам нужен результат.
В императивном стиле было бы так:
>canvas.pen.color = black;
>canvas.pen.width = 1;
>canvas.brush.color = white;
>canvas.rectangle(0, 0, 100, 50);
Здесь мы явным образом задаём параметры конкретных инструментов (canvas, pen, brush) и используем их для создания прямоугольника конкретным способом (описанным в методе rectangle). Нам важно, чтобы задача была выполнена именно с помощью этих инструментов и именно в такой последовательности. Когда же мы описываем <div> в html, нам совершенно без разницы, что и как будет делать браузер, лишь бы результат соответствовал ожиданиям.
Короче, декларативный подход используется чаще, чем кажется, и не нужно на него фукать, у него просто своя область применения.
Во-первых, зачем ты это все написал, если анон, которому ты отвечаешь, написал все то же самое, только короче.
Во-вторых, нить дискуссии была о том, с чего ТС взял то декларативное описание ЕСТЕСТВЕННЕЕ императивного. И вот теерь посмотри на свои описания алгоритмов в императивном и декларативном стиле, и скажи - какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА.
>И если привыкну к неоптимальному подходу, буду использовать его всегда, а потом тратить время на поиск узких мест.
Я даже представить не могу что нужно делать, чтобы узким местом было использование filter и foreach вместо одного for, ты там совсем ебанулся? Ты мне почему-то напоминаешь одного чувака, который, когда учился играть на пианино, спрашивал какой стороной подушечки пальцев нужно нажимать на клавишу.
type Connection<T> = ...
type RequireConnection<T> = T extends Connection<infer X> ? T : never;
type Config<T extends Node, K extends keyof T> = {
connection: RequireConnection<T[K]>
...
}
При записи все нормально, иде подставляет нужные поля, но при чтении дженерика Config<any, any> она говорит А ВДРУХ БЛЯТЬ ВСЕТКИ НЕВЕР, и сует connection: any.
Что изменить?
Два цикла подряд вместо одного = в два раза дольше обработка данных.
>>1951056
>В твоем случае forEach и filter предпочитаемы
Я нашёл фатальный недостаток forEach:
>Error: Cannot read property 'forEach' of undefined
Т.к. forEach - метод класса Array, если мы получаем откуда-то вместо массива пустышку, код валится с ошибкой. Можно вставить проверку на undefined, но зачем, если цикл for не сделает ни одной итерации безо всяких дополнительных проверок? Вместе с проверкой на undefined кода становится больше, чем с обычным циклом for.
Я создаю экземпляр класса, давая конструктору массив, в котором вторым элементом может быть вложенный массив, и конструктор создаёт вложенные экземпляры того же класса по той же схеме. Вложенность, естественно, ограничена размером стека, но мне хватит. Так вот последний по вложенности класс получает вместо массива undefined, т.к. в прошлом массиве был всего один элемент. С for работает без проверок, красиво и просто, с forEach придётся костылить проверку на undefined. Нибуду((
>какой из них ЕСТЕСТВЕННЕЕ для ЧЕЛОВЕКА
Естественнее в каком плане?
Если тебе нужно пошагово объяснить ребёнку/дебилу/старику/иностранцу какие-то действия для достижения какого-то результата - да, тут императивный подход только и можно применить. Чтобы человек не метался в панике и не пытался делать то, что делать опасно, неэффективно или бесполезно. Например, показываешь ребёнку, как надевать курточку - "левую ручку сюда, правую сюда, и смотри не прищеми пальчики молнией" (хотя последнее уже декларативное).
Если же тебе нужно дать задание взрослому здоровому адекватному человеку, тем более специалисту в какой-то области, то тебе достаточно сформировать запрос: "нужно то-то и то-то, в таком-то виде и объёме к такому дню". Ты же не будешь учить уборщицу мыть полы типа "воду наберите в ведро, тряпку макаете в воду и трёте тряпкой пол, пока вода не загрязнится, меняете воду и повторяете пока пол не станет чистым" (она посмотрит на тебя как на поехавшего), ты скажешь ей только "вот здесь чтобы пол был чистым, через час проверю".
Окей, уборщица может быть новенькой и не знать, где инвентарь. Но ты не говоришь ей "иди до двери, возьмись за ручку, открой дверь, отпусти ручку, наклонись, возьми ведро и швабру, закрой дверь ногой, развернись на 180 градусов, пройди до начальной точки". Ты говоришь ей "швабра и ведро находятся в подсобке, подсобка по коридору прямо за маленькой дверью". Дальше она сама находит в своей памяти нужную программу для достижения двери, извлечения инвентаря и его использования для мытья пола. Или не находит и увольняется))
То есть мы общаемся в основном в декларативном формате:
- подай соль
- принеси табуретку
- расскажи о прочитанной книге
- сделай мне сайт, где я буду весь такой хороший
- помогите решить задачку, вот ошибка, вот что хочу сделать, не выходит
И так далее. Мы не пишем программы, мы запрашиваем желаемый результат. Даже обучение не всегда основано только на создании программ - часто предлагается самому найти решение, эксперименты помогают в обучении.
Даже в этом примере видно, что разница в пять раз. Добавь в конец третий цикл конструкции some и разница увеличится до 10 раз.
А теперь умножь таких конструкций по несколько штук на каждый чих, когда у тебя по всему проекту эти маленькие коллекции. Разница возрастает на порядки.
Энтри левел вкат: Functional Light JS - я бы советовал начинать всем с этого, прагматичное ФП, очень хорошо разжевываются самые основы. Книга полезна не только как вкат в ФП, а как учебник по JS и построению программ в целом. https://github.com/getify/Functional-Light-JS
Некст лвл вкат: Mostly Adequate Guide To FP - ФП с корабля на бал, намного больше терминологии и объясняются основы теории категорий, но если вдумчиво читать, то одно из самых приятных введений в функторы и монады которые я видел. Желательно хорошо знать JS перед чтением.
https://drive.google.com/file/d/1NAlmEylllMM5zS8xke6pd16k2ULvbBZ0/view?usp=sharing
Они везде и есть. У меня на работе есть супер сложный редьюсер, которые наверное массивов 20 по 1000 объектов перебирает по несколько раз и всё это занимает 1.7 мс.
Все эти перфоманс дрочки это лишь отсутствие практического опыта разработки. Тот кто шарит понимает, что в вебе узкое место это апдейт DOM, а не джаваскрипт.
Да у тебя один Layout пересчитываться будет десятки миллисекунд спасибо реактоговну, дрочка на фреймы бред. Тот, кто шарит знает, что код пишется не для машины, а для человека в первую очередь, особенно на высокоуровневых языках программирования. Про фреймы будешь рассказывать коллегам, когда они охуеют из твоих for-if'ов и мутаций переменных и будет невозможно добавить новый функционал без ебли.
Помогите полному долбоёбу плз
почему response.status возвращает undefined? при том, что сервер отвечает кодом 200
Еще вопрос - почему в этом коде если поставить await перед fetch, то выскочит SyntaxError - требуется async функция, хотя в учебнике на learn.javascript подобное написание прокатывает?
Да, я полный нубас в js. И да, я на коне
Вот такой экземпляр норм
https://mirlib.ru/knigi/programming/354045-mastering-javascript-a-complete-programming-guide-including-jquery-ajax-web-design-scripting-and-mobile-application-development.html
?
Сук, а ты хорош.
>>1951339
Если стремишься к реюзабельности компонента, его изолированности от окружения и тестируемости (хотя простые компоненты и так нехуй тестировать), то, очевидно, всю логику, в т.ч. IO поебень выносить в отдельные сущности, а клеить тонкой прослойкой типа контейнера, который осуществит необходимые подписки и пробросит пропсы в целевой компонент. Это если делать по уму. А ежели просто ебошить - то делай, как удобно.
1. Нужно соединить 1 обсерваблу из самого компонента, и одну сверху. Если кроме как тут она нигде не нужна, то передавать сверху собственно готовую обсерваблу, или простое значение, а в компоненте уже пулять локальную по изменению?
2. В методичке просят переданное сверху не мутировать, но в то же время реактивные формы этим внаглую занимаются, т.е. их считают за сервис, хотя они не инжектятся, а дриллятся. Как тогда понять, когда это норм, а когда зашквар?
А инкапсулировать будет кто, Пушкин? Без инкапсуляции и с константами прямо в логике твой слайдер может быть только один на странице, на которой кроме него нет никаких картинок (ты же вообще все <img> зохавал?).
Нужен класс:
class ImageSlider {
constructor(name, images, owner) {}
}
Где:
- name определяет CSS-класс, по которым один слайдер отличает элементы других слайдером от своих. Все картинки и кнопки должны иметь этот класс.
- images определяет набор картинок, которые нужно воткнуть в этот слайдер, потому что создавать мы его будем динамически (кому нужна статическая страница с жыс-слайдером картинок в 2021?).
- owner определяет элемент, к которому этот слайдер сам себя добавит (чтобы нам не нужно было его вручную добавлять, просто сделал new ImageSlider() и забыл про него, пока не понадобится удалить).
>>1952023
Забыл ещё, ты перезаписываешь свойство стиля display, а что если тебе нужно картинки отображать не как block? У этого свойства много значений.
Правильнее будет присвоить картинкам определённый класс, в нём обозначить свойство display и присвоить ему нужное значение (block или что угодно другое кроме none), а в твоём коде вместо display = "block" делать просто display = "". Так восстановится значение класса, перезаписанное присвоением display = "none". А первоначальное присвоение none должно быть в конструкторе класса, который размещает предложенные картинки внутри слайдера.
Сам недавно переписывал свой код, когда потребовалось абстрагироваться от значения "block", решение оказалось неожиданно простым.
Согласен, переписал на изменение классов сплавным переходом.
Про конструктор на классах читал. Но вот энта инкапсуляция на практике пока мне не попадалась, все что ты написал я понял. Но реализовать на практике пока не хватает опыта.
>инкапсуляция на практике пока мне не попадалась
Я недавно вот такую менюшку себе сделал, суть такова: есть меню с выбором вариантов ответа, каждый вариант может быть вложенным меню со своим набором вариантов ответа, и так далее. То есть рекурсивная структура. Сделано просто рекурсивным созданием новых объектов одного и того же класса, а запускается созданием самого первого объекта передачей в него всей необходимой информации. Внешний вид, цвета, расположение и форма, даже сортировка (выбранный пункт поднимается наверх, к заголовку группы) - это всё на CSS, на JS только логика создания/открытия/закрытия группы и передача результата (тому, кто создал это меню) с его самоуничтожением в случае успешной обработки результата. По-моему гениально, осталось только отрефакторить и убрать мусор из кода. Короче, без инкапсуляции в класс это было бы намного труднее сделать.
Вряд ли кому-то понадобится делать галерею в галерее в галерее, но несколько одинаковых галерей на одной странице - это очень распространённая ситуация, например, в газетных статьях и на страницах-демонстрациях какой-нибудь программы/библиотеки/технологии.
>реализовать на практике пока не хватает опыта
Это очень просто на JS, сравнивая с другими ЯП)
чсв поднялося
>нет смысла делать эти микрооптимизации
https://habr.com/ru/company/vdsina/blog/544218/
>O(n^2) — оптимальное время для плохо масштабируемых алгоритмов — достаточно быстро, чтобы попасть в продакшен, но достаточно медленно, чтобы ломать всё, после того, как он туда попал.
>Если вы пишете код, который будут запускать другие, то убедитесь, что он достаточно хорошо масштабируется для обработки любого возможного множества данных, вне зависимости от его разумности. Квадратичные алгоритмы обычно проваливают эту проверку.
Это просто к слову о том, почему задумываться о том, как код будет работать с большим объёмом данных - полезно, даже если сейчас ты не собираешься загружать его такими объёмами.
У меня все проходит через сервис, который состояние запросов записывает в стор, а компоненты лишь отрисовывают контент в зависимости от состояния стора и наличия данных в кешируемых хранилищах данных.
в плане других языков
Лол, я сам большую часть сознательной жизни кодил только на строго типизированных языках (Паскаль и подобные ему). Так что я знаю, зачем нужны типы, регулярно создавал новые и всегда указывал их (иначе не складируется), а от слабо типизированных языков шарахался. Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще, а ошибки если и бывают, то не критичны - не прошивку ракеты/самолёта же кодим. Но я-то опытный, хоть и любитель, а вот новичкам, конечно, слабо типизированные языки только вредят, имхо.
>число стало строкой
И часто оно у тебя так случается? По-моему это возможно только когда ты пытаешься сложить строку с числом, вместо сложения происходит конкатенация. Зачем, спрашивается, делать конкатенацию там, где она не нужна?
>тридцатикратно вложенном компоненте
Ты должен делать тесты каждого уровня вложенности начиная от первого изменённого уровня до самого верхнего. Сделал изменение - провёл тест и убедился, что всё работает. Как только тест показывает ошибку, ты уже знаешь, что эта ошибка возникла из-за последнего внесённого тобой изменения, потому что до этого все компоненты тесты проходили успешно. Ну или у тебя ошибка в тесте, лол)) А если ты тестов не делаешь и пишешь сотни строк кода без единой проверки - зачем ругаться на язык? Сам виноват.
Меня вот Паскаль приучил тестить программу после каждой строчки/изменения в коде. Даже после написания комментария предпочитаю перекомпилировать, а то вдруг где-то что-то поломал. Ну а с JS всё ещё проще: компиляции как таковой нет, достаточно переключиться на браузер и нажать F5, все изменения и возможные ошибки будут сразу же явно видны. Т.е. городить систему типов особого смысла нет, зато время на выдумывание этой самой системы уходит намного больше, что замедляет прототипирование.
Вот, например, ты боишься, что у тебя integer превратится в string. Но это цветочки, ты не должен указывать x: integer, ты должен придумать новый тип, например, TValue = Integer, а затем следить за тем, чтобы TValue не попадало в Integer, потому что это разные типы, хоть и числовые. В языке Ада такие проверки из коробки, но вряд ли тебе понравится на ней программировать (очень долго и очень трудно выдумывать новые типы)...
>Mostly Adequate Guide To FP
12 страница, там где автор сначала пишет через класс Flock - реально надо минимум когнитивных способностей чтобы понять что происходит. Потом начинает городить фп ересь, где уже реально нихуя не понятно сходу. Вот и ответ о применимости фп как подхода.
>Но сейчас понимаю, что слепить прототип программы без указания типов на порядок быстрее и проще
Вот именно что прототип, для большого приложения чистый js это пиздец полный, мне по крайне мере от него просто блевать тянет. Даже если через неделю к коду вернешься уже нихуя непонятно куда какие объекты передаются и какие у них поля/методы. А так у меня даже с ts бывают ошибки когда я неправильно тип возвращаемый с бэка указываю, боюсь представить что бы было если бы вся прилага была без ts.
Я что долбоеб запоминать какие значения у меня могут быть undefined, чтобы проверки добавлять? Тем более в ts есть пиздатый синтаксис object?.field. Короче ванильный js это калище дикое, а ts тупо кайф.
А ты не всегда можешь знать наверняка. Я буквально недавно пилил бэк для личного проекта и решил не заморачиваться с тайпскриптом, в итоге я напридумывал новых фич и следить за всем и держать все типы в памяти стало очень больно. В итоге пришлось все на ts переписывать.
>>1952496
Я лично по настоящему больших проектах не писал, но участвовал по крайне мере в средних и везде использовался тайпскрипт, а там где не использовался был постепенный переход. Был еще проект, где некоторые типы в комментах указывались, не помню уже как такой подход называется, но как по мне проще уже реальный ts подключить.
Не то чтобы я дохуя сеньер, но по моему личному опыту ts выручал дохуя раз.
>Это же пиздец нелогично и как это потом все мокать для тестов?
В чем именно по-твоему заключается проблема замокать запрос внутри компонента?
>У меня все проходит через сервис
Который работает магическим образом сам по себе, и к которому компоненты не обращаются вообще никак и не говорят ему, что фетчить и когда?
Я мимо проходил, хз что там про моки. Это лучше тем, что всё спрятано в service/api, в компоненте ты только функцию вызываешь которая возвращает response либо ошибку если она была.
Вот тут другой анон уже писал про это: >>1952278
Удобнее держать все обращения к апи с клиента в одном месте
>>1952724
Каким боком тут ООП? api может быть просто объектом с методами.
const api = {
getSomeData() {
// тут фетч
}
}
https://developer.mozilla.org/en-US/docs/Learn/Getting_started_with_the_web/JavaScript_basics#adding_an_image_changer
Здесь пример
let myImage = document.querySelector('img');
myImage.onclick = function() {
let mySrc = myImage.getAttribute('src');
if(mySrc === 'images/firefox-icon.png') {
myImage.setAttribute('src','images/firefox2.png');
} else {
myImage.setAttribute('src','images/firefox-icon.png');
}
}
У меня в myImage на первой же строчке не записывается атрибут src. В итоге onclick не cрабатывает. Чому так?
Эм. Я нуль, ты имеешь в виду, что если вот у меня слева нет src, то он и не возьмется в переменную? Или под показом дом ты что имеешь в виду? Консоль пустая.
Сука, че за пример такой на первой же странице по js для желторотиков, который не работает.
Поэтому я и скахал что про лвл вкат. Никто не говорит, что ФП это 1 страницу книжки прочитал и выучил за день. Если выглядит как ересь, значит у тебя либо мало опыта разработки, либо опыт твой это писанина на реакте была.
Без опыта это месяц как минимум изучения подхода к написанию кода и обработке данных, ведь нужна практика, конечно же. Зато потом ты становишься намного лучше разработчиком даже на ООП, даже если ФП не используешь в повседневном кодинге, мозги прокачиваются хорошо.
указываю размеры здесь:
<div class="container">
<canvas id="lineChart" width="600" height="400"></canvas>
</div>
высота графика меняется, а ширина всегда остаётся одной и той же.
пробовал в опциях графика разные комбинации responsive:false и maintainAspectRatio: false, но ничего не помогло. Так же прописал Chart.defaults.global.maintainAspectRatio = false; (до этого даже высоту нельзя было поменять)
Подскажите пожалуйста, что делать?
Затем что вот здесь хуйню спизданули:
>>1952703
> Который работает магическим образом сам по себе, и к которому компоненты не обращаются вообще никак и не говорят ему, что фетчить и когда?
Если кто-то несёт хуйню, то почему бы не поправит его? Но тут походу безнадежный случай, человеку ООП мерещится там, где его нет. Вкатыш походу
Ну ты все правильно делаешь.
Вообще реакт должен отвечать исключительно за UI. Все остальное должно быть за его пределами. Именно поэтому хуки по типу useReducer и useEffect налево направо превращают реакт в лапшу из сайд эффектов. Мне кажется во времена классовых компонентов они выглядели хоть и более многословными, но почище.
В классе C есть конструктор, в котором инициализируется условная конфигурация, получаемая от объектов класса A и B.
В классе C есть так же статичные методы, которые задействую эту информации и выводят на экран.
Учитывая асинхронность ноды, мое приложение выглядит так:
const a = new A();
a.run(...);
const b = new B();
b.run(...);
const c = new C(a.getInfo(), b.getInfo());
c.run(...);
В экземплярах объектов a и b метод run(...) вызывает те самые статичные методы класса C.staticMethod() и выводит корректно информацию, хотя конструктор этого класса еще не был вызван, а значит информации от a и b там быть не должно.
Даже, если представить, что конструктор C вызвался раньше, чем отработал любой из методов run(...) a и b, и вывел эту информацию, то можно заблокировать главный поток перед инициализацией c на 5 секунд, но метод run(...) объектов a и b все равно выводит корректную информацию статичными методами по расписанию и без задержек, после чего через те самые 5 секунд срабатывает вывод из конструктора C, что подтверждает то, что главны1 поток был прерван до вызового этого конструктора.
Почему так?
>начал вертеть жопой и петросянить, вместо того, чтобы просто попросить больше информации
>получил ответ в таком же стиле
>рррряяяяя не огрызайся дай пример лучше
>буквально на пальцах, оперируя тремя буквами/объектами, объяснил все изначально максимально подробно с кодом в 3 строки
>Вообще реакт должен отвечать исключительно за UI.
За UI должен отвечать html/css. Жабаскрипт - за логику.
>Все остальное должно быть за его пределами.
Яскозал?
>Именно поэтому хуки по типу useReducer и useEffect налево направо превращают реакт в лапшу из сайд эффектов.
То ли дело вызывать сайд-эффекты через глобальный стор. Зато ООП!
>Мне кажется во времена классовых компонентов они выглядели хоть и более многословными, но почище.
Это ты ебанину с дублирующей логикой назвал "почище"?
> За UI должен отвечать html/css
Как там в 2010?
> Жабаскрипт - за логику.
Конкретно реакт — библиотека для отображения UI.
> То ли дело вызывать сайд-эффекты через глобальный стор
Что не так? Это самая удобная модель.
> Зато ООП!
Где в редаксе ООП? Ты вообще понимаешь о чём говоришь, или просто так бредишь лишь бы спиздануть?
мимокрокодил
От сюда появляется вопрос: как лучше спроектировать классы? Ведь то что у меня сейчас, это неправильно.
У меня в одном приложении есть 3 основных класса: Server, Database и Console.
Server - обрабатывает http запросы.
Database - работает с бд, обновляет в ней информацию и т.п.
Console - интерактивная обертка над stdin, позволяет вводить команды для экземпляров Server и Database.
Сonsole в своем конструкторе вызывает конструктор класса Messages, который содержит информацию о конфигурации и состояниях экземпляров Server и Database.
Код: https://pastebin.com/EM5nrVEx
В самом низу я закомментировал свое решение этой проблемы, оно самое очевидное, но хочется как-то сделать все универсальным, чтобы порядок вызова конструкторов и методов был не важен при этом сохранить класс Messages, потому что мне нравится, когда есть всего один класс со всеми возможными сообщениями, вызов которых происходит повторно в разных участках кода.
Повторю проблему: конструкторы ClassConsole и ClassMessages могут (и делают это в данном примере) срабатывать позже отработки методов run() экземпляров ClassServer и ClassDatabase. Как можно изменить архитектуру классов, чтобы получить универсальную и независимую работу этих классов?
Также, я не знаю что у тебя console делает, он он похоже должен имплентировать IMessages и называться ConsoleMessageLogger.
Если тебе еще и контроллер нужен, делаешь IController и ConsoleController. Жаль что интерфейсов то нет. Если консоли еще нет, а писать в нее уже нужно, пишешь буферизующий декторатор для логгера. Ммм, ООП.
Не по теме твоего вопроса, но: откуда такое именование у тебя появилось? Это можно теперь так делать или ты сам придумал?
Мимо дед
Возможно. Просто я такой человек, который может часами думать над названием переменной, поэтому подобного рода проектирования для меня - лютый пиздец.
>>1952906
Ничего особого не делает да и не будет, скорее всего, только число команд будет расти. Вот реальный код на текущий момент: https://pastebin.com/jqeeVYDW
Про существование интерфейсов я уже и забыл, даже не помню для чего они нужны. Спасибо, почитаю.
>>1952909
Я хочу свести к минимуму использование готовых библиотек/фреймворков. Пишу в первую очередь с целью понять/изучить.
>>1952911
Можно, если имя не зарезервировано. В моем случае server и database работают, console тоже, но начинаются проблемы, когда нужно в этом же коде вызывать console.log(). Надо наверное лучше сразу тогда придумать какой-то префикс для полей класса (для экземпляров объектов он уже есть).
>Можно, если имя не зарезервировано
Да я прекрасно знаю, что можно. Можно даже кириллицей переменную объявить, но не лучше ли придерживаться общепринятому стилю кода? Сейчас может быть ты пишешь исключительно для себя, но однажды, если планируешь связаться с программированием, ты будешь трудиться в составе Команды. Лучше уже сегодня привыкать к тому как принято
>>1952930
Если я привел код в пример, это не значит что я его использую. Просто иногда для быстрого дебажного лога проще что-то подобное написать и стереть сразу же. Поэтому в main() у меня не console, а lfConsole = new LFConsole(...), но в полях классов я еще не придумал правила именования, потому что конфликтов не было, потом исправлю.
>Я хочу свести к минимуму использование готовых библиотек/фреймворков. Пишу в первую очередь с целью понять/изучить.
Чувак, если ты хочешь _изучить_, то изучать надо то, что наработано другими.
Понимаешь?
Пытаться понять, почему так, а не иначе.
Много читать (код и книги), и не очень много писать (больше заметок, чем кода).
И только потом - пытаться делать своё.
Иначе будет такая же хуита, как и у других 16-ти летних мидлов и синьёров, прости г-споди. Которых, почему-то, никто не хочет брать на работу.
Вообще с тобой не согласен. Читая чужой код, ты учишься делать чужие ошибки, а не только получаешь какую-то полезную информацию. Эту информацию нужно еще и самому обработать. И выходит, что это ни чем не отличается от обычного самообучения на практике. Дохуя людей, которые пишут код, считают себя синьорами, рубят 300к/нсек, а на деле хуи моржовые с клавиатурой в руках. Почему в софте, над которым трудятся сотни человек, имеет ту же сотню багов, которые "фиксят" и находят новые? Не потому что код пишут 16 летние мидлы, а потому что это люди, которые считают что делают что-то лучше и правильней, другой считает по своему, третий аналогично и т.д. Все доходит до того, что ведущий погромист, видит это написанное говно, мерджит в мастер и ахуевает, потому что он 100ый в этом списке, да и вообще он написал даже книгу свою по архитектуре кода, которая выстрелила и ее до дыр читает другая сотня-тысяча вайтишников-шахтеров, которые потом с ноги ворвутся за своими 300к/нсек, щеманут омежек и начнут диктовать свои условия команде. Все это конечно утрирование, но примерно так оно все и работает на самом деле.
А что я? Я просто сижу и по фану пишу свой код, в котором я ориентируюсь. Пишу программки для себя, начиная с меньшего, чтобы потом написать что-то большее, например, свою игру. Поэтому да, чем меньше я использую прослойки в коде, которые скрыты, тем больше я понимаю код и имею над ним контроль. Никогда не понимал выскочек, которые про велосипеды что-то там бормочат. Велосипеды - это хорошо, если ты понимаешь зачем он тебе нужен.
Я учился еще в вузике на погромиста, закончил, но интерес к нему у меня пропал. Я не работал ни в каких командах, все что писал выше это не более, чем мой субъективный взгляд на вещи со стороны. Ну а спустя годы, я просто решил к этому говну вернуться и расшевелить его. Ни на какие лавры не претендую, устраиваться никуда не хочу, но хочу понимать свой код и иметь контроль над ним. По возможности использовать более элегантные решения, я же все-таки не против клир кода и прочих концепций в подходе к написанию его, что-то даже в памяти еще осталось после вуза.
> Читая чужой код, ты учишься делать чужие ошибки,
Ебать ты альтернативно одарённый.
А не читая чужой код, ты обречён сделать все те ошибки, которые уже были сделаны до тебя, за всю историю программирования, плюс добавить ещё и своих уникальных тараканов.
Но, вообще, каждому - своё.
Кто-то - перфекционист.
А кто-то - онанист.
Во-первых, со стрикт-режимом где?
Во-вторых - как это меняет тот факт, что JS - дрисня, а TS - рулит?
И что единственный способ починить JS - это писать тонны JSDoc комментариев, в которых, в итоге, получается сильно больше знаков, чем если бы ты писал типы в TS?
Речь была вообще о том, что нельзя однозначно сказать "читай чужой код - становись профессионалом". Чаще даже узнаешь что-то новое/полезное, когда сам пишешь и пробуешь разные варианты, эксперементируешь, а сидеть книжным червем и надрачивать на макконела или ковырять гит такого же самоучки - это дорога хуй пойми куда и зачем, в которой ты идешь только по наитию и принимаешь все за чистую монету. Я не против книг и поиска информации из всех возможных источников, но говорить "иди ковыряй чужой код и читай мою любимую книжку, иначе не стать тебе погромистом" это... Действительно, каждому свое, тут не поспоришь даже.
>смотри код
>интуитивно
>станешь синьором
хуя шиза в вакууме
>Дроч с конфигами — главная боль фронтенда имхо
Это ж фича бабеля - плагины конфигов пресетов.
>>1953098
>в которых, в итоге, получается сильно больше знаков, чем если бы ты писал типы в TS?
ЖСдоковые каменты по крайней мере в тело функции не протекают и ими можно назначать тип функциональным объявлениям. И проиграл от количества знаков, какая тебе нахуй разница сколько там знаков в сырцах?
>на бесплатный хостинг
Наверное никак, чтобы не было 404 тебе нужно в конфигах сервера прописать что все роуты идут через твою страницу (например index.html) если там nginx и у тебя нет доступа к конфигам, то земля тебе пухом, есть Apache, пробуй .htaccess конфигурировать. Сейчас у тебя скорее всего по роутам сервер ищет физически расположенный файл по этому адресу, а его нет вот и 404. А в проекте у тебя все работает потому что роуты без перезагрузки страницы и js меняет url в адресной строке.
Видимо так и есть. Перенаправляет на страницу, ссылка на которую записана в htaccess. Хостинг hostronavt.ru, может кто сталкивался. Как это делается в реальных проектах? Меняется конфиг сервера хостинга? Или может на хостинг заливать билд спроектированный на экспрессе, который на гет запросы будет отправлять файлы ? Или это совсем хуйня?
Эксперты работы с апи обьясните почему если меняю ссылку на апи которое в комментариях то происходит тайперрор
https://codesandbox.io/s/bold-turing-f71jo?fontsize=14&hidenavigation=1&theme=dark
Ну не знаю, попроси знакомого поиграть с тобой в ролевые игры "интервьюер - соискатель".
Для собеса надо знать только базу - замыкания, прототипное наследование, сортировка, это стандартные вопросы на всех собесах.
Срякт и остальное что выучил можешь на пальцах объяснять. Главное еще что бы пет проект был вылизаный, заходишь на него и все блестит. Так обычно в джуны и набирают.
В любом случае лучше пробовать идти на собес, когда будешь работать - в тиме будешь расти быстрее, нежели дома.
Но скорее всего у тебя не прокачаны софт скилы и социально взаимодействие. Потому что тот кто заинтересован в работе - обычно проявляет инициативу и настойчивость - в ходе беседы понимает где его минусы, интересуется как минимум чего ему не хватило для оффера, хотябы в обратном письме эйчару. После того как узнал что компания в тебе не увидела - дрочишь эти темы и дрочишь. Потом пробуешь еще раз проходить собес, можно в том же месте можно в другом.
Сап, джигиты. Пытаюсь в редакс и появился вопрос - если я обращаюсь к стору в родительском компоненте, насколько правильно передавать стейт стора/экшены как пропсы дочернему? Или это говнокод, а в дочернем компоненте нужно еще раз подключиться к стейту?
Или достаточно один раз настроить и потом просто копировать его в проекты и меня src пути к файлам?
Посмотрел гайд, все настроил, все работает, лень там че то разбираться дальше.
Смотря что ты хочешь сделать. Я вот пилю интернет-магазин-PWA на гатсби и у меня компоненты там двух видов - UI, которые нужны чисто чтобы рендерить UI элементы и собсно родительские, которые задают структуру и получают данные из редукса, которые потом передают в UI компоненты по надобности, а также они же диспатчат экшоны в редукс, который потом меняет стейт, запускает thunkи, которые общаются с API и так далее.
Блять, анон, странные у тебя вопросы. Вебпак, как и вообще любой фреймворк, библиотека, пакетменеджер и прочая хуйня - созданы исключительно для твоего удобства. Ты сам решаешь насколько хорошо тебе надо ознакамливаться с инструментом, который облегчает тебе жизнь. Никогда не понимал откуда у людей такая тяга устраивать себе специальные олимпиады на ровном месте.
КАК В РАБОТЕ ИСПОЛЬЗУЮТ ВЕБПАК, НА РАБОТЕ? В ОФИСЕ? ПОСЛЕ ВЫПИТОГО СМУЗИ?? КАК ВЕБПАК В ИДЕАЛЕ НАСТРАИВАЮТ??? КАК ВЕБПАК НАСТРАИВАЮТ ХИПСТЕРЫ БОРОДАТЫЕ В СТАРТАПАХ???? КАК ВЕБПАХ ИСПОЛЬЗУЕТСЯ В КРЕЕМНЕВОЙ ДОЛИНЕ??? КАК ВЕБПАХ НА ГАЛЕРЕ НАСТРАИВАЕТСЯ??? ВЕЗДЕ ОДИНАКОВО??? +-???? ЕСТЬ ОТЛИЧИЯ ГДЕ ТО????
так понятно?
Есть те, кто работая в одной компании становился из JS джуна мидлом? (Ну или те, кто увольнялся с джуна и шёл на мидла). Какой багаж знаний и сколько коммерческого опыта вы имели на этот момент?
Ну т.е. вот к примеру, с такой оберткой я тему уже откуда угодно могу тему переключить. А как это обычно делается вообще?
РЕДАКС МОЖЕТ В REALTIME STATE UPDATING?
Какого хера объект ошибки конвертится в строку, а обычный объект нет. Это баг или фича?
ПЕТОН?
РИАКТ?
ДЖАВАСКРИБТ?
СИ ПЛАС ПЛАС?
>sass
>2021
Lol!
>Styled components замедляют
Пруфы? На сколько замедляют, на 0.0001 ms? Ну если тебе так важно, можно юзать linaria, тогда вообще не будут замедлять.
>и так тормознутый реакт
Просто не пишешь говнокод и ничего не будет тормозить.
>ну и добавляют еще один слой пиздеца в кашу JS + JSX.
Наоборот убирают слой css классов, которые загрязняют JSX.
У тебя могут быть почти одинаковые по сути компоненты, но которые могут менять свой внешний вид в зависимости от каких-то состойний, заглушенные кнопки, и т.п. Либо делай всё стилями, либо в стайлед компоненты передай пропсы. В первом случае у тебя будет каша css стилей и условного рендеринга. Во втором у тебя будет только один единственный стайлед компонент с пропсами
А стили и не должны управляться джсом. Джс управляет классами, стили применяются к ним. Styled components как идея бред. Конечно, это работает, но даже простые стили выглядит как пиздец смесь CSS и JS, страшно представить как это выглядит в больших проектах с вложенными селекторами и со сложным CSS. Стили вообще не должны никакого отношения иметь к компонентам, все что их волнует это конечные HTML селекторы.
>>1954109
>Наоборот убирают слой css классов, которые загрязняют JSX.
Поперхнулся. Как можно загрязнить то, что и так уже является грязной смесью разметки и кода?
>Просто не пишешь говнокод и ничего не будет тормозить.
Просто любое реактоговно даже от реакторазрабов тормозит, видимо не родились еще люди которые могут идеально писать реакт код.
Ты охуеешь, но можно просто вынести твои состояния в отдельный компонент и переключать классы в нем, если очень сильно нужно. Будет точь-в-точь styled components но лучше. Но обычно даже это не нужно, и ты избавляешь себя от необходимости писать десять импортов кастомного говна, чтобы табличку сверстать, а просто пишешь html с классами.
Дело тут в том, что стайледы находятся в одном месте и все, что там внутри происходит сразу же у всех на виду. А что ты там в классах с десятикратным условным рендерингом понаписал, не всегда знаешь даже ты сам.
>вынести твои состояния в отдельный компонент
Поздравляю, ты только что styled-components
>html с классами
Неудобное говно само по себе, тут даже обсуждать нечего, если только у тебя там не тудулист из 4х элементов без переиспользования
>>1954185
Научись пожалуйста излагать свои мысли, я тебя с трудом понимаю. У тебя есть один стайлед компонент, внутри которого ты можешь делать все, что угодно использую все средства js. У классов говно мамонта 1000 летней давности. Предлагаешь писать отдельный класс на каждый пук, где у тебя isMobile, isDisabled, isActive, isHuiNane? Я просто не понимаю что тут вообще можно обсуждать. Может у тебя конечно там 10 захардкоженных компонентов на каждое дуновение ветра, но тут уж земля бетоном тогда
> А стили и не должны управляться джсом. Джс управляет классами, стили применяются к ним
В итоге реакт компоненты засраны этим управлением классами, в то время как в случае со стайледами просто аккуратно предаются пропы.
> Styled components как идея бред. Конечно, это работает, но даже простые стили выглядит как пиздец смесь CSS и JS, страшно представить как это выглядит в больших проектах с вложенными селекторами и со сложным CSS.
Выглядят как sass, только не замусорены классами и дата-атрибутами.
> Поперхнулся. Как можно загрязнить то, что и так уже является грязной смесью разметки и кода?
Если ты грядет пишешь JSX, то это твоя проблема.
> Просто любое реактоговно даже от реакторазрабов тормозит, видимо не родились еще люди которые могут идеально писать реакт код.
У меня не тормозит, и у многих других.
>>1954185
Передаешь объект с возможными состояниями как проп один раз вместо говномесива из переключений классов и всё.
>>1954183
Чем лучше? Правильно, ничем. Дожили, даже в js-среде ретрограды есть, хотя казалось бы — самая динамичная среда в разработке.
>А что ты там в классах с десятикратным условным рендерингом понаписал
Ну так не пиши классы с десятикратным условным рендерингом, поехавший. sass тут при чем?
>У тебя есть один стайлед компонент
Один на каждый пук в приложении и все стили с нуля пишешь? Или может они все-таки что-то между собой имеют общее? Если второе, то не один.
>>1954202
>Передаешь объект с возможными состояниями как проп один раз вместо говномесива из переключений классов и всё.
А в кастомный компонент ты объект с состояниями передать не можешь или как?
> А в кастомный компонент ты объект с состояниями передать не можешь или как?
Каждый span в реакт компонент что ли оборачивать? И там разводить дрисню из переключения классов, когда я могу одной строчкой это через стайледы сделать?
В общем, хотелось бы увидеть реальные ощутимые примущества сасс перед стайледами. Но вот что-то ни разу никто не выложил пример, где было бы видно в коде, что сасс лучше стайледов.
>Дело тут в том, что стайледы находятся в одном месте и все, что там внутри происходит сразу же у всех на виду. А что ты там в классах с десятикратным условным рендерингом понаписал, не всегда знаешь даже ты сам.
Не поверишь, селекторы по классам состояний тоже в одном месте находятся, в скоупе базового класса.
>одной строчкой это через стайледы сделать
Как будто говно, которое ты импортируешь свой стайлед, не состоит из дрисни ифов.
>Но вот что-то ни разу никто не выложил пример, где было бы видно в коде, что сасс лучше стайледов.
Странно, что ты тоже нихуя не выложил, а доказывать тебе должны тебе.
>селекторы по классам состояний тоже в одном месте находятся, в скоупе базового класса.
Ну теперь стал понятен уровень дискуссии. И вот такую срань ты предлагаешь в качестве альтернативы стайледам? Это так верстальщики свой загон охранять решили? Ну тогда понятно
>хотелось бы увидеть реальные ощутимые примущества сасс перед стайледами
Нет дружок, речь как раз о том, что сасс делает все то же самое, что делает любая js-дрисня для стилей, но выглядит лучше, воспринимается легче, работает быстрее и понимается любым человеком, знакомым с азами css-html. Так что показывать и доказывать преимущество js-дрисни на сассом должен именно ты или другие подобные тебе, а не наоборот. Пока этих преимуществ не видно.
>Ну теперь стал понятен уровень дискуссии. И вот такую срань ты предлагаешь в качестве альтернативы стайледам?
Твоя альтернатива - хранить такую же срань в отдельном модуле, заместо отдельного файла стилей.
>Это так верстальщики свой загон охранять решили?
Неплохая боль неосилятора CSS, языка для макак между прочим. Интересно конечно про загоны слушать от жсдебила, который даже свою маму в скрипте хранит.
Толстота полилась. Покажи компонент кнопки, который может иметь 3 разных стиля, 2 разных варианта для мобильной и десктопной версии, состояние активно и заблокировано. И чтобы в любой момент ты мог 3 изначальных стиля расширить. Мне страшно представить какое количество говна ты туда понапишешь своим сасасом, который ты сам не сможешь разобрать уже через полчаса после написания.
Ну вот о том и речь, теперь подумай как это выглядит на самой кнопке, где у тебя будет миллиард условий для рендера отдельных классов, вместо тех же самых условий в самих полях стилей которые видны сразу. Ты ушел не так далеко от того, чтобы сделать это еще удобнее. 3 вида кнопки, это изначальные стили, а уже к ним применяется состояние активно или заблокировано, в итоге тебе все равно нужно будет создавать отдельный компонент, который еще и стили будет подгружать, вместо того чтобы этот компонент изначально на стайлед компонентах и сделать чел пчел пчелибас, тут просто не может быть никакого смсысла в добавлении стилей к тому, что изначально стилями можно описать
Не вижу твоего варианта, видимо не прикрепилось. Попробуй еще раз.
>как это выглядит на самой кнопке
<button className="btn btn-primary"/>
>в итоге тебе все равно нужно будет создавать отдельный компонент
Создам я его только тогда, когда он мне понадобится, не раньше. У меня же нет невынимаемой sc-затычки в жопе, которая требует кастомного комопнента на любой пук.
То, что ты мне показал, вообще к изначальному условию, которое я описал не применимо. Очень похоже на то, что ты просто верстальщик, и не хочешь терять своё место, либо учить js
><button className="btn btn-primary"/>
Даже в этом простейшем примере у тебя уже на первой же итерации начала выходить дристня. Объясни мне, а лучше сначала себе, зачем в этой цепочке нужна прослойки из css классов?
>Не вижу твоего варианта, видимо не прикрепилось. Попробуй еще раз.
Я твоего тоже не увидел, но забавно то, что даже в твоём урезанном до предела примере всё уже выглядит как говно. Представь, что у тебя btn-primary1, btn-primary2, btn-primary3, для каждой active, disabled, и для каждого варианта wide/mobile. И попробуй убедить себя в том, что классами это можно сделать элегантнее и читабельнее. И это при том, что тебе все равно нужно будет создавать компонент. В итоге ты сделаешь бессмысленную прослойку видимо только из вредности мне?
>То, что ты мне показал, вообще к изначальному условию, которое я описал не применимо
Шизик, твое начальное условие описанное тобой же, это: 3 разных стиля, 2 варианта для мобильной и десктопной версии и два состояния. Все соблюдены до точки. Что ты там нафантазировал у себя в голове я прочитать не могу, только то, что написано текстом.
>Объясни мне, а лучше сначала себе, зачем в этой цепочке нужна прослойки из css классов?
Ну наверное потому что просто кнопка и кнопка с primary стилем - это разные кнопки и это стандартная практика шеринга стилей, чтобы их не дублировать несколько раз в итоговом коде? Лично ты можешь сделать миксин кнопки и включать его внутри btn-danger/btn-primary, тогда даже btn писать будет не нужно, если готов заплатить за это несколько килобайтов. Разрешаю.
>Представь, что у тебя btn-primary1, btn-primary2, btn-primary3
Представить не могу, если не дебил с цифрами в классах. То, как мои кнопки будут выглядеть, я уже написал:
<button className="btn btn-primary" disabled={isDisabled}/>
<buttom className="btn btn-danger" disabled={isDisabled}/>
Расскажешь, почему для это вдруг "нечитабельно" и как js-дрисня сделает это лучше? И все еще жду пример твоей js-дрисни, а то в воздух ты пердел-пердел о конкретике, а в итоге сливаешься без примеров.
Пробуй без статики и с меньшим количеством зависимостей
https://stackblitz.com/edit/typescript-kpxz6k?file=index.ts
Сначала дай хоть один внятный аргумент чем архаичный sass лучше стайледов.
>>1954215
> Как будто говно, которое ты импортируешь свой стайлед, не состоит из дрисни ифов.
Ничего никуда не импортируется, пропы в стайледы прикидываются как в обычных реакт компонентах и дрисни из ифов нигде нет. Только однострочные тернарники.
> Странно, что ты тоже нихуя не выложил, а доказывать тебе должны тебе.
Первым было утверждение, что стайледы говно, вот и доказывайте, сасс-шизы
>>1954224
> Нет дружок, речь как раз о том, что сасс делает все то же самое, что делает любая js-дрисня для стилей, но выглядит лучше, воспринимается легче, работает быстрее и понимается любым человеком, знакомым с азами css-html
Но стайлдеы могут всё то же, что и сасс, но при этом больше из-за возможней js. Стайледы выглядят красивее и легче воспринимаются, потому что в них нет дрисни из css-классов, и в них нет ничего сложного, из понимает любой человек, который уже работает с реактом.
>Но стайлдеы могут всё то же, что и сасс, но при этом больше из-за возможней js
Каких возможностей тебе в сассе не хватает, подскажи?
> Стайледы выглядят красивее и легче воспринимаются
Перетолстил.
>>1954302
Ну вот видишь, уже выглядит как дрисня с магическим кастомным DSL и у этих людей хватает наглости кукарекать про "неявность" сасса, а теперь возьми стандартный реакт компонент с десятком разных элементов. Будешь каждый раз хуячить 10-строчные импорты своих кнопок, таблиц, лейаутов?
По объему не больше sass, так что не вижу нагромождения. Ну и читается не сложнее, как по мне, тем более подсветка синтаксиса в vscode лучше, чем в codesandbox.
Огромный компонент будет не больше, чем sass, но удобнее. Выше в треде был пример с sass, там не меньше объём.
>>1954337
> Каких возможностей тебе в сассе не хватает, подскажи?
Возможностей js, очевидно.
> Будешь каждый раз хуячить 10-строчные импорты своих кнопок, таблиц, лейаутов?
Импорт всего лишь несколько строк в начале файла занимают, это вообще не мешает, в отличие от засирания jsx css-классами и логикой из переключения. Но ещё одно преимущество стайледов в том, что локальные компоненты можно объявлять прямо внутри реакт компонента, а импорты будут только для общих компонентов типа кнопок.
>Возможностей js, очевидно.
Каких? Одну назовешь?
>в отличие от засирания jsx css-классами
То есть засирание импортами говна тебе не мешает, а обычные html-классы вдруг мешают? Ты поехавший?
>и логикой из переключения
Не засирай, вынеси логику переключения в отдельный компонент, прямо как выносишь любую другую. Зачем тебе для этого ебаный sc?
>Но ещё одно преимущество стайледов в том, что локальные компоненты можно объявлять прямо внутри реакт компонента
Это называется "антипаттерн" и "говнокод", а не "преимущество".
Нужно получить JSON с данными с сервера. Есть условие, что в респонсе должен быть ответ со значением {stop: true}, тогда типа все ок, JSON готов.
Я решил поиграться в браузере - вбил строку с реквестом, и смотрю в консоле респонс, там stop всегда false (пробовал отправлять реквест несколько раз снова и снова, в итоге сервер просто обрубил меня).
Это как - в промисе ждать, пока в респонсе тру не будет, не резолвить? Или другой способ? Почему в браузере не получается?
Когда через скрипты меняем например текст в html документе.
Где хранится этот измененный DOM ? В кэше?
Типо если обновить страницу, то HTML страница возвращается к стандартному DOM который был прописан в HTML до выполнения скрипта. Измененный DOM типа временный получается.
Все, что по факту предъявляют SASS-шизы в треде - импакт по производительности. Который на деле является микроскопическим, если ты делаешь все правильно и не дрючишь стили 60 раз в секунду. А если ты настроишь SSR, то этот импакт вообще устремится к нулю.
Про отвал всего приложения на SC: приложение надо тестировать и ошибки оборачивать в ErrorBoundary
> Каких? Одну назовешь?
Уже не раз назвал возможность передавать пропсы, например, или темизация, но ты копротивляешься ради архаичного пердолинга с классами, дата-атрибутами и написанием большего количества кода просто потому что у тебя иррациональная неприязнь к новым, более функциональным инструментам. Сасс-шизы это прямо неолуддиты из мира фронтенд разработки.
> То есть засирание импортами говна тебе не мешает, а обычные html-классы вдруг мешают? Ты поехавший?
Импорты во-первых ничего не засирают, их вообще не видно потому что они в самом начале файла, а вот css-дрисня гадит прямо посреди jsx.
> Не засирай, вынеси логику переключения в отдельный компонент, прямо как выносишь любую другую.
Зачем что-то куда-то выносить и засирать проект лишними файлами, когда я могу в стайледах аккуратно, красиво и удобно а одну или пару строк это сделать?
> Это называется "антипаттерн" и "говнокод", а не "преимущество".
Ты скозал? Single file components в vue тоже антипаттерн? Лол. Я для тебя ещё раз повторю: внутри реакт компонента иногда люди могут оставлять локальные стайледы. Common вещи вносятся в отдельные файлы, очевидно. Но импорты — это последнее, что засирает код, потому что их тупо не видно на экране во время работы.
>возможность передавать пропсы
sass у тебя эту возможность не отнимает, хочешь - делай логику и передавай. В 99% случаев тебе так и так нужно эту логику писать, потому что это рабочая логика приложения, а стили просто приходятся сверху дополнением, как и должны. Схуев ли ты решил, что завязывать стилизацию и рабочую логику переключения стейта в одно месиво это хорошая идея - большой вопрос.
>или темизация
Что тебе мешает сделать темизацию css-методами вместо ре-рендеринга всего приложения нахуй?
>написанием большего количества кода
Но больше кода пишут как раз sc-шизы, потому что выкидывают в окно готовые инструменты(html-классы) и пердолятся со своим инлайн говном и кастомными компонентами.
>их вообще не видно потому что они в самом начале файла
Охуительные истории, 30 строчек импортов - это заебись, они в начале файла и их не видно. Представляю твои файлы.
> Зачем что-то куда-то выносить и засирать проект лишними файлами
См. выше. Логика переключения стейтов - это рабочая логика, и писать для нее "лишние файлы" ты будешь так и так. А если не будешь, то инлайн добавить класс по условию нихуя не проблема.
>Ты скозал? Single file components в vue тоже антипаттерн
Да, я скозал. Что там в vue не ебу, но хуярить sc внутри комопнента - это точно то же самое, что хуярить инлайн-стили вместо классов. Почему это плохо и говнокод, можешь спросить в 2010 году, еще тогда все выяснили.
>Что там в vue не ебу
Во .vue файлах пик, scoped аттрибут изменяет любой селектор и добавляет доп. условие, чтобы в других компонентах/дом элементах с таким классом ничего не применялось. Ну еще можно сделать <style lang="scss"> и у тебя сасс работает (да что угодно, главное чтобы вебпак понял о чем ты), импортируешь свои миксины и дрочишься. И еще можно несколько <style> тагов, например хочешь прямо из компонента срать в глобальные стили. Короче хз нахуя я это пишу но лично мне вью очень нравится тем что его можно постепенно очень хорошо внедрять в уже существующее легаси говно.
мимо
1) Создаешь .env файл, пишешь в него все свои ключи, добавляешь этот файл в .gitignore
2) Создаешь .env.example файл пишешь в него все те же самые ключи, только без секретных значений, чтобы можно было окружение воспроизвести на другой машине или другому разработчику без заебов. Коммитишь этот файл и обновляешь по мере надобности.
3) Добавляешь в README как часть сетапа строчку `cp .env.example .env`
4) На любом новом сервере с проектом просто выполняешь команду выше и заполняешь все ключи, либо проставляешь эти ключи в ENV переменные контейнера, если у тебя какой-нибудь докер, а файл оставляешь пустым.
Так вот в конце курса проходим реакт. А в начале щупаем es6 и пишем свою библиотек по типу jquery, мол что бы понимать как классы работают и вообще библиотеки. Пока сидели разбирали как jquery работает я чуть не охуел от перегрузки, эта тема действительно нужна или можно скипать и учить реакт?
Курс невозможно смотреть, много воды + эти два деятеля не печатают код сами, а показывают какие-то картиночки.
КАРТИНОЧКИ, БЛЯДЬ!!!
P.S. Чьи курсы по html/js вы можете посоветовать?
const add = () =>{
dispatch({type: actionTypes.ADD_TO_CART, payload: {id:id, name:data.Name, price:data.Price} })
}
или создать отдельный файл для экшенов, а потом просто написать
const add = () =>{
dispatch(addToCart(id,data)
}
ну первый пик про версточку которая типа на работе учится и dom, к которому настоящие реакт-интеграторы не притрагиваются
Знать конечно это все нужно, но ты же уснешь
второй - это ооп за 24 часа ы, объект - значит ооп)) и ajax через jquery. jsonp хорош для кругозора, cors на работе почитаешь
третий неплох, но вот эти декораторы через бабель поняты не будут. mobx для начала тоже сомнителен, надо сразу погружать в редакс, чтобы spacex dragon завидовал жопной тяге, но это субъективное
4 был бы норм, если бы побольше хуков и поменьше классов, ну и смотря что там в разделе про формы
Все эти полифилы для фетча попахивают 2018. Ну и ни слова про тайпскрипт.
Какой вопрос - такая, знаешь ли, и реакция, создается ощущение, что ты вообще не понимаешь что такое dom. Браузер получает html, браузер у себя в памяти строит модель по этому html - DOM, и показывает ее тебе. Если ты вносишь изменения в DOM - они разумеется не сохраняются в полученный с сервера html, даже если он кеширован, и сбрасываются, как только ты закроешь или обновишь вкладку.
>sass у тебя эту возможность не отнимает, хочешь - делай логику и передавай
Как передавать? Через дрисню из классов и дата-атрибутов? Нет, спасибо.
>Что тебе мешает сделать темизацию css-методами вместо ре-рендеринга всего приложения нахуй?
Неудобная и всратая ебля с css-переменными.
>Но больше кода пишут как раз sc-шизы
Ну, это просто не так. Стайледы наоборот сокращают количество css-дрисни.
>Охуительные истории, 30 строчек импортов - это заебись, они в начале файла и их не видно.
Схуяль 30 строчек? Сас-шиз, откуда ты себе это придумал?
>Что там в vue не ебу
Охуенно. "Не читал, но осуждаю". Типичный долбоёб, которому лишь бы спиздаануть своё охуенно важное мнение о том, в чём он даже не разбирается.
>хуярить sc внутри комопнента - это точно то же самое, что хуярить инлайн-стили вместо классов
Нет, не то же самое. Я скидывал codesandbox и там видно что это не так.
Продолжай оправдываться.
И что в нем вместо ангуляровских модулей?
>Как передавать? Через дрисню из классов и дата-атрибутов?
Через дрисню из пропсов, прямо как ты передаешь в sc
>Неудобная и всратая ебля с css-переменными.
Действительно, очень сложно 10 переменных объявить и поменять по мере нужды, лучше ре-рендерить инлайн дрисню во всем приложении каждый раз.
>Я скидывал codesandbox и там видно что это не так.
Там видно только то, что лично ты ленивый дурачок и написал все в одном файле. Если ты так пишешь в реальное приложение, 200 строк компонента и 100 строк стилей в один файл, то это нахуй из профессии.
мимо 2 месяца дрочусь, нужно прерваться
Нет, там же не надо декораторы настраивать.
Просто в хук вынеси
https://codesandbox.io/s/elegant-nash-4ui2p?file=/src/cats/RandomKitty.tsx
За пару лет ничего не пропустишь, не переживай. Отдыхай.
> Через дрисню из пропсов, прямо как ты передаешь в sc
Не вижу в sc дрисни, это же не цсс-классы
> Действительно, очень сложно 10 переменных объявить и поменять по мере нужды, лучше ре-рендерить инлайн дрисню во всем приложении каждый раз.
Каждый раз? Один раз при смене темы, только делать это удобнее через ThemeProvider
> Там видно только то, что лично ты ленивый дурачок и написал все в одном файле. Если ты так пишешь в реальное приложение, 200 строк компонента и 100 строк стилей в один файл, то это нахуй из профессии.
Всё — это что? Одну кнопку? Я говорил, что компоненты вроде кнопок выносятся в отдельные файлы потому что они для общего пользования. Но именно здесь кнопка используется только в одном реакт компоненте поэтому она объявлена в нём же
Не совсем понимаю, почему я до сих пор не услышал ни одного преимущества саса, сас-шиз? Даже преимущество в 0.0000001 ms скорости обходится через linaria (компиляция стайледов в цсс). Какие твои оправдания, сас-шиз?
Шизло, я же тебе сказал, преимущества должен указывать ты, потому что именно ты пытаешься заменить стандартные ксс-классы на дрисню из магических темплейт строк с функциями и бексконечными ?. && чеками на любой пук, не предоставляя своему шизобесию никаких оправданий, кроме пердежа "итажи жапаскрипт, значит он удобнее". Пока преимуществ, кроме "можно серить там же, где и ешь" я не услышал. Пытайся лучше.
Вот типа такого:
https://htmlacademy.ru/projects/online-store/payment
Только бесплатно.
>>1955094
Шизы, хватит срать. Просто покажи мне условный медиазапрос в css, когда у тебя один и тот же элемент должен делать запрос по разной ширине, если к примеру слева какая-то менюшка открыта или закрыта. И таких медиазапросов у тебя может быть 4 штуки. В СК это делается парой строчек. В ЦСС ты будешь срать кровавым поносом
Психопрофиль стайлед-бояр: стремятся изучать новое, применяют современные, более функциональные инструменты в разработке. В отличие от сас-шизов не стремятся пилить бревно перочинным ножичком, а используют для этого бензопилу. Быстрее делают свою работу благодаря более рациональному подходу и владению эффективными инструментами. В них живёт дух молодости, исследования, открытости, прагматичности. Предпочитают находиться в авангарде технологий, их стек всегда востребован, им постоянно предлагают работу с всё более крупной компенсацией, их любят коллеги-зумеры и тяночки из HR-отдеда, а коллеги-бумеры их боятся и избегают зрительного контакта с ними. Их профиль на линкедине спамят рекрутеры из США, Австралии, Сингапура и Нидерландов, в то время как сас-шизы довольствуются редкими подачками предложений с пост-советских актсорс-параш.
Психопрофиль сас-шизов: ретрограды, имеют нездоровую привязанность к архаичным моделям, их психика утратила гибкость и подвижность. В общем, это закостенелые бумеры, боящиеся вылезти из зоны комфорта. Неолуддиты из мира разработки интерфейсов. Отсутствует понимание о том, что такое чистота в коде, эстетика им чужда. Любят защищать громоздкие конструкции, к которым они привыкли, ведь из-за ригидной психики новые изменения приносят им боль. Их существование наполнено страхом потерять работу из-за неактуально стека технологий, который они используют. Фронтенд разработка приносит особенно много боли сас-шизам, ведь здесь скорость изменения технологий наиболее высокая. Сас-шизов презирают сообществах наиболее сильных и высокооплачиваемых разработчиков. Им рады только на галерах, где они могут с радостью для себя дрочить легаси сас-дрисню за низкий прайс, после чего спустя несколько лет они будут вытеснены с рынка из-за выборочного эйджизма, который не применяется к светлым умам стайлед-бояр, в которых живёт дух молодости даже в солидном возрасте.
Я не понимаю, почему мой по клику не меняется значение в стейте. Я уже все что можно перепробывал
https://codesandbox.io/s/tender-christian-4igcw?fontsize=14&hidenavigation=1&theme=dark
Как реализовать плавную анимацию без jquery?
function sum(argument1, argument2){
argument1(){}};
argument2(){};
}
То что бы потом потом вызвать функцию с аргументом, мы должны написать не имя переданной:
let randomFunc = function(){console.log("1+1")}
sum(argument1, randomfunc)
функции ее обертку в анонимную функцию? вот так:
sum (argument1, function(){randomFunc()})
такое возможно?
Хуй знает что вы там делаете, но тебе похоже нечем заняться, так что сделай пока это
https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Range
Аудио и видео на клиентской стороне в большинстве случаев обрабатывается через `<audio>` и `<video>` тэги, которые по сути контейнеры для ссылок, как `<img>`. Хуй знает, что ты там собираешься писать, в том же экспрессе по дефолту настраивается папка `public`, которая и отдаёт файлы без всяких дополнительных движений.
Если же надо оформлять ссылку на скачку, то достаточно указать `download` у ссылки.
Если же прям надо кишочки работы апи того же `<audio>`, то тут только читать https://developer.mozilla.org/en-US/docs/Web/API/Web_Audio_API или спеку.
А как-нибудь протестить эти теги можно? Паблик нельзя юзать, аудио считай голосовые сообщения и просто с медиа урла нельзя отдавать, нужна проверка прав, но при проверке получилось пока только именно скачивать, в обоих запросах и когда скачивается файл и когда именно в браузере появляется(как у картинок типа открыть оригинал, чисто картинка по урлу), в обоих запросах метод гет, майм тип один и тот же
>А как-нибудь протестить эти теги можно?
Делаешь эти теги в шаблоне и можешь обтестироваться на тестовом сервере.
>Паблик нельзя юзать, аудио считай голосовые сообщения и просто с медиа урла нельзя отдавать, нужна проверка прав, но при проверке получилось пока только именно скачивать
Просмотри https://developer.mozilla.org/en-US/docs/Web/HTML/Element/audio#attributes и если никак проверку прав через аттрибуты не сделать, то придётся нырять в интерфейс HTMLAudioElement и там уже пердолить свою реализацию запроса прав.
Да почти все медиасервисы так делают со статикой, урлы только хэшируют анально да от роботов прячут.
Можешь при загрузке статики токен какой-нибудь в заголовке или запросе проверять для авторизации. Можешь файлы в статику складывать только после запроса за метаданными и потом удалять. Можешь DRM обмазаться если совсем упорот.
Суть моей части проекта в том чтобы написать полностью фронтенд, начиная от UI элементов с версткой до всей бизнес-логики работы с API. Проект сам это интернет-магазин PWA. Сделать надо на генераторе статических страниц Gatsby для оптимизона, при этом на него мне пришлось написать source-plugin для работы с их кастомным API. Сам Гатсби на реакте если что.
Ну так вот, я дал свой эстимейт закачику ио времени и цене, и уже поздно метаться, ибо по руками ударили, но я чет теперь думаю что я по неопытности взял слишком мало времени и денег и меня ждут бессонные ночи в попытках не проебать очередной дедлайн.
Дайте пожалуйста ваши примерные эстимейты на проект по времени и цене. ТЗ нет, потому что мне буквально точно также всё на словах раскидали, да знаю что пиздец, но кушать хочется.
Возьмем к примеру нодовский модуль http представим, что я делаю 10 асинхронных запросов на удаленный сервер. Задачи ставятся в очередь, но не блокируют друг друга, т.е. возвращается ответ на запрос, который пришел первым, а не был первым поставлен в список задач.
Это что получается? Эти задачи выполняются параллельно? Т.е. не в одном потоке? Но нода однопоточна же. Гдето краем уха услышал, что многопоточность реализует не язык, а окружение, в котором язык выполняется, например в браузере - браузер, у ноды с++ (или что там).
Поясните про эту хуйню короч.
>Но нода однопоточна же.
Однопоточна в том смысле, что у тебя один event loop и одновременно может выполняться только одна строчка JS кода. Но fetch и setTimeout это не JS-код и они там могут быть хоть 100-поточными. Когда ты пишешь fetch то тебе в ЖС сразу (!) возвращается промис, на этом JS переходит к следующей строчке, а самим XHR занимается уже браузер и как -- это его дело. С таймером то же самое, ВСЕ джуны валятся на этой хуйне. setTimeout возвращает идентификатор таймера МГНОВЕННО и сразу после этого JS выполняется дальше, таймер тикает в браузере и когда таймер заканчивается, то браузер просто ставит переданный в setTimeout callback в очередь макрозадач. Ни таймеры ни XHR не являются фичей джаваскрипта, это фичи БРАУЗЕРА (ну или ноды или любого другого окружения).
В смысле опрашивает промис, чо ты несёшь? Движок браузера написан на С++ и он в случае с фетчем делает днс запрос, открывает соединение на нужный айпишник и шлёт туда байтики, потом получает обратно из сокета какие-то байтики, смотрит хорошие это байтики или не очень и в зависимости от этого переводит промис на стороне ЖС в одно из состояний фуллфиллд или реджектед. Ну или может быть он вообще достаёт файл из кэша, может из дискового, может из оперативки.
>Опрашивает промис раз в n миллисекунд?
Што? Промис это просто объект в JS - его не опрашивают. Он создаётся и при создании получает значение пендинг. Потом он обязан быть переведён в фуллфиллед или реджектед, после чего в очередь микрозадач движком ставится соответствующая таска.
Ебать, теперь это называется для общего развития кек?
https://www.youtube.com/watch?v=cCOL7MC4Pl0
https://learn.javascript.ru/event-loop
>Движок браузера написан на C++
В контексте Chrome -- да. Движок firefox например на джаве написан.
>в случае с фетчем делает днс запрос, открывает соединение на нужный айпишник и шлёт туда байтики, потом получает обратно из сокета какие-то байтики, смотрит хорошие это байтики или не очень и в зависимости от этого переводит промис на стороне ЖС в одно из состояний фуллфиллд или реджектед.
Так уже понятней.
Вот это https://chromium.googlesource.com/v8/v8/+/3.29.45/src/promise.js?autodive=0/ вроде как реализация промиса в V8.
>все асинхронные операции - это не ЖС
На практике да, это выглядит именно так.
>>1956298
>имеет синтаксис для вызова этих операций
Да
>и обработки результата
Обработку в том смысле, что он ставит задачу в одну из очередей, да. С самим результатом ты уже всё разбираешься сам в коде коллбэков своих.
>сама работа делается устройством
Ответ на этот вопрос не относится к ECMAScript. Он знает, что промис рано или поздно будет фуллфилд или реджектед, на этом всё и это гарантируется. Будет там браузер поднимать для этого потоки, устанавливать соединения или пойдёт в кэш дисковый или в кэш памяти - ECMAScript'у категорически похуй.
Знание того, как оно устроено внутри в движке абсолютно бесполезно. По крайней мере на том уровне, пока ты не понимаешь досконально то, как это выглядит снаружи, что гарантируется, в каком порядке итд итп. А как только ты с этим разберёшься, то у тебя про внутренние детали браузера вопросы сразу и исчезнут, потому что это не имеет значения. Сам там был. Когда разберёшься с event loop, у тебя пропадёт неуверенность и непонимание того, чо в каком порядке происходит в твоем коде и почему оно так делает, и браузер тогда из твоего поля внимания исчезнет. Сейчас ты чтением исходников хрома пытаешься прикрыть пробелы в понимании, не трать время.
Купи лол скачай конечно же сам знаешь откуда https://frontendmasters.com/courses/javascript-hard-parts-v2/ и пересмотри хотя бы раза 2-3, оно стоит того.
В последней ссылке есть буквально ответ на вопрос, который ты спрашивал выше. Вот прям буквально про fetch, поэтому я тебе эту ссылку и кинул.
И да, тот чел рассказывает ОЧЕНЬ душно и подробно, но я не советую на первой итерации скипать. На второй-третьей уже можно, ессно.
Алсо, далеко не все курсы с того сайта я бы рекомендовал. бОльшая часть там всё же неплохие, но есть и не очень удачные и просто запредельное говно.
В жс всё является объектом как пистоне или есть какие-то исключения?
>сама работа делается устройством?
Не устройством, а окружением.
JS это встраиваемый язык без средств ввода/вывода.
Он нужен для программирования среды, в которую он встроен. А встроен он может быть куда угодно - браузер, нода, фотошоп, автокад, ардуино, и сотни других даже есть ядра операционной системы, где js engine работает в нулевом кольце и на нем ты можешь программировать, например, планировщик потоков этой операционки или аллокатор памяти.
Вот есть язык Lua, который исторически встраивают в игровые движки, чтобы писать игровую логику. Есть тысячи других встраиваемых языков программирования. ЖС ровно для того же нужен. Только он многим мощнее и выразительнее всех прочих встраиваемых, и с ортодоксальным синтаксисом.
Предьяви этим ребятам: https://www.w3schools.com/jsref/event_onclick.asp
>Как вы пришли к тому, что все начали пилить руками?
Зачем? Руками имеет смысл пилить какие-то учебные вещи, чтобы разобраться с концепцией. А библиотеки - это глупо. Там очень много рутинной работы, которая к повышению скиллов отношения не имеет.
Запили реализацию async/await через генераторы, например. Хорошее упражнение. Займёт у тебя от 3 минут до 1 месяца и повысит твой скилл.
https://trekhleb.dev/blog/2021/gyro-web/
Нужно ли подчищать что-то вил анмаунтом после того как зафетчил что-то? Например как у меня сейчас, я фетчу с апи мои обьекты, массив полученный записываю в стейт, по вил апдейту этот стейт перезаписывается (с переходом на новую страничку)
Заметил что иногда страницы подружаются по 6 секунд (там 8 картинок 200х200 и чуть текста), иногда как-то подлагивает мб из-за того что где-то не анмаунтнул?
Анмаунт нужен в основном чтобы отписываться от каких-либо событий, хз что ты там хочешь подчищать, учитывая, что стейт и так очищается после удаления компонента. Хз что у тебя с картинками, но по хорошему ты их ниоткуда скачивать не должен, должен быть хостинг изображений и ты просто вставляешь ссылку оттуда в <img />, тогда это никак работу сайта стопать не будет.
Сегодня мы с помощью библиотеки JQuery и функции animate придаем нашей страничке немного мобильности и живого вида!
Так же мы научимся как делать всплывающий upbutton.
>>1956782 (OP)
>>1956782 (OP)
>>1956782 (OP)
>Это что получается? Эти задачи выполняются параллельно? Т.е. не в одном потоке? Но нода однопоточна же.
Нода на плюсах параллелит, это движок для ЖС
https://www.toptal.com/back-end/server-side-io-performance-node-php-java-go
В ещё одну отдельную очередь. Макротаски дёргаются из очереди строго по одной за итерацию лупа. Микротаски выполняются за одну итерацию все по очереди, причём, если ты будешь на лету добавлять микротаски (синхронно резолвить промисы, например), то ты застарвишь очередь (это будет выглядеть как while (true) по сути). А коллбэки rAF выполняются когда браузер решит, что он готов рендерить и они выполняются за одну итерацию все, если их несколько, но вновь добавленные уже уйдут на следующую итерацию.